In-depth Analysis of New Magento2 Development Updates

A couple weeks ago, Magento and its team of engineers hosted a webinar on Magento2 development updates, which showcased the progress that has been made so far on Magento2 development, as well as what developers, merchants & solution/industry partners could expect from its eventual launch. Listening in on the webinar I gained some pretty interesting insights on theme and layout customization, code decoupling, dependency injection, new PSR coding standards, and the new testing infrastructure. But what does this all mean? This post will highlight and analyze the various development updates for Magento2 and what it will mean for the global Magento Community. Let’s get started.

Magento2: 3 years and counting…

Magento2 is an ambitious project with some lofty goals:

  • Clear processes and transparency
  • Improved product quality
  • Improved performance and scalability
  • Improved product security
  • Enhanced Modular architecture
  • Improved coverage of Web APIs
  • Simplified customization process and learning curve
  • Improve Multi-language support
  • Improve education and product documentation for merchants and developers

For full details of the project, please visit:

This means that most of the core and extensions have been re-factored or even completely rewritten; and needless to say, this has proven to be a major challenge for the Magento and Magento2 team; since it has been under development for the last 3 years and because of this a lot of the initial excitement from the community has died down.

In an effort to keep the community involved with the project, Magento2 code was made available on Github in 2011, unfortunately this initial commitment by Magento was followed by long periods of inactivity, some of which extended for several months at the time, causing the interest in Magento2 to die down again.

Jokingly developers have started referring Magento2
as the “HalfLife3 of eCommerce”.

With that said, Magento has finally decided to crank up Magento2 development, and the Magento2 team has been working hard since October releasing new code almost every week. And let me tell you, I’m excited (and a bit scared) for the changes coming in Magento2.

So what’s new with Magento2?

A year ago I posted about all the new changes coming to Magento2, and there has been a lot of progress and changes since then. One of the big take aways from the recent webinar was the focus that has been put into updating Magento to use the latest technologies.

1. Prepare to update PHP

This new release will only be compatible with PHP 5.4 or higher. This in itself is a huge change. So far, Magento has only officially supported up to PHP 5.3, and while attempts to run Magento1.x on newer versions of PHP have been moderately successful, there are a variety of well known bugs and issues.

Why am I excited about this?

Well there are many reasons to be excited about Magento supporting PHP5.4/5.5, but the following are particularly interesting:


  • – Built-in development server in CLI mode.
  • – Support for traits.


  • – Integrated OPcode caching with the OPcache extension.
  • – Numerous improvements to the GD library.

While the cli webserver is not 100% functional with Magento2 and might never be, the other features on the newer versions of PHP are more than enough to get developers excited.

Traits you said, what the hell are traits?

If you haven’t been following the latest developments in the PHP world, you might not know what traits are, or why they can be extremely useful. PHP implements a single inheritance model, this means that a class might only extend from only one class.

Languages like C++ and Python allow to inherit from multiple classes, Ruby in the other hand uses mixins to include functionality from multiple classes without actually using inheritance.

PHP5.4 introduces traits, the concept itself is nothing new and is used in languages like Perl and Scala; traits allow us to reuse code horizontally across different classes in different hierarchies.

When thinking about traits, it helps to conceptualize them as interfaces with implementation. If you don’t know what an interface is, you shouldn’t be reading this blog post.

At the time of writing this post, Magento2 doesn’t implement traits at all. However the option is still available for developers to implement it inside their extensions and custom code.

2. Old Man PHP5.3

Let’s not forget that Php5.3 is now 4 years old and its starting to show its age, specially when talking about performance the newer versions of PHP are much faster and can run circles around PHP5.3.

To put this to the test, I downloaded the script from and ran it against PHP5.3, PHP5.4 and PHP5.5.

PHP version : 5.3.28
test_math : 1.478 sec.

test_stringmanipulation : 3.125 sec.

test_loops : 1.391 sec.

test_ifelse : 0.954 sec.

Total time: : 6.948 sec

PHP version : 5.4.23
test_math : 1.256 sec.

test_stringmanipulation : 2.868 sec.

test_loops : 1.057 sec.

test_ifelse : 0.650 sec.

Total time: : 5.831 sec

PHP version : 5.5.7
test_math : 1.068 sec.

test_stringmanipulation : 2.050 sec.

test_loops : 0.945 sec.

test_ifelse : 0.591 sec.

Total time: : 4.654 sec

Now the previous tests are by no means meant to be extensive and thorough, more than anything they are designed to give us a general idea about each version’s general speed and performance.

Personally I would go for PHP5.5 directly, since it seems to be a bit faster and has a build in OPCode cache system.

Related Reads
PHP 5.4 Benchmarks
PHP Roadmap & Performance

3. So long Mage::

Magento2 introduces many changes in its application structure and Magento2’s internal functions, but the most noticeable change is the removal of the Mage god class.

Many developers are scratching their heads trying to understand why Magento is removing the use of the god class, after all, as developers use this to call factory methods like Mage::getModel, Mage::getSingleton, Mage::helper, and so on.

While having a god class might be convenient it also brings up several issues, like having larger (and harder) dependencies across the application, this increases the code complexity and makes it impossible to figure out class dependencies without inspecting the source code.

With Magento2 there is a greater effort being made to improve the code quality, and reduce the code complexity. The disappearance of the Mage class also means that the factory methods and class names are gone with it.

This is going to have a significant impact on the way developers are used to working with Magento; for example let’s use the Product class and more specifically, the class constructor as an example while in Magento1.x it currently looks like this:

In Magento2 we have some more like this:

Now, at first glance the Magento2 code might look worse just by the sheer amount of code compared to the current version, but if we play closer attention, we can see that what is actually being done is a technique called dependency injection.

In this case, all the class dependencies are being declared as as formal arguments inside the class constructor and assigned to the object state. We can also see that the namespaces are being used when declaring the dependencies in the constructor attributes this was done in accordance of the PSR Standards, which we will look into later down in the post.

So whats Magento2 trying to achieve with this kind of refactoring?

  • Dependencies of a class become immediately obvious just by looking at the class
  • Dependencies can be determined automatically when using class reflection
  • Dependencies can be injected automatically by using a dependency injection container or framework
  • Respecting a true OO (Objection Oriented) design
  • Sticks closer to the S.O.L.I.D principle

Why I’m excited (and a bit scare) about this?

As I said before this is the most drastic change coming with Magento2 but it’s a really positive one, and it really shows Magento’s commitment to improve the code quality, stability and readability.

That being said, I can see many developers struggling with this feature change, as it will force all of us to think about Magento code differently.

Related Reads: Playing with dependency injection in PHP

4. Testing, Testing, Testing

Every developer that has been working with Magento for any number of years knows very well how difficult is to test Magento, and how easy is to get hurt by a lack of testing. Magento2 is doing a massive effort in terms of testing and quality improvement, and these are the set of changes that I’m really looking forward to.

As we saw before, Magento2 is removing the use of god classes and objects, this is great news for testing since it allows us to create true unit tests for our code. Before, the extensive dependency in the Mage god objects (Mage::app(), Mage::getConfig(), and so on) made it almost impossible to test individual functions because of the complexity of having hard-coded dependencies.

And if like that wasn’t good enough, Magento2 has been building with testing in mind, this time testing was considered from the start and not as an after thought (I’m looking at you MTAF). The Magento2 team started by writing tests with its new refactor and change that they implemented.

As a result, the testing framework is an integral part Magento2, and it does a great job by including the following tests types:

  • Integration Tests
  • Unit Tests
  • Javascript Unit Tests
  • Static Tests
  • Legacy and Migration Tests
  • Performance Tests

We won’t go into detail about each type of tests (but look forward to a future article covering into detail) but the last 3 types are extremely interesting, not only we can test against the Magento core functionality but we are also able to test the impact of our custom extensions on the system performance.

Needless to say, now that testing is a part of the framework, writing tests for custom code and extensions is not only easier but something we should always do!

Why I’m excited about this ?

Magento has always been really hard to test, which makes our job as a developer more difficult and error-prone. Now that Magento2 has built-in testing, it allows us to add our own tests easily and there is now no excuse for community extensions to not include tests!

Testing is great step forward to improve Magento and its community, and it will result in much better code quality all around; all developers and extensions can benefit from having proper tests for their code. This also opens up the possibility for TDD (Test Drive Development) for Magento.

Magento’s commitment to the future of eCommerce

Magento2 is certainly a massive leap for Magento, and it’s a bit of a step up for the code release in terms of technology, performance and coding standards. It also shows that Magento is committed to keep improving itself and that this eCommerce platform is here to stay.

And yet there are still many things that I didn’t get to cover in this post like PSR compliance, webhooks and some particulars about the development and the tests tools included with Magento2, but don’t worry will go over those in future posts! Stay tuned.