Create a directory in sites/all/modules and name it ‘mymodule’. This will be the directory of your new module and it should contain the .info and .module files.

Creating the .info file:

Before we start coding our new module, we need to create a simple text file that will hold some basic information about our module. Create a file in the ‘mymodule’ directory and call it mymodule.info. Enter the following contents into the file:

; $Id$
name = My module
description = Just a test module to learn hooks
core = 6.x

You can add more into .info files. For more information on that go here : http://drupal.org/node/231036.

Creating a .module file:

The .module file will hold all the code ie. All the hooks that the module implements goes in here. Create a ‘mymodule.module’ file in the mymodule directory. Now if you go to Administer-> Site Building -> Modules you will be able to see your new module:

Now you can enable the module. However the module will not give any results because we haven’t implemented any hooks to join in with the Drupal workflow. In the following few sections we shall look at implementing some hooks.

Hooks:

For a complete list of hooks you can go to : http://api.drupal.org/api/group/hooks/6 and also http://drupal.org/files/drupal_6_core_hooks_cheat_sheet.pdf.

We will be implementing only some of these hooks.

Hook_perm:

This hook is used to add user permissions into the permissions list. These permissions can then be selected on the user permissions page and used to restrict access to actions the module performs. Permissions are checked using user access().

Enter the following code in your .module file:

<?php
function mymodule_perm() {
return array(‘permission 1′,’permission 2′);
}

This will add permissions to the permissions list. If you would go to Administer->User Management->Permissions you will see the following:

You can check if the user has a permission by using user_access() function. (eg: if(user_access(‘permission 1’) {  //do something } )

Hook_help:

The next hook is hook_help(), which allows you to create an entry in the global help page (/admin/help/) as well as providing help messages display at the top of pages. This hook accepts two parameters $path and $args. The return valu should be a string containing the help text. Here is an implementation:

function mymodule_help($path) {
switch ($path) {
case ‘admin/help#mymodule’:
return t(‘This is a module being implemented primarily for understanding hooks !’);
break;
case ‘node/add/story’:
return t(‘Don\’t forget to:Enter a title, Promote to front page etc’);
break;
case ‘node/%/edit’:
return t(‘Some notes on editing nodes’);
break;
}}

Now if you were to go to Administer->Help, you will see a link to My Module. This will give the following page:

Also if you try to create a new story by going to node/add/story you will see the help text on the top of the page as follows:

Similiarly if you try editing any created content you will get a help text – ‘Some notes on editing nodes’ on the top of the page. So using hook_help we created can create a help page for the module and also add help texts to top of any page in drupal using $path.

Naming convention:

The available hooks to implement are explained here in the Hooks section of the developer documentation : http://api.drupal.org/api/group/hooks/6. Each hook has a defined set of parameters and a defined returned type. The string “hook” is used as a placeholder for the module name is the hook definitions. For example, if the module file is called example.module, then hook_help() as implemented by that module would be defined as example_help().

How hooks work? :

Drupal offers a system of callback hooks at various parts of the core code. The hooks are placed in key locations within the core code, such as when adding a user,publishing a blog etc… When the core code hits a hook, it will call out to all implementers of a given hook, finding implementers by looking for method names that adhere to the naming scheme.

For example hook_perm function is used to setup new permission types that can be granted to user account roles. If you go to the permissions page at drupal/?q=admin/user/permissions you will see a list of permissions.

Drupal checks for all the modules that implements the ‘hook_perm’ In this case blog and block module implement the hook_perm as blog_perm and block_perm respectively. Similarly all implementations of hook_perm are called to generate the final list. Thus modules adding permissions to the list by using hook_perm. Some modules like blogapi do not implement hook_perm, that’s why it is not present in the list.

So during the step by step process of executing a request Drupal executes hooks at certain points. While executing hooks Drupal finds functions in modules which implement that particular hook and executes those functions as well. Thus this way modules can intervene and add to the normal workflow of Drupal.

Create a new directory in the sites/all/themes folder. This is the place where all user defined themes should go. Name the new directory as ‘mytheme’ which will be the new name of your theme.

.info file:

Create a .info file with the name mytheme.info. This file defines metadata for the theme, including the name of the theme, a description, its Drupal core version compatibility, and which theme engine it uses. Style sheets, JavaScripts, Block regions are also defined here. Enter the following contents now:

; $Id$
name = Mytheme
description = Just a new theme.
version = VERSION
core = 6.x
engine = phptemplate

You will notice that at the top of files you download from Drupal. org there is always a line commented out that starts with $Id:, with a name and some date information that follows after. This is a special ID tag used by the version control system used by Drupal.org (CVS) to maintain all of the core and contributed code. Your custom files don’t need this line on them but it doesn’t hurt to have it there either. The empty version of this string is simply $Id$.

Now if you go to Administer->Site Building->Themes you will be able to see your new theme in the list. Now if you select this theme you will see a disorganized output. This is the default output from different modules. The main page is displayed by system/page.tpl.
You can see this by using the Themer info function of the Devel module.

In order to organize the page output you need to override page.tpl (theme_page()). Lets copy the page.tpl file from bluemarine theme and paste it in our theme, then empty cache (using Devel), and reload the page. Now the page is organized into different regions. If you copy the style.css file also the the page would appear styled.

Changing CSS:

Let’s start by adding a border around content items to help them stand out on the page. Using Firebug in Firefox we can find out the exact element that styles the node, which is the .node at line 232 of the styles.css. Change it as follows:

.node {
margin: .5em 0 2em; /* LTR */
border: 1px dashed #ccc;
padding: .5em;
}

Your page will now appear with dashed lines around the nodes. You can also override other CSS files, but then you will have to include it in the .info file of the theme like this example : stylesheets[all][] = system-menus.css.

Modifying a Template file : (*.tpl.php files)

Now let’s look at customizing the page.tpl.php file. This is the file that defines the general HTML structure of the entire page. The theme engine and enabled modules make a number of variables available to this file, and then these variables are simply output using PHP print statements. Let’s change the structure of our theme by moving the breadcrumb output up into the header region of the page.

Using the Themer info of Devel module you can find out how the breadcrumb is beign output. The parent file is page.tpl.php, so our breadcrumb is being printed from page.tpl.php. The function used to make the $breadcrumb variable is theme_breadcrumb().

Open up the page.tpl.php file in your ‘mytheme’ folder and go to about line 29, where the $header variable is printed. Down at line 42 is the $breadcrumb variable we want to move.

Now let’s modify the file to output the breadcrumbs immediately after the header, by removing line 42 and restoring it as a modification to line 30 as follows:

<tr>
<td colspan=”2″><div><?php print $header ?><?php print $breadcrumb ?></div></td>
</tr>
</table>
<table border=”0″ cellpadding=”0″ cellspacing=”0″ id=”content”>

In a similiar way you can change the appearance of other items like node,block.. using node.tpl.php,block.tpl.php.

Template.php:

The last, crucial piece of Drupal theming is the ability to completely override the output that Drupal gives you by default and use your own custom markup instead. You may find that while the template files give you a lot of control, you can’t really do much about the HTML that you are given inside those variables (like $header,$breadcrumbs). You can do all the HTML editing around them that you want, but how do you crack into the variables themselves. This is where template.php comes into picture. Using template.php file we can override or add variables and also override theme functions.

Overriding/Adding Variables:

All variables that go out to a template file are first passed through a special kind of function, called a preprocess function. You can add your own preprocess function to your template.php file and get the last shot at the variables before they head out to the template. To keep things tidy, you can use one preprocess function per template; for example, you can create a mytheme_preprocess_page function to affect variables to be used in your page.tpl.php file. With this function, you can define, or redefine, any variable.

For example you can define a variable called $random_number as follows:

function mytheme_preprocess_page(&$vars) {
$vars['random_number'] = rand(1, 100);
}

Then (after clearing the Drupal cache), you can print out that variable out in your page.tpl.php file just like any other variable:

<?php print $random_number; ?>

You use the exact same procedure to override an existing variable. When you assign a variable name that is the same as the one Drupal is already using, yours will take precedence.For example to change $submitted from ‘Submitted by…’ to ‘Posted on…’ :

function mytheme_preprocess_node(&$vars) {
$vars['submitted'] = t(‘Posted on ‘) .format_date($vars['node']->created, ‘custom’, ‘F j, Y’);
}

Here is documentation listing all variables available in page.tpl.php, node.tpl.php, and block.tpl.php.

Overriding Theme functions:

Much of Drupal’s HTML output is easily accessible in template files. But what about something like the page’s “breadcrumb trail,” which shows the hierarchy to the current page? Unfortunately, there’s no breadcrumb.tpl.php file. In this situation, you need todig a little bit deeper, to the place where remaining markup in Drupal is initially defined: theme functions.

Theme functions are regular PHP functions located in Drupal’s code whose names begin with theme_. Every element on the page that is not in a template file is run through a theme function, such as the theme_breadcrumb() function: (theme.inc)

The function basically just takes an array of HTML links and uses PHP’s implode() function to concatenate the values using the » character, wrapping this in a <div> with the class of “breadcrumb.”

function theme_breadcrumb($breadcrumb) {
if (!empty($breadcrumb)) {
return ‘<div>’. implode(‘ » ‘, $breadcrumb) .’</div>’;
}}

In its current state, this function will print out the breadcrumb trail on a page, such as Home » Administer » Site building » Themes. But what if we decide that we’d rather the breadcrumb be printed as Home::Administer::Site building::Themes, with doublecolons instead? No problem! We’ll just pop open theme.inc and change it there, right? Wrong! The proper way to handle overriding theme functions is by simply copying the function into your template.php file and naming it according to Drupal’s naming conventions so that it’s recognized. Then you can modify it however you like.

function mytheme_breadcrumb($breadcrumb) {
if (!empty($breadcrumb)) {
return ‘<div>’. implode(‘ :: ‘, $breadcrumb) .’</div>’;
}}

The Theme System :

Each path in Drupal corresponds to a particular module that is responsible for handling the page request. For example, “node/1” is handled by the Node module, “admin/build/themes” is handled by the System module. Once the module has built up the contents of the page, it calls up the theme system with a special function called theme().

The theme() function:

Theme functions are never called directly. They are instead called through a function called theme(). So even though a module may define a function such as theme_username(), when the module needs to output its code, it would call theme(‘username’) instead. The theme() function is what makes this system of overrides possible. For eg: if theme_breadcrumb() function (present in includes/ themes.inc) has not been overridden then it is called else the overriding function(which would be present in template.php of theme) would be called.

What files constitute a theme ?

Themes are present in the drupal/themes directory. Drupal provides a no of themes like bluemarine, garland, chameleon etc..Some of these uses PHPtemplate engine like bluemarine, garland (*.tpl.php files) while others like chameleon dont use template engines. Using PHPTemplate engine we can create .tpl files (uses HTML and PHP) to override theme functions. For eg: to override theme_page() we can make a file called page.tpl.php. However themes that do not use the PHPtemplate engine, have to uses a .theme files which is pure php and contains overriding functions. (chameleon_page(),chameleon_node()..).

Themes also contain CSS,javascript,images which integrate with the template files to produce the desired output. Lets check out the contents of the bluemarine theme :

themename.info (bluemarine.info):

This file defines a variety of metadata for the theme, including the name of the theme, a description, its Drupal core version compatibility, and which theme engine it uses. Beyond those basics, the .info file can also define the block regions available to the theme, and the CSS stylesheets and JavaScript files used.

Template files (page.tpl,block.tpl..):

With these files, using Drupal’s PHPTemplate file naming convention, you are able to ‘override’ the default theme function. Each one controls the layout of certain parts of the template. To edit the display of blocks, nodes, and comments, edit the block.tpl.php, node.tpl.php and comment.tpl.php files respectively. The content generated by these files is used in page.tpl.php.

These files are overriding the default files. All you have to do is find the default template file, copy it into your theme folder, and edit it. Many themes start with these main Drupal core default templates:

page.tpl.php (located in modules/system): Controls the layout of the entire page. This isn’t for the page content type; you can think of it more as the overall screen in which your content types and blocks are displayed.

node.tpl.php (located in modules/node): This is used for the display of each individual node.

block.tpl.php (located in modules/system): This is used for all of the blocks on the site.

comment.tpl.php (located in modules/comment): Each individual comment is displayed with this file.

box.tpl.php (located in modules/system): For the container element that surrounds search results and that surrounds a list of comments that is attached to a node.

You can find any other templates in the folder of the module that created it. for example, forum templates will be in the forum module folder (modules/forum). For a list of these : http://drupal.org/node/190815.

Images and CSS :

Stylesheets can be used along with templates to create the desired look. The theme uses styles.css which is included by default. Also other stylesheets can be used but then you must declare it in the .info file. Images include the logo (logo.png) and the screenshot (screenshot.png).

Template.php :

This file can be seen in garland theme. This file can be used to override theme functions (those present in theme.inc). For example we can change the appearance of the breadcrumb by overriding the theme_breadcrumb() function.

Devel Module:

Devel is one of the most useful tools for Drupal Developers and Themers alike. Devel allows you to: print database queries for each rendered page, expose some handy functions for printing complex arrays in a human-readable fashion, empty cache, rebuild menus with one click, generate dummy content (nodes, users, comments) – great for theming and testing views, Theme Developer: allows you to click any rendered element; observe which function created it; offers candidate override function and displays available arguments as well as candidate template files. You can download it here : http://drupal.org/project/devel.

Content Construction Kit (CCK):

As the name suggest this module is used to build custom content types. Drupal’s  gives each one of the new content types only a “Title” and “Body” field. We’ll need quite a few more fields. With CCK you can add custom field to content types. So you can create forms
containing a variety of fields—such as checkboxes, select lists, image uploads, and many others. You can download the CCK module here: http://drupal.org/project/cck.

Views Module:

The Views module is the natural counterpart to CCK. Views allows you to create pages and blocks that pull data back out and display it to your visitors. For nearly any purpose of displaying content, the Views module can provide a listing of content in a variety of ways: a table, a list of full nodes or teasers, an RSS feed, a list of individual fields, and more.  The views project page on Drupal.org describes Views as: a smart query builder that, given enough information, can build the proper query, execute it, and display the results.
To sum it up, Views gives you a very usable interface to create complex MySQL queries which are used to display your content. You can download the Views module here : http://drupal.org/project/views.

FCKeditor and IMCE:

One of the biggest criticisms of Drupal, apart from the fact that it does not come with a WYSIWYG editor built in, is that it has no built-in image handling. Out of the box, Drupal’s built-in Upload module allows anyone with “upload files” permissions to attach image files to content they create. It’s then possible for them to manually insert <img> tags linking those image files into the content they’re writing. However, that’s a pretty cumbersome process for many users, especially those attaching many images to a long post, like a magazine article. FCKeditor is a WYSIWYG editor that allows people without HTML knowledge to create rich website content. IMCE is an add-on module that can work with editors such as FCKEditor to make it easy to add images to website content. To download FCKeditor : http://drupal.org/project/fckeditor. To download IMCE: http://drupal.org/project/imce.

Some of the important features :

Flexible module system
Modules are plug-ins that can modify and add features to a Drupal site. For almost
any functional need, chances are good that either an existing module fits the need
exactly or can be combined with other modules to fit the need.

Customizable theming system
All output in Drupal is fully customizable, so you can bend the look and feel of
your site to your will.

Extensible content creation
You can define new types of content (blog, event, word of the day) on the fly.
Contributed modules can take this one step further and allow administrators to
create custom fields within your newly created content types.

Search engine optimization
Drupal offers out-of-the-box support for human-readable system URLs, and all of
Drupal’s output is standards-compliant; both of these features make for searchengine
friendly websites.

Role-based access permissions
Custom roles and a plethora of permissions allow for fine-grained control over who
can access what within the system. And existing modules can take this level of
access control even further—down to the individual user level.

Social publishing and collaboration tools
Drupal has built-in support for tools such as group blogging, comments, forums,
and customized user profiles. The addition of almost any other feature you can
imagine—for instance, ratings, user groups, or moderation tools—is only a download
away.

Modules:

All of the administrative and user functionality in Drupal, from fundamental
features such as ability to log in or create content to complex functions,all come from modules
In Drupal each module provides specific functionality, and works together with other
modules to enhance their functionality.Some examples of modules are the Contact module, which enables a site-wide

contact form, and the User module, which handles user authentication and permission checking.
The “core” drupal modules are present in the drupal/modules folder while the “contributed” modules should be placed

in drupal/sites/all/modules. You can enable or disable modules by going to Administer->SiteBuilding->Modules.

Users:

The next building block of a Drupal website is the concept of users.The first user you create when you build a new

Drupal site is special.User 1 has permission to perform any action on the Drupal site.Every additional user can be

assigned to configurable roles. Each role can be given permissions to do different things on the
website: visiting specific URLs, viewing particular kinds of content, posting comments etc.. By default, Drupal

comes with two predefined roles: authenticated user and anonymous user. Anyone who creates a user account on the

site is automatically assigned the “authenticated user” role, and any visitors who haven’t yet created
user accounts (or haven’t yet logged in with their username and password) have the “anonymous user” role.

Nodes:

Any form of content such as blog post,pages,news items are all stored as nodes.All nodes, regardless of the type of

content they store, share a handful of basic properties such as: author,creation date,title,body. In addition to

nodes’ basic, common properties, all nodes can take advantage of certain
built-in Drupal features, like flags that indicate whether they’re published or unpublished
and settings to control how each type of node is displayed. Permissions to create
and edit each type of node can also be assigned to different user roles; for example,
users with the “blogger” role could create “Blog entry” nodes, but only “administrator”
or “editor” users could create “News” nodes. Drupal comes preconfigured with two types of nodes: “Page” and “Story.”

You can also create your own content types.What happens, though, if you need to store more information than “title”

and “body content?” Plug-in modules can add to Drupal’s content system new kinds of nodes that offer more
features. One example (which comes with Drupal) is the “Poll” module. When users
create new “Poll” nodes, they create a list of poll questions rather than the usual “body”
content.The idea that new modules add properties and build on top of the node system means
that all content in Drupal is built on the same underlying framework.. Features like searching, rating,
and comments all become plug-and-play components for any new type of node you may define, because
under the hood, Drupal knows how to interface with their base elements—nodes.

Taxonomy:

Drupal maintains almost everything as a node. So How do you break your separeate your node into separate categories

?.That’s exactly what Taxonomy does.It allows the administrator of a site to set up categories of topics that nodes

can be associated with when they’re created. So you can create predefined “Tags” for bloggers to enter manually when

they post. The Taxonomy module calls all of these things “terms,” and provides a page for each descriptive term

that’s used on the site. When a visitor views one of these pages, Drupal pulls up a list of
all the nodes that were tagged with the term.

Comments:

Comments are merely responses by a user to a piece of content, and exist only in relation
to that content. Like nodes, but to a lesser extent, comments can be expanded with contributed modules to have

additional features such as ratings or file upload fields. An important point to note is that comments are not

stored as nodes, they are only attached to nodes.

Blocks:

Block are widgets that fit into areas such as the sidebars, footers, and headers of a
Drupal site. They’re generally used to display helpful links or dynamic lists such as
“Most popular content” or “Latest comments” and similar items. By going to Administer->Site Building->Blocks
you can configure blocks to show up on certain regions,or to be hidden.

Menus:

Menus hold the navigation links to various web pages on a Drupal site. Drupal comes with three default

menus.Navigation The main system menu. In practice, this menu is the default “dumping ground” of
links offered by modules, including administrative tasks.
Primary links An empty menu provided for custom navigation needs, typically displayed very
prominently in the site’s design. Major sections of the site such as “Home” and
“Blog” tend to be placed in the Primary links menu.
Secondary links Another empty menu provided for custom navigation needs, but more subdued in
presentation. As a general rule, more supplementary pages such as “Terms of Service”
or “FAQ” are placed in the Secondary links menu.

SQL query example:

Lets look at an example of an SQL statement which gets all the products (product_id) in a  particular category:

$sql = “SELECT product_id  FROM catalog_category_product WHERE category_id=3″;
$data = Mage::getSingleton(‘core/resource’) ->getConnection(‘core_read’)->fetchAll($sql);

You will get the product ids as an array in $data. However if we wanted to get all the attributes of a product based on the product_id then it is difficult as all the product info is not present in one table. Due to the EAV design it is loosely present in many tables. So we require to join a number of tables to get the product information. In such cases we should try using Magento’s built-in query methods instead of directly running queries on the database. More on built in query methods later.

Analyzing the code:

Lets analyze the code:

$data = Mage::getSingleton(‘core/resource’);

First of all we require a connection to the database to perform queries. This is done by using resources. The role of a ‘resource’ in Magento is to manage database connections. So using getSingleton(‘core/resource’) we get an instance of Mage_Core_Model_Resource.

Check out that file and you will see a function called getConnection($name). This is used to get a ‘read’ or ‘write’ connection (‘core_read’ – read connection, ‘core_write’ – write connection).

The fetchAll function executes the query and returns all the rows to $data. The results are returned as an array of results (array of arrays).

How do i know the table names ?

You can see Magento’s database design by checking this link http://www.magentocommerce.com/wiki/development/magento_database_diagram.

The core ResourceModel has a method called getTable() to get the table name of any model in the system. Table names do not have to follow the name of the model, an end-user can change the table names by changing an XML setting.Therefore, it is best to use the getTable method of the core resource.

$res = Mage::getSingleton(’core/resource’)->getConnection(’core_read’);
$tableName = $res->getTable(’catalog/product’);

This will give $tableName as ’catalog_product_entity’. This happens because we have the following XML configuration in the catalog module’s config file.

<global>
<models>
<catalog>
<class>Mage_Catalog_Model</class>
<resourceModel>catalog_resource_eav_mysql4</resourceModel>
</catalog>

<catalog_resource_eav_mysql4>
<class>Mage_Catalog_Model_Resource_Eav_Mysql4</class>
<entities>
<product>
<table>catalog_product_entity</table>
</product>

ResourceModels:

ResourceModels manage the different read/write connections and automatically figure out table names based on convention and perform the database related operations for a particular Model. ie. It acts as an abstraction to retrieve (or write) data from database. For eg: in the Mage_Catalog_Model_Product class you can see that to get data it uses the getResource() function. This function gets the ResourceModel to perform the required database operation.

For the Catalog Module the ResourceModels can be found in Catalog\Model\Resource\Eav\Mysql4 directory. (this is defined in the config.xml – search for <resourceModels>). For getting ResourceModels we use the getResourceModel() method.

Mage::getResourceModel(‘catalog/product’) will create an instance of  Mage_Catalog_Model_Resource_Eav_Mysql4_Product.php. (If class names have the term Mysql4 in their names, they are generally called ResourceModels. If the word Entity appears in the class name, then the resource is an EAV Entity). You will get the same result by calling Mage::getModel(‘catalog/resource_eav_mysql4_product’) also.

Now take a look at this Product.php file. You will see some sql statements like the one below:

public function getIdBySku($sku)
{return $this->_read->fetchOne(‘select entity_id from ‘.$this->getEntityTable().’ where sku=?’, $sku);}

So if we need to get the product id for a sku value then we can simply do it by:

$id = Mage::getResourceModel(‘catalog/product’)->getIdBysku(5);

Its easier to use predefined functions than write your own query statements. Similiarly there are other funtions predefined in the Resource Models that you can use to retrieve data from database.

Entities:

Entities extend Magento’s resource objects. Basically, Entities pair up to selected Models and help them save to the database. Entities behave mostly like resource models, as they are just a special sub-class of resources. Entities for catalog module are in Mage\Catalog\Model\Entity.

Collections:

Entities are designed to load one item, or record, at a time. But, most of the time when we think of database queries we want to write a SELECT statement that gives use a result with multiple rows. The entity models are not able to do that.

What if we want to select all records from the database matching some criteria. Normally, a simple SELECT statement with a WHERE clause would work. But, things are not that simple because of the EAV design. Not all of the data that makes up an entity lives in one table, so we need to JOIN more tables. To properly construct a WHERE clause we would have to know exactly which tables our specific data is stored in. This is the problem that collections solve. Loading an arbitrary number of records based on criteria is the job of entity collection.

Probably the most useful method of a collection is the addAttributeToFilter method. This method takes an attribute code and a condition.

$products = Mage::getModel(’catalog/product’)->getCollection();
$products->addAttributeToFilter(’sku’, ’9999’);
$products->load();

In the above example, the condition is a simple string, but the condition can also be an array. When passing a condition array, the key of the array designates the type of comparison. The type can be eq, for equals, like for like comparisons, gt for a greater than comparison. Here is the same example above, but searching for an array of product IDs.

$products = Mage::getModel(’catalog/product’)->getCollection();
$products->addAttributeToFilter(’entity_id’, array(’in’=> array(1,2,36,35) ));
$products->load();

//runs the query
SELECT  * FROM ‘catalog_product_entity‘ WHERE  (e.entity_id in (1, 2, 36, 35))
*/

For loading selected attribute values , we can use the addAttributeToSelect method.

This is only scratching the surface of the SQL that you can generate with collections. Look at the Eav/Model/Entity/Collection/Abstract.php file for a full list of methods to manipulate your SQL. Remember that collections are the only way to load entity objects if you need to use a WHERE clause other than querying against the table’s primary key field. When dealing with non-entity models, you can always write raw SQL and run it against a resource connection.

Using Zend to prepare statements:

You may have noticed that in the ResourceModel files magento team does not use plain SQL.  Instead they prepare it using Zend_Db This means that Magento is using Zend for handling requests.

$read = Mage::getSingleton(’core/resource’)->getConnection(’core_read’);
echo get_class($read);

You will get the class as Varien_Db_Adapter_Pdo_Mysql which is an extension of Zend_Db_Adapter Abstract. You can create an instance of a Zend_Db_Select object using the select() method of a Zend_Db_Adapter_Abstract object. This can be used to build ‘SELECT’ queries. When building the query, you can add clauses of the query one by one. There is a separate method to add each clause to the Zend_Db_Select object. For example:

To Build this query:
“SELECT product_id, product_name, price FROM “products” WHERE price > 100.00″ //this is not a magento query

We can write:
$select = $read->select()->from(‘products’, array(‘product_id’, ‘product_name’, ‘price’))->where(‘price > 100.00′);

More on how to build ‘SELECT’ statements using Zend here : http://framework.zend.com/manual/en/zend.db.select.html.

Lets look at an example:

What if you want to load all products in a particular category:

$resource = Mage::getSingleton(‘core/resource’);
$read = $resource->getConnection(‘core_read’);
$categoryProductTable=$read->getTableName(‘category/category_product’)
$select = $read->select()->from(array(‘cp’=>$categoryProductTable))->where(‘cp.category_id=?’, 3);
$products=$read->fetchAll($select);
foreach($products as $row)
{
$product = Mage::getModel(‘catalog/product’)->load($row['product_id']);
echo $product->getName();
}

getModel() (To create an instance of a Model class) :

The getModel() function is used to create an instance of a Model class. For example

$Product = Mage::getModel(’catalog/product’);

would basically tell Magento to create an instance of Mage_Catalog_Model_Product class. (ie. Mage/Catalog/Model/Product.php). If we now echo the get_class($Product) we would get the Mage_Catalog_Model_Product text displayed in our browser. You can use all methods defined in Product.php. Some useful methods include getName, getPrice, getTypeId, getStatus which we can execute like:

echo ‘Product name: ‘ . $Product->getName();
echo ‘Product price: ‘ . $Product->getPrice();

However, the above code wont give you anything. You will not see any price displayed in the browser. This is because you haven’t loaded the product using load() method. We have to use the load method to load some data into our newly instantiated object.

$Product->load(53); where 53 is the product id.

getData() (To get relevant data from the object instance)

This function is used to get relevant data from the object instance. Let’s say you want to retrieve the SKU value. You can use some other method for that like getSku() method that needs to be executed on object of Product type or you can:

echo $Product->getData(’sku’);

getData can be executed with or without any parameters passed to it. If you execute it without any parameters you get the array variable as a result. You can’t directly echo the array. You would have to map it to some field, like echo $arayVar['someField']. What are all the available fields? To find out you can do something like

echo ‘<pre>’;
print_r($Product->getData());
echo ‘</pre>’;

You can get the sku of the product by:

$ProductData = $Product->getData();
echo $ProductData->sku;

or:

echo $Product->getData(‘sku’)

Another example:

$ProductData = $Product->getData();
$StockItem = $ProductData->stock_item;

Now your $StockItem variable is a object of type Mage_CatalogInventory_Model_Stock_Item and you can go ahead and use the same principle used until this point to find it’s methods and the data it holds.

First use the getModel to create the instance of object then you use getData to retrieve the data from that instance.

getSingleton():

One of the important architectural feature is it’s Singleton design pattern. In short, Singleton design pattern ensures a class has only one instance. Therefore one should provide a global point of access to that single instance of a class.

So when you are using getSingleton you are calling already instantiated object. So if you get the empty array as a result, it means the object is empty. Only the blueprint is there, but nothing is loaded in it.

Registry:

We had told that Magento provides global point of access to single instance of classes. How does Magento do it ?. This is done by using an array called registry in Mage.php.

Checkout the Mage.php file and you will see an array variable called _registry.

In order to provide global point of access for an instance of a class we must register the object into the registry array by using a function called register. For example:

Mage::register(‘events’, new Varien_Event_Collection());
Mage::register(‘config’, new Mage_Core_Model_Config());

Here is the code of the register() function:

public static function register($key, $value, $graceful = false)
{
if(isset(self::$_registry[$key])) {
if ($graceful) {
return;
}
Mage::throwException(‘Mage registry key “‘.$key.’” already exists’);
}
self::$_registry[$key] = $value;}

Basically what it does it registers an object with name as $key and the instance as $value into the registry array. You can also unregister an object using the unregister() function.

Whenever we want to call an object from the registry we use the registry() function. For example in the getConfig() method:

public static function getConfig()
{
return Mage::registry(‘config’);
}

Previously we had registered an  instance of Mage_Core_Model_Config as ‘config’. The getConfig() function returns that instance. Here is the code for registry() function:

public static function registry($key)
{
if (isset(self::$_registry[$key])) {
return self::$_registry[$key];
}
return null;
}

Analyzing the getModel() and getSingleton() code:

The getModel() and getSingleton() functions works by using this registry. Here is the code for the getModel() function:

public static function getModel($modelClass=”, $arguments=array())
{
return Mage::getConfig()->getModelInstance($modelClass, $arguments);
}

Basically it gets the Config object (This object is formed by parsing all the config.xml files, so it contains all config details of all moules) and then makes an instance of the model that is specified by the $modelClass argument.(for example if $modelClass is ‘catalog/product it creates an instance of Mage_Catalog_Model_Product)

Now take a look at the getSingleton Method:

public static function getSingleton($modelClass=”, array $arguments=array())
{
$registryKey = ‘_singleton/’.$modelClass;
if (!Mage::registry($registryKey)) {
Mage::register($registryKey, Mage::getModel($modelClass, $arguments));
}
return Mage::registry($registryKey);
}

Basically it checks wheter an instance of that class is already existing, if so return that instance else create a new instance and register it as ‘_singleton/$modelClass’.

Job of the controller:

The controller receives a URL request from the browser. The controller has to process this request to find what code to run. This is done via a router. Routing is the process of taking a URL and decomposing it into parameters to determine which module, controller, and action of that controller should receive the request. The URL gets “routed” to a particular Controller, which in turns tells Magento what to do. The Controller tells Magento which layout is to be used. This determines which modules are put into place, which in turn tells Magento what Views to output. The data from the Models are given to the Views to be displayed. In the scheme of things here, Blocks fit roughly between the View and the Model.

Decomposing the URL:

Now we will see how a browser request to a URL gets translated into module execution. Generally speaking any URL can be deconstructed as follows:

As you can see the above URL has been decomposed to get the module as ‘customer’, the controller as ‘AccountController’ and the action to be performed as ‘indexAction()’. Checkout the AccountController file in Mage\Customer\controllers\ . You will see an indexAction() function. This is the function that is executed by the above URL request.

If the URL was http://example.com/magento/(index.php)/customer/account/login then the loginAction() will be executed.

So The front controller (the controller that receives requests from browser) “dispatches” the request to its internal list of “routers” and determines if any of the routers “match()” the request’s parameters. If so, then a new MVC Controller (‘AccountController’ in this case) is created from the matching module and, again, the request is “dispatched” to this controller object. The final MVC-style controller is technically a “Front Action” (Notice that AccountController extends Mage_Core_Controller_Front_Action).This new Action object dynamically calls one of its own action methods (‘indexAction()’) and marks the request as being “dispatched” (i.e. finished).

How the routers find a match?

The front controller has an array of “routers” that it uses to decide which module the URL should trigger. This correlation between URL and module name is defined in the config.xml files of the modules. Checkout the config.xml file of the Customer module you will see this:

Once a router has found a match of the first part of the URL to a defined frontName value from the XML, this value gets directly translated into a module name with a little adjustment to the capitalization of the words (ie. ‘customer’ to ‘Customer’) The controller and the action names are taken from the URL.

What if you only enter example.com/customer/ and not specify the controller and action you want. Find out what result you get. You will be directed to the 404 Not Found error page. How did that happen? If any value is missing, the defaults are taken from the config.xml of the Core module. If any indicators of module, controller, or action are missing from the URL the values are read from the default tag under web. By default, the CMS supplies these XML values it its own config.xml file. You can change these values by going to System->Configuration->Web.

Actions:

Actions are classes that extend Mage_Core_Controller_Front_Action which, in turn, extends Mage_Core_Controller_Varien_Action.(‘AccountController’ is an Action). A request is dispatched to an action method (‘indexAction()’). Action methods have the word “Action” appended to their names to distinguish them from normal class methods. Appending a word to the method name also helps to stop people from running unexpected methods from the URL. Imagine someone requesting example.com/index.php/customer/account/__destruct. If the system did not protect action names, the resulting method call would look something like this:

$controllerInstance->__destruct();

Something like this could potentially be a vector to open up attacks on your site. So Magento protects the action method names by appending Action to any value taken from the URL. Action and action methods are where the primary business logic for a request happens. Typically the action methods will load a model or two based on IDs or other URL parameters, kick off a few methods of these models, and then run the layout sequence.

Launch your browser and type http://127.0.0.1/magento/index.php/customer/account/login/. This should execute the loginAction() method in AccountController class of Customer module.

The Output will be as follows:

STEP ONE: (Creating the Directory Structure)

You will be creating your module in the app/code/local directory. First create a directory and call it ‘MyPackage’. This will be your new package where you can create modules. (Similar to Mage Package). Next create a directory and name it ‘MyModule’. This is your Module directory which will contain the required files like models, blocks, controller,etc..

STEP TWO: (Registering the Module)

You need to inform Magento that you have a custom module.. This is done by creating an XML file in /app/etc/modules, MyPackage_All.xml. Notice the _All in the xml file name. you can declare all of my modules here.

<?xml version=”1.0″?>
<config>
<modules>
<MyPackage_MyModule>
<active>true</active>
<codePool>local</codePool>
</MyPackage_MyModule>
</modules>
</config>

This code is used to inform Magento that there is an active module (you can turn it off from here by setting ‘active’ to false). Also that it is located in the ‘local’ code pool.

After performing this step you can check the result by going to System->Configuration->Advanced. You will see a list of available modules and in that list MyPackage_MyModule will be present.

STEP THREE: (Creating a Block Class)

Next we need to create the module. Go to the app/code/local/MyPackage/MyModule Directory and create a directory called ‘Block’. Create a php file called View.php and copy the following code:

<?php
class MyPackage_MyModule_Block_View extends Mage_Core_Block_Template {
public function myFunction(){
return “Hello World!“;
}
}
?>

We have created a simple block which contains a function that returns the string ‘Hello World’.

STEP FOUR: (Enter Config info for module)

Now we need to make a config.xml file in app/code/local/MyPackage/MyModule/etc directory. This is done to enter configuration information for the module. Copy the following contents:

<?xml version=”1.0″ ?>
<config>
<modules>
<MyPackage_MyModule>
<version>0.1.0</version>
</MyPackage_MyModule>
</modules>
<global>
<blocks>
<helloworld>
<class>MyPackage_MyModule_Block</class>
</helloworld>
</blocks>
</global>
</config>

This informs Magento of the module version. Version matters when you set up your module to be update-able. (A newer version will inform Magento to run the update files if you have them).

It also informs Magento that the module contains block files which are found in MyPackage/MyModule/Block/  directory. The class name should be “MyPackage_MyModule_Block”.

STEP FIVE: (Creating a Template file)

Now we need to create a template file which uses the View Block Class to display the message “Hello World”. Create a template (phtml) called view.phtml in the following directory: app\design\frontend\default\default\template\mymodule\view.phtml.

<div><span><strong>This is the output of the MyModule module:</strong></span><br />  <span style=”color:#FF9933;”>
<?php
echo $this->myFunction();
?>
</span>
</div>

This just outputs some HTML and also runs the myFunction() function from our block (View.php).

STEP SIX: (Using the Module)

The module is now ready for use. You can view the output by two ways.

One way is to add the following code in a cms page:

{{block type=”mypackage_mymodule/view”  template=”mymodule/view.phtml” }}

Another way is to enter it as a layout update:

<reference name=”right”>
<block type=”mymodule/view” name=”mymodule” template=”mymodule/view.phtml”/>
</reference>

RESULT:

This will be the final output of your module: