DCDCoder·Jul 24, 2016
> The use case for Magento is (apparently deliberately) confused. It's an unholy melange of a CMS and a shopping basket. There is no good out-of-the-box experience; in practice it's a job creation scheme for consultants.
The CMS capabilities of Magento are quite limited, as the Community Edition does not even include a "menu" module or a hierarchy for your static pages. My opinion is similar to yours, it is a powerful shopping basket that will require lots of custom development or third-party module juggling to get a decent result.
I have been working with Magento 1.x CE for a few years now, and I wanted to add a few more factoids from a developer perspective:
* The database API has an "you want it, you got it!" mentality - if you tell it to add a unique index and MySQL refuses to because existing data is not unique, the API will parse th
Read the rest
e MySQL error message to identify the duplicated fields/values and delete them silently. You will get your index, but you might no longer have all your data. [0]
* The model classes store nearly all the in-memory data in an untyped dictionary. You can call $model->setFoobar('12345') and later $model->getFoobar() to get it back - all unknown method calls get forwarded to a "catch-all" method which treats the method name as a key into this dictionary, and gets/sets a value of that key [1]. Most of the time, these calls are unannotated, so IDEs can't make any sense of them (see the "Undefined method" part in [2]). This unknown method forwarding is also a performance issue, so they make optimizations like [3] by inlining pieces of the catch-all handler code for commonly-used data.
* The JavaScript is based on Prototype.js, not jQuery, so half the modules and themes bundle their own copies and drop them in different locations. Some of them provide a configuration setting so you can disable their jQuery and use your own, some don't.
* It includes a "Developer Mode" where php notices and warnings are turned into exceptions like in sane languages. But plenty of modules and themes have never been tested with this setting on and they cause faults on every page load - either you have to disable the Developer Mode, or fix this third-party code.
[0]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
[1]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
[2]: https://imgur.com/RMxWEgR
[3]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
> I don't have a good answer on the shopping basket, but Magento was bad enough at that too that we went back to our in-house homerolled system.
Our clients were originally in love with Magento because "we can just add all these existing modules and get all sorts of awesome functionality without having to pay you for it!" We warned them that that was a pipe dream, but they didn't listen. Now they have several thousands of hours worth of custom development on top of Magento 1.x (95% of it written solely by me, no bus factor problems with that) and it's not even finished yet. Last I checked, the end-of-life for M1.x is planned in December 2018, and the client has no plan for what to do then.
> I understand some work has gone into Magento 2.0 to make it less mind-bogglingly horrible.
When I looked at Magento2, they had an amazing solution to PHP's lack of generics: they bundle multiple "template" classes and during system installation, you're supposed to run a CLI script that goes through those classes with a list of wanted concrete classes and generates specialized class files for all of them. If you fail to run this script, don't worry - their custom autoloader will detect this and generate those classes at runtime, when they are needed.