Magento 2 pre-release review
Written by Matthew Cooper on December 12, 2012Tweet
Since Varien sold Magento to eBay as part of the X.commerce initiative last year the future of Magento has never looked so good. In this post I will try to address some of the questions a lot of people have by probing at the Magento 184.108.40.206 development revisions and comparing it to the current stable Magento 1.7.x. releases.
I am pleased to say that performance has been improved. Magento 2 runs notably faster than Magento 1.7 under a shared hosting environment which is welcome news to many shop owners who have been bamboozled into expensive hosting plans to compensate for the fact that the Magento 1.x iteration is a resource hog.
If you have ever debugged previous versions of Magento, you'll know all about the intensive auto loading trickery that goes on. In Magento 2 the auto loading algorithm is leaner. Probably the most noticeable change is the option of using flat file class mapping to speed up class loading. Running the following from command from the CLI auto-magically creates a serialized map of all the Magento classes and where they are located:
- php -f dev/tools/classmap/fs_generator.php ./app > ./var/classmap.ser
You can also map classes using an associative array. Note also the way to call classes using the static factory methods like Mage::getSingleton(), Mage::helper() and Mage::getModel() have undergone a slight syntax change:
- // Magento 1
- // Magento 2 - pass the fully qualified class name
These factory methods rely on the dependency injection pattern with Magento_Autoload replacing Varien_Autoload.
In a decision what will surely have most Magento programmers overwhelmed with delight, the presentation layers (.phtml view files and .xml layout files) have been combined into one place at the module level. This is especially handy for distributing extensions neatly. Views can still be overridden in the usual manner though, from the app/design directory.
One of the main objectives of Magento 2 is to discourage closely coupled modules. In plain English that simply means that removing one module shouldn't ever break the functionality of another. One of the ways Magento 2 helps us achieve this goal is by implementing the Publish/Subscribe pattern. As far as I can tell, this essentially the same thing as the Event/Observer pattern from Magento 1.
How does it work? Well, at the individual module level we can define one or more events (known as subscriptions) in the config.xml file of that module. It looks something like this:
- <!-- From app/code/core/Mage/SalesRule/etc/config.xml -->
Note that the subscription declarations point to a specific class and method from that module. Now at run time all the module config.xml files are merged into one giant xml and all the events from every module are registered in one place for global referencing. Other modules can then call these subscriber events via the Mage::dispatchEvent() method. The caller of subscription is known as the publisher.
As you can see, the Sales Module is able to communicate with the SalesRule module abstractly. They are loosely coupled.
- The base Zend Framework series 1 library stays the same but has been strangely "frankenstined" with a couple of modules from the latest v2 which are not even used. What this means is that Magento 2 does not take advantage of PHP 5.3+ namespaces.
- The resource models are no longer MySQL specific: Mage/Catalog/Model/Resource/Eav/Mysql4/Product.php becomes Mage/Catalog/Model/Resource/Product.php. In fact it appears that Magento 2 will officially compatible with MSSQL, Oracle and MySQL.
- There is a new library called Magento in the root lib folder. This library basically takes away some of the logic from the old Varien library. I guess the idea is to remove the Varien namespace completely in due time.
Magento 1 really set the bar high as far as open source shopping carts go and Magento 2 is a logical evolution rather than a game changer like its predecessor.
I like that the core team made a conscious effort to improve some of the performance issues that plagued Magento 1. I'm also a little disappointed that they haven't spent as much time innovating new features as I had hoped for. I was expecting a feature for seamless sharing of products on eBay (or MercadoLibre/Mercado Pago if you are in Latin America) for instance. Then again, maybe they will throw in some new features before the final stable release, I really don't know.
The great news is that if you are a developer and have built an extension based on any of the recent stable revisions of Magento, upgrading shouldn't prove to be such a big task after all. On the other hand shop owners need to be aware that old extensions from Magento Connect won't work out of the box.
Since release candidates should start getting rolled out within the next few months, now is a great time to start testing the waters.
I hope you found this article interesting; if you did I would love to hear from you.
Follow me on Twitter @debugthat. Thanks!