Basic Magento Directory Overview

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

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
…
<global>
<models>
<wishlist>
<class>Mage_Wishlist_Model</class>
<resourceModel>wishlist_mysql4</resourceModel>
</wishlist>
<wishlist_mysql4>
<class>Mage_Wishlist_Model_Mysql4</class>
<entities>
<wishlist>
<table>wishlist</table>
</wishlist>
<item>
<table>wishlist_item</table>
</item>
</entities>
</wishlist_mysql4>
…

Embedding HTML in the Footer

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.