> Upgrading the Magento system software no longer results in the loss of data.

Well, that's good. You're still working with Magento, though, so... (I've built plugins for it. Don't. No money is worth that.)

[1] devdocs.magento.com/guides/v2.1/release-notes/ReleaseNotes2.1.0CE.html

My experience (and I'm not even going to complain about the XML!):

The code base is horrifying; we would often trace bugs through the stack, realize they were in magento core files, then face really difficult decisions about furthering our fork.

The code is deeply integrated from UI to DB. If you change it, upgrades won't apply cleanly. But you need to change it (or the data structures/applications therein) to implement any non-core features.

Speaking of upgrades, they are mostly done by opaque and undocumented upgrade scripts, and tend to break plugins or addons...

Which are generally poorly written and untested, even highly rated ones in their web store, but their quality isn't even the biggest problem. The absence of a sane extensibility model means they virtually can't coexist consistently, and when they do they break on (or need rigorous requesting due to) upgrades...

The EAV table layout wouldn't be totally horrible if it weren't so badly implementated. They put everything, even system data, in EAV tables; not only did this make it hard to extend, but it put a huge load on the (outdated) ORM.

Performance was an exercise in caching like no system I've seen before, entirely due to this design choice. The downside of that is that server restarts under load could cause a full system panic as new web hosts put an unbearable load on the DB, which could throw off other web hosts when their ORMs blew up by timing out all their pooled DB threads, which started a cascade through the rest of the system.

It was possible to deploy a single cache shared by all your Magento servers, but even stock Magento would pepper that cache with dozens of serialized queries to serve a single page, making the network overhead barely worth it. Plus, this meant you couldn't clear the cache under load or you'd be down for an hour, and clearing the cache was a daily necessity because their tagging system to rebuild the cache incrementally was horribly broken. (Only barely worked using Redis, which was both recommended by Magento and provided by a 3rd party unmaintained driver and officially unsupported.)

We ended up reimplementing all our e-commerce properties on a custom node platform by assembling high-quality atomic tools for the important bits. The technical debt of the transition was paid off in 3-6 months on our feature schedule and has paid dividends since, and we easily handle double the load on ~10% the infrastructure spend.

There are other alternatives we looked at, such as Spree (ruby) and other php based carts, but Magento 2 has so many extensions available from third party and the developers are actively listening to the community. The Chief Architect, Alan Kent is available to communicate with and has pushed changes that the community really wanted (i.e. moving to SASS from LESS).

It's been a steep learning curve, but there is also a lot of flexibility in modifying the code to suite your needs (without needing to edit the core).

I am obviously exaggerating but Magento might have an xml file to configure another xml file.

(Full disclosure: I'm Magento's chief evangelist, but I was an agency developer for a Magento shop from 2008-2014, so I'm not totally a shill. Also, I care that we are listening & getting things right.)

I spend a lot of time interacting with PHP developers around the world. Some have been / are Magento developers, some are not. By wearing Magento gear at conferences and usergroups I would hear quite a lot of opinions about Magento, both negative and positive. Here's the negative.

* No documentation * Can't test it * XML sucks * EAV is the Devil's creation * The view layer is impossible to understand * Inconsistent implementation in core code * Not true open source * It's too complicated * It's too slow * etc.

Fact is, there's always more to the story. Take documentation: yes, it's tragic that there never was official developer documentation for M1, but it was an outcome of Magento's explosive origins leading to the company being totally constrained. (We did eventually produce some fantastic user docs though.) Magento 2 solves this by having several tech writers on staff, as well as a doc site to which the community can contribute via pull request.

In the case of testability, well, Magento 1 was born in 2007. Ideally, yes, it would have been built with test coverage, but that wasn't standard practice for PHP back then. (How many of you were writing tests for your PHP apps in 2007? Not too many aside from Sebastian Bergmann!) Eventually though some great tools came around, and there are many examples of fully covered installations as well as CI/CD implementations. Magento 2 solves this by covering much of the core with unit, integration, and functional tests.

Regarding XML, Magento 1 (and 2) largely favor configuration over convention, and the decision was made to use the most structurally descriptive markup possible. Of course, the implementation of it in M1 was full of Magentoism - building a DOM by combining DB data, merging multiple XPATHs, and filling out a bizarre hierarchy for scope. It's not intuitive without either experience or schema definitions. Magento 2 solves this by splitting up configuration into functionally-scoped files AND by providing XSD. The XSD help when editing files by hand in an IDE, and we are seeing the creation of tools to help developers avoid writing it altogether.

When questions about EAV come up, believe me, I understand. That's a tough storage pattern to get used to, but the ORM helps quite a lot. The implementation in M1 is imperfect though, as you do end up with domain objects which leak their storage pattern. EAV is invaluable for solving the complicated requirements of facilitating arbitrary entity attributes and scoping/translation of those values. We looked at removing it for M2, but could not find a better solution. And if you say "noSQL," sorry, you're wrong.

The view layer is the thing which trips most people up - even developers who grok Magento right away. Theme fallback and layout XML are the complicating factors here. Theme fallback/inheritance is not so hard to get, and it is fantastic at keeping custom themes DRY - especially when multiple sites are running off of one instance. If only one thing could have been documented from the beginning, it should have been layout XML. Layout XML - along with the view model approach which we took with M1, allowed for simplified, DRY controller actions and ultimately allowed frontend developers to build interfaces without having to need backend developers. In M2 we have refined layout XML as well as abstracted the entire rendering framework, allowing developers to adjust or replace framework details as they see fit.

For inconsistent implementation in core code (which is especially evident in adminhtml), this was the outcome of a small team producing a lot of code independently. It's unfortunate, and very confusing for developers new to the platform. I struggled with this when I was starting out. We've worked to eliminate this in M2, but there is work remaining to be done. Thankfully we have Issues and pull requests on GitHub, and at the very least we can evolve our test suite to help us (and others) to implement functionality in The One True Way®.

On the subject of GitHub, we are much more of an open source company than we were in the Magento 1 days. We did allow contributions, but the process for becoming a contributor was cumbersome, and development effort was only revealed through updates to an SVN endpoint with no discussion. That is very different from our approach with Magento 2. Starting with the beta in December of 2014, we allowed pull requests to the M2 codebase, eventually building in our contributor agreement into the CI process. Many of our core engineering team are regularly on GitHub interacting with a bevy of "how do I" requests along with legitimate issues and pull requests. We have improvements to make here which will help us to keep up with the volume of discussion, and you should see these soon.

When I hear that Magento is "too complicated," I have to ask, then why doesn't something similar take its place? Ultimately the problem of complexity rests with the domain of commerce, which is always custom and always complex. Consider just one area of a commerce application - say, price calculation - and look at the complexity: cost, retail price, adjustments at the catalog level, adjustments at the customer level, and then add in the multiple taxation schemes which exist in the world (tax on full price before discount vs after, tax on shipping, etc.). Complexity is everywhere, and if you want to make an app which works for most, there will be overhead. Ideally the app helps the user manage that complexity as best as possible.

When I hear that Magento is too slow, that is always a worthless discussion without details about traffic, order volume, amount of entity data, update frequency, etc. M2 is a much better application for performance than M1, largely because it was developed with a mind to commodity computing and reverse proxy (which were nascent in 2007). That allows us to build core architecture for performance as well as enterprise architecture for scalability. That said, performance for M2 is not a finished story; I imagine that we will continue to improve on it as time goes on.

Okay, if you made it this far, I owe you some coffee or beer or whatever when we happen to meet. I was compelled to write this because I saw a lot of complaints which seem to come from the end of the Magento 1 era. Many of these complaints are reduced when considering the context, and they are all handled quite nicely in the Magento 2 era. I'm always happy to see or hear feedback.

I can be reached at ben@magento.com.

No idea how good it is but version 1 was horrifying.

The fact their github has 1274 open issues and 179 open pull request at the time of writing suggest maybe nothing has changed: https://github.com/magento/magento2

That makes an assumption that the complexity involved is necessary. The alternative to Magento isn't a product that does everything Magento can do but with a simpler codebase, but instead is a more specialised product that doesn't include the features of Magento that you don't need.

The complexity of Magento stems from the fact it does everything you could possibly want but ignores the fact that most (like, 99%) stores don't want or need everything. A simple ecommerce site that sells 10 virtual products has to have the same feature set as a fully-featured online store with 1000s of real products, templates that change based on dates, multiple variations of items, weight-based shipping calculation and so on. That's what bugs me about it. I want to be able to make a custom build that only includes the things I actually need.

Also, consider this - the internet is full of articles, blog posts, and Stackoverflow questions that are about "Magento". Authors are rarely explicit about the version number. A lot of the difficulty in learning how to use Magento well is that as a developer I have to look at the date something was posted and approximate whether or not the advice is applicable to what I'm working with. Perhaps this is something you can address as Chief Evangelist - ask authors to take care to say what version their posts are about, and to revisit old articles to update them when Magento changes, or to deprecate posts about versions that are out-of-date.

(Note: This is based on M1. I've tinkered with M2 but haven't yet deployed anything on it yet. Hopefully my concerns have been addressed.)

Like I would say, stop complaining, but start creating a better world and share your ideas, code and knowledge to improve.