Solving Magento

Solutions for Magento E-Commerce Platform

by Oleg Ishenko

Magento EAV System

The following is a collection of my experience with the EAV system in Magento. It contains all the facts I needed early on in my Magento developer career. Being a reflection of a personal experience it may be incomplete, obscure, or overladen with details. Please comment if you have a suggestion on how to improve it. If you need a clarification on some part of the text below, please ask. If there is an error – point it out. Thank you!

The EAV system is one of the most complex part of Magento shop software. It is also the most controversial and often cited as a root of performance problems in shops that have to handle large and complex product databases. When developing Magento extensions these problems can be exacerbated by failure to properly use the EAV implemented in Magento, which often happens due to a great effort that is required to understand it. For me, as probably for many other Magento developers, it has been a lot of lessons learned hard.

Before diving into details of the Magento’s EAV, it is necessary to learn a bit about the origins of EAV and its general principles. EAV has quite a long history. Some of its earliest applications were storage systems for clinical data back in 1970s. As a storage method EAV borrows from early object-oriented languages. SIMULA 67 is cited as one such influence. Functional languages such as LISP are also known to have contributed to the development of EAV. They contain storage structures that record object information in attribute-value pairs – a principle fundamental to EAV.

Continue reading

Magento Routers: a Look under the Hood

Magento Routing

The centerpiece of Magento, the Front Controller, can sometimes be a challenge for a beginner Magento developer. Just a few years ago most PHP applications where collections of scripts, which were supposed to be accessed by their own URL to perform their function. The MVC and Front Controller patterns change this approach by letting one object to handle all requests. Front Controller instantiates objects, fires events and sets up the application behavior according to the received request. This is a significant paradigm shift that can be a source of much confusion. The purpose of this article is to explain how request dispatching works, how router configuration is compiled and read, and how router settings can be configured.

Routers explained

A quick look into Magento .htaccess file reveals that most requests are routed to the index.php, the one in the root folder of your application. Exceptions are requests for which a matching resource (folder or a file) can be found. To process a typical request Magento calls a Front Controller, an instance of Mage_Core_Controller_Varien_Front class. While being initialized the Front Controller reads router configuration collected from all the config.xml files and builds its router collection. By the point the request is passed to it for dispatching the Front Controller has all the information required to find a matching controller.

You can define routers for your modules in their respective config.xml files. This is also the way the core modules define their routers. Routers can be defined for front end as well as for back end functions. Looking through the config.xml files available for your default installation of Magento we can derive a general structure of a router configuration.

Continue reading

Theme: Esquire by Matthew Buchanan.