Has Magento 2 Reduced Integration and Upgrade Effort? The developer beta period (officially commencing December 18, 2014) is a great time to explore Magento 2 and provide your perspective and feedback. What is better? Where can Magento go further? Are there rough patches where small changes could have a big positive impact?

In a previous post I asked is it useful to categorize modules? A part of this article was asking if a “site developer” is a useful role? The feedback I got was more like “this is an interesting idea, but its not what really happens when developing a site in 1.X”. This does not mean its not useful to categorize modules – it can make Magento easier to pick up and learn. It also does not mean you cannot build a site just by adding modules – this can be useful to prototype a store or explore a new extension. But a core value proposition for is Magento is its ability to be a Chameleon – its ability to be customized to develop your site with your branding and your unique look and feel.

So what should you explore in Magento 2 during the developer beta period regarding reducing integration and upgrade effort? Here are some suggested areas to dig into. (The following assumes you know Magento 1 as a basis of comparison.)

Presentation Layer

The following areas have been changed in the presentation layer:

• A lot of business logic has been pulled out of PHTML files and blocks and moved behind service contracts. Benefits should include there is less code in PHTML files if you want to customize them.

• The introduction of service contracts with easy exposure as REST or SOAP services should make AJAX calls easier with consistent behavior to PHTML and blocks.

• There are now more, smaller PHTML files. This should make it easier to replace individual PHTML files where changes are required.

• CSS has been extracted from PHTML files. This should make it easier to replace CSS without having to replace corresponding the PHTML files.

• Similarly JavaScript is being pulled out of PHTML files (not 100% complete yet), for the same reason as CSS. That is, you can replace PHTML and/or CSS without having to copy the JavaScript as well. The finer grain the adjustments the less upgrade effort that should be required in the future.

• There is a better inheritance structure for CSS (LESS), JavaScript, and other page assets with the ability to override individual files more easily. This means styles can be applied without touching existing modules. This makes patching modules easier (you won’t lose local changes). It should also reduce the effort of future upgrades.

Domain Layer

The following are some of the changes at the domain or business logic layer:

• Service Contracts have been introduced to provide slow changing APIs across releases. Other modules that depend on the service contract are less likely to require changes during upgrades.

• Plugins support has been added to avoid class rewrites. This should reduce the number of extension conflicts as plugins can nest. (In Magento 1 it was not uncommon to rewrite a class – if two modules rewrote the same class only one rewrite would win, requiring the system integrator to manually merge the changes from the two modules.)

• Events are still there as before.  I am particularly interested to see if plugins are a good replacement for events, or whether events are the normal extension approach with plugins being available when events do not currently exist.

• Modules have been split up somewhat to make it easier to remove unwanted logic and add new extension logic easier. For example, each shipping method is now a separate module allowing easier control over which shipping methods can be offered.

Conclusions

In many ways this post does not say anything much new. All of the above features have been mentioned before. However my intent behind this post is to get people ready to start thinking about whether the changes as made have gone far enough to really solve the targeted issues. Even better, are there any low hanging fruit where a little more effort would go a long way to solving a remaining problem?

It is not mandatory to fix all problems in Magento 2.0. We can continue to iterate and improve after the release. But this less desirable due to the impact on extensions and sites. So it is desirable to get the base platform as right as possible now. This is what the developer beta period is intended for – for extension developers to explore the changes made and provide feedback.

So when should extension developers port their extensions? I have answered this before, but I think its worth repeating. My default generic advice would be to explore during dev beta (Q1 2015) then plan the serious porting after that. If you want to avoid possible rework then port your extension as late as possible (so porting completes as close to the GA release as you can). If you want to have more likelihood of changing Magento 2 to suit your extension, do it as soon as possible. Some extension developers may also decide to port their extensions earlier to be ready and start training up their own staff on 2.0 to be ahead of the curve. But my default advice is to explore Magento 2 during developer beta (so you can raise issues or suggest changes), and then do the serious port after developer beta to minimize rework required.