This is the fourth and last part of our series of posts on how to create an Authors module using the QbMageModuleShell tool we developed. In the first post we showed how to create the module and set up a basic author model, in the second post we showed how to create a simple frrontend view of our data, and in the third post we added to the product an “author” attribute, to be able to choose the author for a product. In this post we will show the author insde a product’s view page.

For that end, we’ll need to accomplish some things:

• Create a block for the tab
• Create a template for the tab
• Add the tab to the product page layout.

Create a block for the tab

To do this, we’ll create the block in product/tab/author, which extends Mage_Catalog_Block_Product_View_Attributes.

We will need to open the “Create PHP Class” slider in the module’s page, in QBMageModuleShell. There, we will use block/product/tab/author as the pathname, and Mage_Catalog_Block_Product_View_Attributes in the extends field.

We will then add to the created file, app/code/community/Quanbit/QBAuthors/Block/Product/Tab/Author.php, the following methods:

function getAuthor(){
 return Mage::getModel('qbauthors/author')
           ->load($this->getProduct()->getAuthor());
}

function getAuthorLink(){
 return Mage::getBaseUrl().'qbauthors/author/view?id='
           .$this->getAuthor()->getId();
}

Create a template for the tab

Then, we create the file for the template, called app/design/frontend/default/default/template/qbauthors/product/author.phtml, and add the following content:

<?php
$author = $this->getAuthor();

if($author):
?>
<div class="box-collateral box-up-sell">
 <h2>Author: <a href="<?php echo $this->getAuthorLink()?>">
    <?php echo $author->getName()?>
 </a></h2>
</div>
<?php endif ?>

Add the tab to the product page layout

Finally, we need to tell Magento to use that block, and that template, in the product view page. To do that, we need to edit the qbauthors.xml file, and add the the following (just before the last </layout> tag):

<catalog_product_view>
 <reference name="product.info">
   <block type="qbauthors/product_tab_author" as="author" 
         name="product.author" template="qbauthors/product/author.phtml">
   <action method="addToParentGroup"><group>detailed_info</group></action>
   </block>
 </reference>
</catalog_product_view>

This is adding the block to that page.

This is the final result:

This is the third part of our series of posts on how to create an Authors module using the QbMageModuleShell tool we developed. In the first post we showed how to create the module and set up a basic author model, and in the second part we showed how to create a simple frrontend view of our data. In this post we will create a new product attribute set for our store (a Book) and link each book to its author.

Defining the Attribute and Attribute Set

In Magento, Products have a special structure, which is called the Entity Attribute Value model (EAV). That structure allows the administrators of the site, to easily add attributes to the products, and even create different sets of attributes. We’re going to take advantage of that, by creating a new attribute (the “author”) and a new attrribute set (the “book”).

First of all, we need to edit, in our module, the file /etc/attributes.yml (create if it’s not there already). Here, we will write the following content:

attribute:
 catalog_product:
  author:
   source: qbauthors/author
   visible_on_front: true
   input: select
attribute_set:
 catalog_product:
  book:
   attributes: [author]

In the first few lines, we’re creating the attribute, and setting some non-default values:

1. that there is a Source for our data (the Authors model we already created), and
2. that this data should be available in the frontend, and
3. that we should see a “select” for choosing among the different options

In the last lines, we create the Book attribute setm and add the author attribute to it.

After writing the file, we need to go to this module’s page inside QBMageModuleShell, and do “Create Migrations”. That way, the tool will read the file we just created, and  generate the attributes creation script. Afterwards,  ”Run Migrations”, so Magento knows that the next time we load a page, it will need to run the migration scripts for this module again. WARNING! The creation script will erase all the data for the module, so you should back it up first.

Viewing the result

To check how everything worked, we’re going to create a new Product. When we go to the New product page, inside Magento’s admin, we will be able to choose “Book” from the dropdown of attribute sets. After choosing it and clicking it, we will be able to create the new Book.

Here, in the new tab created called “Book”, there is a dropdown where you can choose an author from our previously loaded list.

The created Attribute and Attribute set are standard EAV objects of Magento, so if you want to use the EAV editor inside Magento (in Catalog > Attributes) to change them in any way, you’re free to use it.

This is the second part of our series of posts on how to create an Authors module using the QbMageModuleShell tool we developed. In the first post we showed how to create the module and set up a basic author model. In this post we will create a frontend view to list and view the details of the authors in the store.

Creating the Frontend View

A Frontend View allows a visitor of the website to view some type of information. We will create a view to list the authors, and then another one to view the details of a specific author. To create the frontend view, go to the module view and choose “Create Model Frontend View”. In the text field, choose the same name we chose for the last class (“author” in our case) and hit the “Create Model Frontend View” button.

For those of you that are interested, the tool basically created a controller, a Block and a couple of templates to display both the list and the detail view. It also registered the layout for the controller in the layout file, and the route for the controller in the config file.

Check it out!

And that’s it! The frontend view is created and completed. In order to try it out, we will add two authors. In order to do that, login to the store admin, and go to the CRUD page we created last class. There, add a couple of authors to try the frontend for yourself.

Now we need to navigate to the right url to see the authors (no menu item is added to the frontend). The url has the form of: http://<<magento>>/<<module short name>>/<<model name>>, so in our case this would be http://magento.localhost/qbauthors/author. As you can see this url takes is to a list of authors (ok, I admit it, the styles are not great, but that’s work for the frontend designer of the store ).

As you would expect, by clicking in the name of an Author you can navigate to the detail page.

Customizations and fine-tuning

While useful for creating the skeleton of your module, QbMageModuleShell doesn’t take care of the pages styles. As a result you will surely want to customize them and adapt to your store needs. To do that, you can edit the template files in the app/design/frontend/default/default/template/qbauthors/author/ folder. Don’t be afraid to changing them in any way, because if you make a mistake you can easily regenerate all the files again using the steps above. Just be sure to backup your modifications first, since regenerating the model will overwrite the existing files.

In “Creating Magento modules the easy way” we argued for the need of a tool to automate the process of creating some Magento artifacts. We also opened to the community a tool that we have been using internally in Quanbit. We are now presenting a series of posts that will show how to create an Authors module for our Magento store using QbMageModuleShell, our automation application for Magento.

Login

In order to start creating Magento artifacts we will need to install QbMageModuleShell. Assuming that you have downloaded it to your local machine, you should go to the front page in http://localhost:8080/ and see someting like the image below. Here you should enter the path to the Magento Installation (e.g. /home/alex/Projects/MagentoPlugins/qbauthors).

Creating the Module

If everything went ok you should see a list of all the available modules like the one shown in the image below (of course the exact modules being listed will vary according to your custom Magento installation).

Since we are going to create our own module, we click on the “New Module” button. In the new module form we will choose “Community”, and enter our package and module name (Quanbit and QBAuthors respectively). We finally hit the “Create Module” button and the work is done!

If you want to check that everything went as expected you can go back to the module list, search for the new module, and click on “view”.

Creating the Model

There, we will create this model: a class Author, with the name, birthdate, and bio of the author. To do that, we will use our favourite text editor and edit the /app/code/community/Quanbit/QBAuthors/etc/model.yml file. That is a YAML file which contains the definition of each model class. We will add there this definition:

author:
   name: string
   birthdate: date
   bio: text

After we save that file, we will have all the information needed to create the model, and the CRUD for it. Going back to QbMageModuleShell, we need to access the module, and then perform the following steps:

• Create Model: Here we will write just “author” and the application will create all model files necessary (including the resources files).
• Create Model Admin: Here we will write “author” once again, and this will create a Backend controller that will allow us to perform CRUD operations on this class of the model. We will be able to access it from catalog/authors in the backend menu.
• Create Migrations: This operation creates a migration file, with the “create table” SQL Query for the authors table.
• Run Migrations: In this step, what we are actually doing, is instructing Magento that in the next page load, it should run all migrations from this module all over again. So, we will see no change in the database until we load any page of our store or backend.

After all that, we have all the necessary files for the module to work. If we now navigate to our magento admin, and login there, we will find in Catalog/Authors the fully working admin for the Authors.

In the next classes we’ll see:

Anyone that has already tried to create a Magento module knows what a hassle it can be: creating the folders in the right places, setting the right files distributed among the private configuration of the module and the global configuration of Magento, the layout files, and so on. And if this wasn’t enough, creating a class for a Block or a Model does not get any easier: again the right names in the files, registering everything in the configuration files, etc, etc, etc.

Being such a cumbersome, error prone and repetitive process makes it an ideal candidate for automation. So we created a simple application called QBMageModuleShell. Although it was originally a command line application used for internal development, we have added a web frontend and released it to the community. In QBMageModuleShell you can point to your Magento installation and have the application perform some of these repetitive tasks for you. We have already implemented several components to handle things like creating, deleting, enabling and disabling modules, building blocks, controllers and model classes, creating CRUD Admin for model classes, creating and running migrations, and we are adding more stuff every day. Let me show you just a hint of the app:

If you are willing to try it you can download it here

Hernán Wilkinson is not only a guy who knows a lot about Object Oriented Programming and TDD, but also an excellent teacher. If you ever get the chance of hearing him speak (whether it is a talk at a conference, assisting to one of his courses in the university or by hiring his training services) I would recommend that you don’t miss it.

Being such a fig fan of his talks I was quite happy last week when I started to see some blog articles written by him, in particular about the importance of using good names when we program. You can get a small taste of it here:

…Good names make our lives easier, on the other hand, bad names make us feel in hell. Bad names suck energy from us because we have to “re-think” every time we see that bad name what it really means, what it is the real purpose of that thing being named. At the end, bad names obligate us to do the work that other should have done, that is why we “hate” programs written by others and we “hate” them more if they are badly written, if the names are bad…

So, if you want to be a better programmer, please take a minute and go to read them: About “names” when designing with Objects and The “Art of Naming”.

And as a bonus, if you like digging in the OOP history you may want to read the following page: Dr. Alan Kay  on the Meaning of “Object-Oriented Programming”

Enjoy!

When developing a project for one of our biggest clients, we realized that Magento had some very powerful and interesting rules for applying discounts on the shopping carts. Those rules take into account the amount of items in the shopping cart, the shipping address, the categories of the products and several other attributes. However, while rules are very powerful, the possible actions to be performed are quite few. You can apply discounts or free shipping, but we needed something else: we needed to be able to enable or disable a shipping method based on the cart products.

Imagine this: you are running your e-commerce site and you want your customer to be able to choose overnight delivery only if he/she is buying a product from the ‘offers’ category. Thus, you would like to tell Magento to enable the overnight delivery only if there’s at least one product with the ‘offers’ category in the cart.

That’s how QBShippingAndPaymentFilters was born. With this module you will be able to create rules to enable or disable either payments or shipping methods. These rules use the full power of Magento’s shopping cart rules and enable you to present the right options for the customer based on them.

For the example presented before you can set up a rule for doing exactly that; of course we assume that the overnight delivery shipping method is properly configured and disabled from Magento’s admin interface (it is the module’s responsibility to enable it when the conditions are met). As you can imagine, the same approach can be used for enabling and disabling payment methods.

If you like to try it out you can go to the product page.

Although this is a bit of old news, I wanted to mention it: last week the release of elgg 1.8.3 was announced. I have to say I’m pretty amazed by the release speed of these guys. Keep up the good work!

Just a quick update: elgg 1.8.2 has been released. You can find the bugfixes and enhancements in the announcement.
We are very happy to have contributed with our small grain of sand and hope to keep doing so.

Writing a test with QBElggTestsForPHPUnit is not much different that writing a standard test with PHPUnit. In future posts we will see how to tweak things a little (like adding custom fixtures) but right now I’m just going to show you how to write a very simple tests: the HelloWorldTest . The purpose of this test is two-folded:

• Showing a simple example of a test.
• Showing that each test runs on a “clean” DB state.

To do this we will create a test case class with two test methods (testCreateNewObject1 and testCreateNewObject2) such that the second test depends on the first one. This will ensure that testCreateNewObject1 will run always before testCreateNewObject2 (check the @depends PHPUnit directive).

In testCreateNewObject1 we are going to create a new object, save it to the DB and check that it has a valid GUID. But that’s not it: we are also going to pass the GUID of the object to the next test and see what happens when testCreateNewObject2 creates a new object. If the tests don’t share the same DB state then creating a new object should yield the same GUID, since both tests where executed on “clean” DBs. As a matter of fact, the GUID created in testCreateNewObject1 should not even be a valid entity GUID in testCreateNewObject2.

So, here goes the code with the necessary comments:

We can now run this test in the console by doing:

And that is pretty much it