I’m a Magento developer. I’m not a “community guy”, but I have been a true supporter of this solution since 2009 and followed its various 1.x branches during time and also its 2.x rebirth after the X.com episode. I installed, maintained and upgraded several platforms based on it, either on CE or in EE, addressing some unusual edge cases such as SQL deadlocked on highly loaded checkout, index optimizations for 100s websites on a same platform, integrated video on demand with DRMs validation, connected Magento to several ERP, CRM, PIM and WMS, not counting anymore. I was member of the team that built a project selected as finalist for the “Magento innovative website of the year in 2011”. This blog post was inspired by messages on Twitter from Karen from @WebShopApps and conversations tat followed :
After 6 years as a #realmagento partner today we step down. Disappointed in @magento’s approach, looking forwards to making our own future
— WebShopApps (@WebShopApps) 25 décembre 2016
Okay quiet enough. This is #realMagento & its 2017. My play. https://t.co/ofhwSjhwMz
— WebShopApps (@WebShopApps) 5 janvier 2017
@lazyguru I find it surprising that the complexity didn’t internally bring up red flags months, if not years, ago.
— Kevin Schroeder (@kpschrade) 9 janvier 2017
Also, a long DM speech I sent to @benmarks that followed the following tweet he sent me during the writing of this article :
@gplanchat I don’t see @Sylius anywhere near being turnkey (my impression from conversations at SymfonyCon). Am I mistaken?
— Ben Marks (@benmarks) 7 janvier 2017
Sorry if it was a bit long Ben :)
Discovering Magento 2.0 Enterprise
From march to july 2016, I created my first Magento 2.0 store. It was a bit special for me : it was dedicated to the mainland China’s market. It was an overseas wedding booking system. Both subjects I wanted to face some time in my career, check. Booking isn’t standard in Magento, but as we were using the Enterprise edition, the gift registry module was perfect for a staring point. I forked the module to break its internal limitations, especially concerning virtual products, and limit the impact on further EE uses.
Today, I don’t recommend using Magento 2.x to my customers.
That’s a bit harsh, but that’s what I’m doing. The Magento team did some great work by the past, this version was deeply frustrating: guys, I truly hope you’ll make the next ones better! During this project, I had to build a main installation that would be deployed on an elastic AWS infrastructure, discover Magento 2.0, give guidance to a dev team and succeed. Business as usual? Not really. First of all, Magento came with a lot of CLI tools… I loved it. People I worked with didn’t. Actually they were working on Windows, and not used to CLI. They were using a vagrant box to run the Magento, and used GUI from end to end (NetBeans, SourceTree, Magento’s BO). This is a addressable issue, lots of developers aren’t used to those tools, especially front-end devs working on several CMS, but it can be solved with a bit of training. Now, you have to know that working in dev mode is very slow, don’t even think about it on a vagrant box. In dev mode, the DI cache and code compilation breaks all the time. It took 12 to 15 minutes to rebuild it, I heard it is faster now since a few versions. The frontend files needed compilation… that took a minute. First feeling of all 3 Magento developers: lots of small amounts of time lost trying to fix the cache built from the core. I had to explain why this project was taking so much time to my client. Complexity is a burden, unneeded complexity will kill your project and give your competitors time to dig your own grave.
Dear Magento experts community
That feeling I have when reading some posts of “Magento experts” still promoting the tool today, whatever happened to the core. Arguing it is a needed evolution to make the software better.
No, you don’t get better anything -already complex- by adding more complexity.
You guys are making feel you are building your own filtering bubbles, by denial. When I read your posts, I feel some times like you didn’t use other tools than Magento since a long time. Really. Come on, admit you love working on easy to understand projects without unobvious behaviors. Don’t think Magento will keep being the “must-have” e-commerce tool. In some way almost everybody doesn’t really care between Magento, Prestashop or even WooCommerce if the tool does the job they payed for it. Yoav Kutner and the Oro team has joined Symfony several years ago and succeed already with OroCRM. They are about to double the win right now with OroCommerce! Prestashop and Drupal are migrating to Symfony.
XML everywhere
Magento is using XML for almost every configuration. 2.0 brought at least XML validation, compared to 1.x branch it is a good point for developers, but it doesn’t simplify at all. XML is still harder to read for an human than other file formats such as YAML, JSON… and plain standard PHP arrays. Developers wanted ways to avoid errors and mistakes, not another layer of complexity.
The Dependency Injection : the path to reinventing the wheel (again)
Dependency injection is the process of building object instances (services) and integrate them together when one depends on another.
Let’s say it loud : Magento 2’s DI is crap, you only need to look at the product and category model classes to be convinced.
See product constructor and category constructor Yes, the only thing those objects probably can’t do is calling the API of your coffee machine on every git push. Thus, I can’t guarantee this statement.
Single responsibility
Single responsibility is the process of making classes so simple that one object can’t know how to do several types of actions. Category and product classes previously cited are the perfect counter-examples. Come back to your development learnings : a model is a data storage. In fact, an in-memory, temporary, directly usable data storage. There is no need for anything like :
- a link repository
- a link builder
- cache management
- errors storage (!)
- a helper
- a collection factory
- persistence routines
- indexer management
- event management tools
- API management tools
No, really, I mean it: this is nonsense. Those tools should be kept from the outside of the product model AND work on the product’s data. This way, implementing new worker logic -new ways of managing a store- becomes painless, and most of all does not bring incompatibilities and instability on a same code base with different needs. If you did not faced a platform with multiple stores having different processes, Magento is probably overkill for you.
Strong typing and contracts
Zend Framework 1
KISS
Preferring extension against composition
This is all about how classes are built on Magento : extend existing classes.
Bugs, bugs, bugs, bugs (again)
Yes, there are bugs on each software. The thing is on Magento 2.0, bugs have been reported, PR sent since several months and no action taken. I even have seen some bug fixed on the core, copying the code sent in a PR closed without merge nor thanking the reporter. Communication is the key you once used to gain success. All this is team work. I don’t know what you’re thinking, Magento community is like an ant colony. Magento may be the Queen in the colony, you need everyone to make the magic happen (and sell EE licences). You probably know what happens to the queen when she doesn’t go in the way it is profitable for the whole colony.
Magento compared
Yes, and to be honest, as a community we should compare Magento with other tools that are emerging now. I am using OroCommerce right now for a real-life project, and I am very surprised by the work that has been achieved already. This software does not bring all the features Magento does. In fact, Magento does not bring essential B2B features OroCommerce is bringing, like fully-customizable checkout processes, request for quotes, product lists in cart, multi-warehouse (EE feature), multi business units and multi-organizations (EE feature), or even offline sales processes. It also integrates with a OroCRM, a CRM, and is based on the same tools than Akeneo (PIM) and Marello (ERP). The latter will probably be able to integrate with OroCRM and OroCommerce in a same application at some point. Magento just can’t compete alone. I am seriously considering the replacement of a Magento 1.9 instance I am running by a Sylius instance. We do not need most of the features of Magento, and as Sylius is based on Symfony, it just makes it simple to integrate new features by reusing existing bundles or extending them with a very small amount of work.