Magento's Architecture: Part 2

Modules and how they work within the system

Magento primarily works on a base of modules. All functionality is divided up into modules that make up the system overall. It's important to understand what each module does and how to go about adding modules to the system, in order to understand the architecture of modules themselves.

Distribution of the modules between directories

All modules are located within the /app/code/ directory. Directories are commonly referred to as codePools. There are three possible locations for all modules that relate to the system. They are all split by type to prevent any confusion:

  • community—For community-distributed extensions, usually those that we have installed through Magento Connect or have downloaded from a source, other than our own. Anything installed through Magento Connect will be installed here automatically.
  • core—Reserved for core Magento modules, so that we cannot directly overwrite or interfere with them. We keep our modules out of core to avoid any conflict with the core modules or any future updates. Anything from a Magento upgrade or any new Magento modules will go into this directory.
  • Local—This is where we should be placing our modules when they are either under local development or are not distributed among the community. It's best to keep anything that we develop in this directory, so as to not interfere with the core or community modules. Nothing will be automatically installed here, unless we have physically uploaded it.

Modules included with Magento

Included modules in the core folder of default Magento installation are as follows:

  • Mage_Admin
  • Mage_AdminNotification
  • Mage_Api
  • Mage_Backup
  • Mage_Bundle
  • Mage_Catalog
  • Mage_CatalogIndex
  • Mage_CatalogInventory
  • Mage_CatalogRule
  • Mage_CatalogSearch
  • Mage_Checkout
  • Mage_Cms
  • Mage_Contacts
  • Mage_Core
  • Mage_Cron
  • Mage_Customer
  • Mage_Dataflow
  • Mage_Directory
  • Mage_Downloadable
  • Mage_Eav
  • Mage_GiftMessage
  • Mage_GoogleAnalytics
  • Mage_GoogleBase
  • Mage_GoogleCheckout
  • Mage_GoogleOptimizer
  • Mage_Install
  • Mage_Log
  • Mage_Media
  • Mage_Newsletter
  • Mage_Page
  • Mage_Paygate
  • Mage_Payment
  • Mage_Paypal
  • Mage_PaypalUk
  • Mage_Poll
  • Mage_ProductAlert
  • Mage_Rating
  • Mage_Reports
  • Mage_Review
  • Mage_Rss
  • Mage_Rule
  • Mage_Sales
  • Mage_SalesRule
  • Mage_Sendfriend
  • Mage_Shipping
  • Mage_Sitemap
  • Mage_Tag
  • Mage_Tax
  • Mage_Usa
  • Mage_Weee
  • Mage_Wishlist

Setting up the folder structure of a module

Let's presume that we want to set up a module's folder structure, ready for development. Our module's core folders will be placed in /app/code/local/Book/Example/.

These folders will primarily be used for storing our code that makes the module work. The folder structure breaks down as follows:

  • Block/
  • controllers/
  • etc/
  • Model/
    • Mysql4/
    • Book/
  • sql/
    • book_setup/

Typically, developers will pick or choose each folder, depending on whether or not they're going to use it within their module.

Note that Model/Mysql4/Book/ has its first letter in uppercase, whereas sql/book_setup/ does not. We must be sure to keep this the same way throughout our development.

Template files for the frontend of our module will be stored as follows:

  • XML files will be stored in /app/design/frontend/<interface>/<theme>/layout/example/
  • Output files will be stored in /app/design/frontend/<interface>/<theme>/template/example/

Any admin template files for the frontend of our module will be stored as follows:

  • XML files will be stored in /app/design/adminhtml/<interface>/<theme>/layout/example/
  • Output files will be stored in /app/design/adminhtml/<interface>/<theme>/template/example/

Here's a breakdown of what each folder is for:

  • Block/—For processing of all display blocks called by the system for the module. These are controllers that will be called in the XML layout files within a theme, in order to display something.
  • controllers/—Our controllers that support the application and structurally keep things together.
  • etc/—Configuration files for the module, for declaring things such as the default options when installed and declaring all blocks, models, and install/upgrade actions.
  • Model/—For placement of all models to support controllers in the module.
  • sql/—SQL actions when the module is installed/upgraded/uninstalled.

Zend Framework and its role within Magento

Magento (at its raw PHP base) is built on the Zend Framework. From the database class to the handling of URLs, Magento is in its raw form, with Zend Framework doing all the work. Alongside this, Varien has built several core modules on top of the Zend Framework, in order to tie it altogether into the system as we know it.

What is Zend Framework

Zend Framework's official site best describes the framework as follows:

Zend Framework (ZF) is an open source framework for developing web applications and services with PHP 5. ZF is implemented using 100% object-oriented code. The component structure of ZF is somewhat unique; each component is designed with few dependencies on other components. This loosely coupled architecture allows developers to use components individually. We often call this a "use-at-will" design.

While they can be used separately, Zend Framework components in the standard library form a powerful and extensible web application framework when combined. ZF offers a robust, high performance MVC implementation, a database abstraction that is simple to use, and a forms component that implements HTML form rendering, validation, and filtering so that developers can consolidate all of these operations using one easy-to-use, object-oriented interface. Other components, such as Zend_Auth and Zend_Acl, provide user authentication and authorization against all common credential stores. Still others implement client libraries to simply access to the most popular web services available. Whatever your application needs are, you're likely to find a Zend Framework component that can be used to dramatically reduce development time with a thoroughly tested foundation.

How Zend Framework works

The Zend Framework (at its core) is designed to be used as a package or separate modules. This (among other features) makes it unique, as most other frameworks are designed to be used plainly as frameworks or not at all.

However, the Zend Framework comes with classes that allow us to use it as a standalone framework and develop with it as one. Instead of being delivered with a preset amount of directories and layout for developers, it only suggests a layout for our files. This means that we can adapt the framework to meet our current workflow and choose how much we adapt the workflow to fit the framework.

It's role and effect in Magento

The Zend Framework allows Magento to focus on the core issues at hand. It removes a lot of the work on the database and core structural classes and puts the work towards fixing and adding to core modules of Magento.

Most importantly it gives developers a standard approach to development that they can move across and apply to Magento. The standard development practices help greatly in adopting Magento as a platform and make it easier for developers having experience with Zend Framework to adapt to Magento.

More information on learning the Zend Framework and resources can be found at the back of this book in the Appendix attached. Its official site is located at:

Backing up Magento's data

It's important to know how to back up our site, to ensure that our installation's data is not lost (if ever things go bad).

It is recommended to back up our Magento installation:

  • Regularly as a base to ensure that there are incremental backups of our system
  • Before installing new modules or themes from Magento Connect
  • When developing modules
  • Before upgrading our system

Backing up the files

We will need to back up all the files relating to the Magento installation, when backing up our system. Two of the ways in which this can be done are given below.


Manually, we are able to download all the files of the installation to our hard drive. This is the longest method of backing up the files and is the most foolproof method available.

Using SSH

Using SSH, we're able to vastly speed up the duration of backing up the servers. We can do this in two ways:

  • Zipping up all files, if the server has it enabled
  • Copying all files to another directory

Both of these depend on whether or not our server has SSH. So if this isn't available to us, then we cannot use these methods.

Both of these methods require us to connect to our server via SSH first and then use the cd command to get to the directory (which Magento is installed in), before running the commands.

Zipping up all files

This will create a zip file of our entire Magento installation's files and folders called

tar cf magento_archive.tar *

To untar this archive, extract the files afterwards:

tar -xvf yourfilename.tar

We can then move this to another directory of our choice using the mv command:

mv /path/to/new/destination/

Copying all files to another directory

We run the following command to copy all files (as they are) into another directory on our server. We'll replace the full path with the path to the desired directory, into which we want to copy all the files.

cp –R * /path/to/new/destination/

Backing up the database

We'll need to back up the database as part of our Magento backup. Let's go through how.

Using the system itself

Magento comes with a built-in method for backing up our installation and keeping several backups logged, in case we want to download older backups at any time. It can be found in the System menu under Tools:

Magento 1.3: PHP Developer's Guide

The initial screen will be similar to the next screenshot:

Magento 1.3: PHP Developer's Guide

To create a backup via the System panel, all we need to do is click on Create Backup in the upper-right of the screen and wait for it to finish:

Magento 1.3: PHP Developer's Guide

The process of creating a backup can take quite a while (especially for bigger databases), so we will need to keep an eye on our server's memory limits and PHP execution limits. These are set in our .htaccess file on runtime, but some servers will only run the defaults and not allow them to be overridden. If we encounter a white screen instead of the success message (shown in the previous screen), then the problem is either memory limit or execution time limit. We will need to increase them ourselves or contact our web host.

Once the backup is completed, however, we'll be able to find it in our /var/backups/ folder. They will be named by timestamp and the highest numbered filename will be the last to be backed up.

Using phpMyAdmin

The most common back up solution is phpMyAdmin, and some people prefer it over any built-in method. To export via phpMyAdmin, we:

  1. Navigate to the database
  2. Switch to the export tab
  3. Select all tables and SQL as the export type
  4. Under options on the right-hand side select Disable foreign key checks
  5. Select save as file at the very bottom of the page
  6. If we want to match the compression type of Magento's output, select gzipped as our compression method
  7. Click the Go button to export

This will give us an SQL file, which we can then import at a later date back into an empty database and restore our data.


In this article, we've learned the following:

  • How Magento's folder structure and files are laid out
  • What each of the base directory's folders and files do
  • How the template system works
  • How modules work within Magento
  • About the Zend Framework and how it benefits Magento
  • How best to go about backing up Magento and when to go about it


[ 1 | 2 ]

If you have read this article you may be interested to view :

You've been reading an excerpt of:

Magento 1.3: PHP Developer's Guide

Explore Title