Magneto has three different type of codepools: A) Core, B) Community & C) Local. This three codepool working in same manner but priority of module include paths are different for them. Let’s take a look at app/Mage.php,
$paths = BP . DS . 'app' . DS . 'code' . DS . 'local'; $paths = BP . DS . 'app' . DS . 'code' . DS . 'community'; $paths = BP . DS . 'app' . DS . 'code' . DS . 'core'; $paths = BP . DS . 'lib'; $appPath = implode(PS, $paths); set_include_path($appPath . PS . Mage::registry('original_include_path')); include_once "Mage/Core/functions.php"; include_once "Varien/Autoload.php";
This code snippet illustrates the order Magento is using to include paths – firstly it includes Local code pool, than community and after that – core, which allow developers to override classes without changing core files.
First of all, this folder stores all the code that makes Magento so strong. The chief rule of Magento development is that you should never make any changes in it. In other words, this folder belongs to Magento core developers only and it’s strongly recommended that you are not going to edit anything in this pool.
This folder belongs entirely to community developers. This is the right place for hundreds of 3rd party extensions, both free and paid, that can be found at MagentoConnect or available on extensions development store. If you have installed any extension, it must be in app/code/community/ only.
If you have your own Magento-based store and want to make everything by yourself or you are a Magento developer and have a purpose to change the logic somehow, local pool is the place where everything should be done. If you want to override Magento extensions, blocks or methods, copy the necessary folders from the Core pool and do whatever you are inclined to do. Apply the same rule for custom extensions that are created specifically for the website – all code should be in local pool.
Magento organizes its code into individual Modules. In a typical PHP Model-View-Controller (MVC) application, all the Controllers will be in one folder, all the Models in another, etc. In Magento, files are grouped together based on functionality, which are called modules in Magento.
Magento is a configuration-based MVC system. The alternative to this would a convention-based MVC system.
In a convention-based MVC system, if you wanted to add, say, a new Controller or maybe a new Model, you’d just create the file/class, and the system would pick it up automatically.
In a configuration-based system, like Magento, in addition to adding the new file/class to the codebase, you often need to explicitly tell the system about the new class, or new group of classes. In Magento, each Module has a file named config.xml. This file contains all the relevant configuration for a Magento Module. At runtime, all these files are loaded into one large configuration tree.
This folder liability is View, if we use terms of classical MVC architecture. Blocks coordinate models with the template files. The files in the folder load the data from database and transfer it to the templates in theme(.phtml)
Controllers represent all business logic actions for the given request (dispatch(), preDispatch(), postDispatch() methods) and delegate commands to other parts of the system.
It contains all xml files that declare and configure behavior of all modules. Each module must have at least config.xml and it’s a right place to declare all models, routers, blocks, helpers, etc.
Optionally this folder could have adminhtml.xml (grant permissions for your tabs/sections in backend menus) and system.xml (creates this new section or specifies where it should be displayed in existing one).
Here we can create methods that would be useful for our store in different ways. Helpers contain utility methods, which are commonly used in the whole system. Methods, declared in helpers, can be called from any template file or block, model, controller class by
Each Module has a default Data Helper class Modulename/Helper/Data.php!Developer Guide for Magento Module Structure and CodePool,