The way classes are named in Magento was taken from the Zend Framework, upon which Magento was developed.
Class names are standardized depending on their location on the file system. This standardization enables automatic class loading. The Magento autoloader is built in /app/Mage.php. Because class names are directly related to a specific path in the file system, the autoloader allows developers to include them without using include_once or require_once. A class named Mage_Page_Helper_Data, for example, would be found at /app/code/core/Mage/Page/Helper/Data.php
Themes allow you to control the look and feel of your Magento installation and the stores it contains. Related themes are grouped together in design packages, and each store in your installation can use its own theme, share a single theme, or any combination of each. The “base package” is the default design package (a collection of related themes) installed.
The files that determine the visual output and frontend functionality of your store are contained inside the themes in a design package. Each design package must contain a default theme and can contain any number of theme variants.
Themes are found in two main directories in the Magento file system:
app/design – control how the pages are rendered
skin – control the visual aspect of the theme (CSS, images, etc)
Layout – the basic XML files that define block structure and control meta information
Template – contains the PHTML files containing xHTML markups and the PHP for visual presentation (both page and block templates)
Locale – CSV documents with language translation strings for non product and category text within Magento
CSS – the CSS files for the theme
Any files not customized by a particular theme are pulled from the default theme and base package, allowing developers to localize their themes by changing or adding only those files necessary for a custom theme.
If a custom theme is specified, the application looks in:
If the file is not found in the custom theme, the application looks in
If not found in the default, the application looks in
If not found, an error occurs
Magento’s Action Controller does not pass a data object to the view or set properties on the view object but rather directly references system models to get the information it needs for display. The view is built by the combination of Blocks and Templates. Blocks are PHP objects, and Templates are PHP/HTML files. Each Block is tied to a single Template file. Inside a phtml file, PHP’s $this keyword contains a reference to the Template’s Block object.
The Magento application contains 3 codepools. Core is reserved for the base classes written by the Core Magento developers. When you want to extend or change the functionality of these classes, you do so by over-riding these classes in your code located in one of the other 2 codepools. Changes to code should never be made in the Core codepool because they may be lost when Magento is upgraded. The Community code pool is where third-party modules, such as the ones downloaded from Magento Connect, can be found. The Local codepool is where any other kind of modification, extension or core (or community) overrides should take place. The Local code pool is loaded first and is the place for changes that need to be made to a specific site or to modify/extend/override what is in the Core or Community codepool.
During the bootstrap, Magento first checks the local codepool for include files, then checks community, and then core. Magento reads a module’s configuration file, looking in the block, to notify the system where to find module code. The module’s configuration file is located in /app/etc/modules.
/app/Mage.php defines the pathing for the three code pools.
Sometimes when you install an extension and go to your Magento site you get a 503 error with a message saying your system is in maintenance mode. Often times the culprit is a file called maintenance.flag which should have deleted during installation and didn’t. Browse to your root Magento folder and delete that file. Voila! Magento is up and running again.
The most commonly used core block types used in Magento layouts
core/template: This block renders a template defined by its template attribute. The majority of blocks defined in the layout are of type or subtype of core/template.
page/html: This is a subtype of core/template and defines the root block. All other blocks are child blocks of this block.
page/html_header: Defines the header part of the page which contains the site logo, top links, etc.
page/template_links: This block is used to create a list of links. Links visible in the footer and header area use this block type.
core/text_list: Some blocks like content, left, right etc. are of type core/text_list. When these blocks are rendered, all their child blocks are rendered automatically without the need to call thegetChildHtml() method.
page/html_wrapper: This block is used to create a wrapper block which renders its child blocks inside an HTML tag set by the action setHtmlTagName. The default tag is <div> if no element is set.
page/html_breadcrumbs: This block defines breadcrumbs on the page.
page/html_footer: Defines footer area of page which contains footer links, copyright message etc.
core/messages: This block renders error/success/notice messages.
page/switch: This block can be used for the language or store switcher.
Insert blocks into the config file with this syntax:
Magento is a shopping cart application written in PHP with an MVC style architecture. Model-View-Controller applications aim to separate the representation of information contained in the database from the presentation of that information to the user. This architecture pattern leads to increased reuse of code within an application, simplification of design, and ease in maintenance (separation of concerns). The model contains business rules, application data, logic, and functions. The view generates the display of the application data to the user. The controller passes information between the view and the model. Each model in the application separates an area of functionality from others.
To extend the functionality in your Magento, you can create custom modules to do nearly anything you desire. Your custom changes should *never* be placed in the core code so you don’t lose them when you upgrade. Magento contains 3 code pools (groups of modules): core, community, and local. Your modules should be placed in community (if developing for use on multiple magento instances) or local (if developing for your single magento installation).
Namespace refers to a folder used to group similar modules together. What you place in your custom module can override what is in the core or can extend the core with altogether new functionality.