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: http://framework.zend.com/.

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