Magento 2, like any significant project, has a set of goals. These were publicly discussed at the recent Magento Imagine 2014 conference. I thought I would summarize them here for those interested and add a bit of a personal perspective on them.
Disclaimer: I work with the Magento team, but this post contains personal opinions and perspectives and does not necessarily reflect those of eBay Inc. Or in other words, this post is not binding!
The new release of Magento 2 is upgrading the minimum versions for the tech stack. Magento 2 is designed to be a robust and stable platform, and so relatively mature technologies have been selected, not the bleeding edge. It is also a goal not to depend on too many different technologies, but instead endeavor to allow the community to use what technologies they prefer on top of the base platform. But I expect this is an area you just have to expect to not satisfy somebody.
Upgraded technologies include:
- PHP 5.4 is now the minimum version supported.
- jQuery is now being used. It is important to note that upgrading the tech stack is not a claim to be using the most leading edge technologies around.
- HTML 5 and CSS 3.
- PSR-0, PSR-1, and PSR-2 PHP coding standards.
- LESS for CSS preprocessing.
Improving performance (making requests faster) and scalability (making it possible to add hardware to support higher loads) is an important goal of Magento 2. Work is in progress on benchmarking, but a lot more work is planned here. Optimizing code that is going to be significantly reworked is not productive, so this area has not been the main focus of work on Magento 2 to date. This will change.
A lot of effort has been invested into streamlining customizations in Magento 2. One of the key benefits of Magento is that merchants can customize the site so extensively to meet their specific needs. Magento is not a one-size-fits-all system with a few templates. Radical new functionality can be included into a site to give a merchant that edge or support their online brand. Examples of work here includes:
- Addressing numerous pain points where adding a new module could not customize desired behavior (you had to hack the underlying code base), or when adding modules to your site would collide causing conflicts. Technology updates here include improved layout file inheritance, a new dependency injection framework, interception support, splitting of modules to make it easier to remove or replace modules, and more. Magento has a large code base, so phase 1 was to introduce the new technologies with phase 2 being to refactor code incrementally to take benefit of the new technologies.
- Restructuring the directory structure so everything specific to a module resides under a single directory for that module.
- Pulling business logic out of template files so it is easier to customize a template file without as much copy and paste.
It turns out many of the technologies to minimize extension conflict pain have a side benefit of having less lines of code required to build the customization. This may result in a higher initial learning curve for Magento 2 compared to Magento 1, but the end result is customization projects should be able to complete faster as there is less code to develop and maintain. Upgrading should also be easier and more reliable with the reduced conflicts and better encapsulation that has been achieved.
Added 5/18: Of course someone picks up on “may result in higher initial learning curve’, dropping the ‘may’! 😉 To expand, a part of reducing extension conflicts is to discourage practices that lead to such problems. Modern software engineering practices are being applied to Magento 2 to help here. There is also a greater emphasis being placed on product documentation to explain the concepts better. The end result is it may be easier to develop in Magento 2, but that is one area where community feedback will be the real measure, and the documentation is by no means complete at this stage so it is too early to tell. I certainly believe the overall story will be significantly better. There should be a much lower number of extension conflicts if people follow the new rules.
One of the cool bits of technology in Magento 2 is the new service layer work. While it is just good software design to have well defined interfaces to modules and so define a relatively small API that other modules can depend on (and the presentation tier of blocks and layouts), I think the cool bit is that with a simple XML configuration file, the PHP API is automatically made available as both a REST service and SOAP endpoint (with automatically generated WSDL file). No extra coding is required. So if you want to provide some new API for another system to access, you can create a new module with that client’s API, declare a short XML file, and you are up and going. I think this could have a big impact on integrations with the Magento backend, opening up a range of interesting new approaches that previously were too costly to embark on.
The fact that the business logic is being moved more and more out of templates and below the service layer is another bonus, making it easier to guarantee the APIs will behave the same as user interactions on the site. (This was a problem at times with Magento 1 where APIs could drift from web behavior.)
The Magento installation process is getting an overhaul. Much of the work to streamline customizations also makes upgrades easier. Automated testing (below) also helps increase the trust in upgrades. This is another area of work that is just starting to pick up. Composer is being investigated as one of the technologies to make it easier to spot supported combinations of modules before you install a new third party extension.
Magento 2 is being developed using modern automated test strategies. The goal is to minimize manual testing and publish the automated test suites so that all developers and merchants can see the test coverage achieved, and hopefully contribute to building even more test cases to ensure a quality project. Classes of tests include:
- Unit testing (testing small fragements of code independently)
- Integration testing (testing groups of code)
- Performance tests (automated so any code committed that introduces a performance hit is identified immediately)
- Static code analysis (such as code style and XML validation)
- Integrity testing
- Functional testing (automated Selenium based testing using the Magento Test Framework (MTF), designed to minimize the effort of user interaction testing)
In some ways, many of the changes in Magento 2 are not that radical – they are just applying better software design principles to the code base. However I believe these platform level changes may have unexpected indirect benefits that are sometimes hard to explain. It is hard to explain to a merchant why dependency injection support (which also happens to simplify automated testing) is so exciting. Let’s be clear – to them, it’s not! What is exciting is the potential to reduce the effort (and hence cost) to develop new sites, customize them, and then upgrade them later. This has huge potential to accelerate the rate of innovation. Merchants may be willing to upgrade more frequently, with a greater sense of confidence. When did you think twice about upgrading apps on your smartphone? This can then give merchants an edge in terms of adopting current trends faster.
This to me is the real potential benefit of Magento 2. It’s acceleration effect. Only time will tell whether my predictions here come to pass!
Do you have a question on Magento 2 technology direction? Leave a comment and it might turn up in as a future blog post!
“Magento 2, like any significant project, has a set of goals.” .. on the fourth year of development.
I was not with the project back then, so I am going to focus on the future rather than speculate about the past.
Alan, it is great to see all this momentum behind Magento2 I am excited to see how it rolls out. I would be great to see sample data. I am half wanted to try to convert the 1.9 sample data to work with 2.x!!
For the first time I really believe Magento/eBay has the right team and the right focus around Magento2. It’s very clear they are architecting this from a viewpoint that it will be ripped apart by developers, extended, altered and re-shaped, and as such needs to have a solid foundation and set of guidelines that will stand up to this.
I say thank god finally we have people like Alan Kent on this, please do as you say and focus on the future, do not listen to those that wish this to fail, make this the greatest ecommerce platform ever. With your intelligence and that of your team I believe you can again build a game changer in the world of ecommerce.
Thanks for the kind words, but it really is the whole team contributing. And I am not saying that just to be politically correct. There is a great bunch of passionate people building the system. I am actually relatively new to the team and more trying to guide and polish the rough edges. We will make mistakes, but I really do think Magento 2 is going to be a major step forwards for the platform.
It makes me think of being “disagreeable” by Malcolm Gladwell (author of books such as “Blink”, “David and Goliath”, and “The Tipping Point” – Keynote speaker at Imagine this year.). Magento as a team has to learn to be open and receptive to the community, while at the same time sticking to its guns at times to deliver a consistent story based on what the team feels is best for the product.
[…] Kent (von eBay/Magento) hat begonnen, über Magento 2 zu bloggen.Das erste Posting behandelt die Ziele von Magento 2. Klare […]
Hi, thanks for your insights in this article.
I’ve been wondering how much of the original SOAP calls (if any) will communicate with Magento 2. I think it’s great that there’s much more room for custom Services now, which is definitely a boon, but I also wonder if something basic like
is still valid.
I notice https://wiki.magento.com/display/MAGE2DOC/Making+a+SOAP+Web+API+Call but beyond this overview of adding your own services, I’m having some trouble. Any information or sources of information you could provide about compatibility would be very helpful.
The services are still being defined in Magento 2, so they are not final. But we using the chance to clean up and unify the Apis which will help ensure consistent behavior between web service calls and the normal UI. It is not a goal to be backwards compatible with the old API.
Since it is relatively easy to define a SOAP API in Magento 2, I could well imagine a community member building a backwards compatible Api as an extension (or for the common bits). Personally I would lean towards moving to the new native API, but there may be reasons some projects that this is less desirable.
If you had particular calls you were interested in, always happy to hear about them to validate what we are planning internally.
Thanks for the feedback!
Yeah, one of the things I was thinking about is moving over to Magento 2 and the effect on some extensions using the current SOAP API.
For me, SOAP was not exactly my preference, but it maintained a certain base level of compatibility through the minor versions that direct class usage didn’t always provide. Likely, others have exploited this too.
It would be nice to have category.tree and product.list mapped to the newer functionality if they don’t still exist.
I think these two bulk grabs at the catalog could be equipped with their attributes and CRUD operations instead of iterating through them to then call info, yet closely resembling the old structure.
It may help in navigating between stores of the two major versions during the transition period. As for the rest of the old SOAP capabilities, eh, if it were there fine if not fine really. I wouldn’t want to manage shopping carts, customer accounts or sales using the old version. I’d also imagine the general store information is not compatible/relevant between the two in terms of data structure and robustness.
I look that the Magento 2 will be 2x complex that Magento 1 and this is no nice … not every php dev is necessary and engineer and complexity is not the best answer to deal with problems …
Thanks for the feedback. Magento 2 is adopting new technologies like dependency injection. But this is in frameworks like Symfony too. I personly dont think ir is 2x than magento 1 – but there is a learning curve. Improving the docs should help too – coming soon.
I will add that some internal devs have mentioned they dont like going back to M1 code now. It may be an steeper initial learning curve that flattens off earlier. (Which is why better docs important.)
… __costructor() methods in M2 looks like a nightmare to me
Needs work, but it is mechanical rather than hard (from our experience so far). But we are seeing how to shorten some of the constructor lists.