Although we might have thought that all resources would be focused on the next major version (officially announced during Developers Paradise 2011), in fact Magento’s developers have continued to announce major new functionalities for Community 1.6 and Enterprise 1.11. Judge for yourselves...
Support for multiple databases
In the past, Magento supported a single database handler: MySQL. But Magento versions 1.6 and 1.11 can now also support Oracle and MS SQL databases. This strategy aims to allow administrators and companies that have invested in these technologies to capitalise on their assets and thus to reduce their training requirements. This support was obtained through an ingenious overhaul of the Magento persistence layer, which once again provides evidence of the application design skills of Magento’s development teams. This overhaul makes it possible to factor the code for all handlers and to only have to manage the differences in Helper that are specific to each of them. For existing applications, the transition should be transparent.
Return merchandise authorisation (RMA)
This functionality should make a number of our clients very happy, although it is limited to Magento’s Enterprise Edition. It enables configurable management of the returns authorisation workflow, providing each merchant with a Magento back office in alignment with their returns process.
More advanced integration of transporters (particularly UPS and DHL) allows for printing of transport labels.
This term may seem off-putting but it remains a very strong point: it means that customers can access their shopping carts and their list of preferred products and that the merchant can use segmentation functionalities without identifying the customer and this from multiple types of devices (Android, PC, etc.).
Magento 2: the future
Although the announcement of Magento’s acquisition by eBay aroused substantial interest, it did not eclipse the other major announcement during the conferences on Magento 2. At this stage in the project, all announcements naturally remain to be confirmed.
Vendors need good reasons to embark on the development of a major new software version. This is all the more true when the application in question is very large in scale. Thus Magento’s team has set a number of goals:
- to improve the architecture, particularly by significantly reducing the coupling between the different modules and by rewriting a portion of the data persistence layer;
- to enhance performance: often seen as a Magento Achilles heels, the team reports that performance has already been improved by 20% at this early stage of development;
- to reduce the time for technical skills upgrades: the other weakness of Magento according to many developers; Magento 2 should simplify developers’ lives, particularly in respect of application design;
- to test the code: the new size of the project requires the use of automatic testing; thus the team is establishing automatic unit, functional and performance testing;
- to ensure transparency in the development process: Magento should soon be providing read-only access to its project management tool, which should make it possible to track progress and backlog on the application, thus resulting in true visibility of the progress and modifications made.
What does this mean in concrete terms?
Magento 2 will be based on a number of new language functionalities and therefore is expected to be incompatible with earlier versions of PHP. This will pertain in particular to the use of PHP 5.3 namespaces.
The development has not finalised anything on this point to date. In fact, the release of a stable version of Zend Framework 2.0 has been pushed back on several occasions. The team does not preclude the possibility of including it, on condition that its actual release date is compatible with the project calendar. Otherwise, Zend Framework 1.x will continue to be used.
Magento 2 is expected to abandon Prototype in favour of jQuery. Over and above any question of clique wars, in my opinion this is first and foremost a practical choice stemming from the greater popularity of the latter, as a result of which it is easier to find resources skilled in jQuery than in Prototype.
Design: template legacy and drag and drop modes
Magento 2 should introduce a few new features in design management, including template legacy (a welcome addition) and the ability to use a drag and drop mode for page building (a functionality already available in Magento Go).
Persistence layer overhaul
Amongst the modifications expected to have the greatest impact on how we work with Magento 2, the most important is undoubtedly the overhaul of the data persistence layer, which should be heavily based on ORM Doctrine (the development team has even considered including the latter).
Object loads and saves are respectively performed via:
With Magento 2, it looks like the developers are moving toward the creation of an entity manager responsible for object persistence. The above code might then become:
$object = $entityManager->load($type, $id)
These are major changes with substantial potential impact for other developers like us. However, the architectural logic extolled by Magento’s developers needs to be understood in order to fully appreciate it. In the current version of Magento, the Model-Resource-Collection trio must be set for each model. With the new set-up, only the ‘Model’ class will remain. This should considerably reduce the complexity of the Magento model.
From an architectural perspective:
- the model layer will now only implement the functional logic of the models; and
- the persistence layer will be an isolated application service provided by the entity manager.
This simplification should nonetheless present a number of drawbacks compared to the current system, the largest one undoubtedly being the presumed obligation of declaring all persistent fields in the models.
Modular interdependence should be substantially reduced in Magento 2. The stated goal is to be able to pick and choose which Magento modules to use and not to use. To achieve this, the current modules will remain intact but will need to be encapsulated in higher level sets called ‘components’. Modules may then only be dependent on other modules in the same component. Inter-component dependence will then be attached to this model.
This should make it easier to identify the various couplings within the application. Further, the team is currently working to identify strong couplings in the application that are not absolutely necessary and that could be replaced by weaker links. One of the lines of their work is to reduce direct calls between modules as far as possible, through heavier reliance on observers.
This major version of Magento should be available in late 2012, with an earlier alpha version release. The changes are expected to substantially modify how we work, without however challenging the main principles behind the Magento solution. From what we know today, this will be more of a practical refactoring than a complete rewrite.