Magento Developer's

Basic Magento Directory Overview

Md. Shafiqul Islam — Mon, 28 Sep 2009 12:21:48 +0000

Important Paths

/ -Directory Root

/app – This is where all the php code for the application resides

/lib – The external code library.

/skin – This is where css and other images reside

That’s the quick overview.

/app

/code – Where all modules reside

/design – Contains both layout xml files and template .phtml files

/etc – Global configuration

Mage.php – Static class Mage, where everything is held together.

Before I move on to the other two directories (/lib, /skin) I’ll explain the directories in this (/app) dir.

/app

/code

/community – Downloaded modules built by Magento community members

/core – The core modules ‘out of the box’ build by Magento

/local – Any module we build ourselves

Within these three subdirectories we find the /Mage directory. This is where all the modules should reside. Also, upon startup Magento includes the paths

/app/code/core/ and
/app/code/local.

So, by default the system has access to those directories. Now here is the trick: If we create a module ‘RandomModule’ and within that model we create a ‘/model’ directory, we must follow a convention for every class we put inside that folder. For instance a class would be named the following:
class Mage_RandomModule_Model_SomeClass extends Varien_Object { }

With this convention we can call this class anywhere from within the application. Magento will take the name, replace underscores with forward slashes, include that file, then load the requested class, and return an instance of that class. Pretty cool.

As for the individual modules, you will see a directory pattern that all follow, it is pretty simple there. I have noticed that Magento likes to separate their model. For instance, there will be a directory that will ONLY contain classes/methods that query the db and return results. They follow that pretty strictly, I never see methods access db from within a model that is not dedicated to db access. They do that in their practice, we are not forced to do so, but I have tried it, it makes a lot of sense to me.

Thats pretty much it for the /app/code directory for now

/app

/design

/adminhtml -Admin designs

/frontend – Front End designs

/default -This is the default Interface, we can create other interfaces

/default – This is the default theme, we can also create multiple themes

/layout – Contains all the layout xml files

/template – Contains all the template .phtml files

Here, we can create multiple interfaces and themes within each interface. From the admin page in a browser, we assign a theme to each website or store. The power here is that we can create multiple themes, such as spring, christmas, or whatever, then they can be enabled and disabled by a simple click from the admin panel.

This interface/theme pattern is used again in our /skin directory from the root. This assures that when the administrator switches an interface or theme, the appropriate css sheets will be applied.

Also, very cool to me.

Lastly, lets overview the /skin directory from the root directory.

/skin

/adminhtml – Admin styles directory

/frontend – frontend styles directory

/default – Our default interface

/default – Our default theme

/css

/images

/js

Notice the correlation of the /skin directory to the /app/design directory.

To create a new interface or theme, we MUST make a new interface or theme in both of these directories or there will be mayhem!

That’s the basic directory structure overview.

Models and ResourceModels

Md. Shafiqul Islam — Mon, 28 Sep 2009 12:10:44 +0000

AllMagento models extend the base Mage_Core_Model_Abstract class. This class helps any model save itself to the database in a straight property-to-column name manner.
The model, when saving, calls up its own resource singleton and passes itself ($this) to the resource’s save method. The resource is then scripted to collect any values from the model’s internal _data array and prepare an insert or an update statement with those values.

Model’s have a _getResource method which retrieves a previously setup resource.This resource is initialized by the init method using a resource name of the pattern module_name. The name portion of that pattern represents the final portion of a class name. The prefix of the class name is specified by a portion of the XML in the module’s etc/config.xml. If class names have the term Mysql4 in their names, they are generally straight model resources.

If the word Entity appears in the class name, then the resource is an EAV Entity. Let’s look at the Wishlist module as an example. In the config.xml of the wishlist modulewe see a resourceModel tag under themain definition of models. The value of this resourceModel tag points to another XML tag under the models tag. The class tag of this new definition specifies the class name prefix for any resource of this module. The following code shows how the sample XML file would produce a resource for the wishlist module.

$wish = Mage::getResourceSingleton(’wishlist/wishlist’);
echo get_class($wish);
//outputs: Mage_Wishlist_Model_Mysql4_Wishlist
…

Mage_Wishlist_Model
wishlist_mysql4

Mage_Wishlist_Model_Mysql4

wishlist

wishlist_item

…

Embedding HTML in the Footer

Md. Shafiqul Islam — Mon, 28 Sep 2009 11:35:41 +0000

Often online merchants need to embed code in the site footer to integrate with 3rd party services such as analytics, affiliate programs, tracking codes, etc. Instead of modifying each template manually, Magento offers a quick and simple way to introduce such 3rd party javascript code to the templates directly from the admin interface.

Misc Code

To do so, locate the Miscellaneous HTML box under System>Configuration>General>Design>Footer. Paste the code directly in the box and save the data. Make sure to refresh Magento’s cache in full under System>Cache Management.

Once completed, the embedded code will be available on your store.

Resources and Database Connections

Md. Shafiqul Islam — Wed, 23 Sep 2009 05:09:04 +0000

The role of a resource in Magento is to manage database connections. Resources are defined under the global XML tag of any config.xml file. To make a new database connection you would add XML like the following to any config.xml file. Each resource has a name of the form module/name and each connection has a name. Connection names are generally of the pattern

module_read,
module_write,
or module_setup.

localhost

magento
mysql4
SET NAMES utf8
pdo_mysql
1

….
The format should be mostly self explanatory, most of these values end up being passed to the Zend_Db_Adapter_Abstract class. The initStatements tag is executed upon every connection to the database server. The model tag seems unnecessary, perhaps it was part of an idea that didn’t pan-out completely. The type tag refers to one of two connection types defined in the global app/etc/config.xml file. Only pdo_mysql and mysqli are implemented at the moment.

To retrieve a Magento database connection we must first get a resource. If you require a generic database handle, you can use the name core/resource for the resource name, and core_write for the connection name. The Mage::getSingleton method keeps track of all classes loaded through it as singletons and returns a previously initialized object if the name matches. Each module may have its own database settings – usernames and passwords – or it might even be connecting to a separate database server, so be sure to use the most appropriate resource name when you can. In a default setup, all of Magento’s connections use the settings of default_setup, default_write, or default_read.

$write = Mage::getSingleton(’core/resource’)
->getConnection(’core_write’);
if ($write instanceof Zend_Db_Adapter_Abstract) {
echo get_class($write);
}
//outputs: Varien_Db_Adapter_Pdo_Mysql

Database Design

Md. Shafiqul Islam — Wed, 23 Sep 2009 05:04:36 +0000

Magento’s database design is one of its most controversial aspects. Key data aremodeled using the Entity Attribute Value method (EAV). Utilizing an EAVmodeling pattern allows for unlimited attributes on any product, category, customer, or order, but EAV also depletes a programmer’s ability to write ad-hoc queries against the data. Before we delve deep intoMagento’s database design, we will look at the basic way of communicating with the database – the resource.

Actions

Md. Shafiqul Islam — Mon, 14 Sep 2009 10:51:04 +0000

Actions are classes that extend Mage_Core_Controller_Front_Action which, in turn, extends Mage_Core_Controller_Varien_Action. Actions also have a dispatch method, but this method dispatches the request to an action method. 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.

But, I digress,Magento does protect the action method names by appending Action to any value taken from the URL, so this argument is purely academic.
During the dispatch event, the preDispatch method is called, and following the actual execution of the action method, the postDispatch method is called. By default, the postDispatch will save the current URL into the user’s session as the last URL visited.
Action and action methods arewhere 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. Having the action methods be responsible for outputting their own layout is an important issue to understand. This makes it more difficult to integrate with other systems, as you cannot as easily supplant your own layout or templating methods after executing the business logic. Also, it does not allow for any “post dispatch” logic to make any alterations to the output.

Routers

Md. Shafiqul Islam — Mon, 14 Sep 2009 10:49:37 +0000

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. The controller and the action names are taken from the URL as diagrammed above. If any value is missing, the defaults are taken from the core XML config via the getDefault method. When specifying a URL, you don’t always specify exactly which module, controller, and action you want to run. A request to example.com/customer/ does not fully specify which controller of the customer module, nor which action to run. If any indicators of module, controller, or action are missing from the URL the values are read from the default tag under web, then under front (default/web/front).

By default, the CMS supplies these XML values it its own config.xml file. You can change these values in the administrative back-end under the menu items System > Configuration > Web. If the XML values happen to be completely missing, the fall-back values of core, index, and again, index are used for the values of module, controller, and action, respectively.

The Front Controller

Md. Shafiqul Islam — Mon, 14 Sep 2009 10:48:44 +0000

From here, the responsibility transfers to the front controller. 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. The available routers are:
• Standard
• Admin
• Default (only used for 404s)
The definition of a match between a router and amodule looks like this for the Customer module:

standard

Mage_Customer
customer

The AppModel

Md. Shafiqul Islam — Mon, 14 Sep 2009 10:47:56 +0000

The “App” model is the main kickoff point for the execution path of any request to Magento. Although the Mage class is important for loading all sorts of classes and configurations, the execution path starts and ends inside the App. The App is responsible for:
• Initializing the system cache
• Instantiating the default front controller (Mage_Core_Controller_Varien_Front)
• Instantiating the default request object (Mage_Core_Controller_Request_Http)

Magento’s Request Cycle

Md. Shafiqul Islam — Mon, 14 Sep 2009 10:45:10 +0000

Now we will discuss how a browser request to a URL gets translated into module execution. Generally speaking, any URL can be deconstructed like this:

Magento’s request cycle can be a little confusing to trace through. This is mostly due to the hierarchical nature of the file nesting (routers located under controllers) and the use of the term “dispatch” to mean 3 different things. The front controller “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 (not front-controller) 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”, it houses a number of methods that define the business logic tier.
This new Action object dynamically calls one of its own action methods and marks the request as being “dispatched” (i.e. finished). All these uses of “dispatch” are still different from the event mechanism’s dispatchEvent() method.