30 ms·

Magento is incompetent on much simpler levels than this. 1. Someone thought chmod 777 was a good idea, ever, under any circumstances. Not only is this standard

Magento is incompetent on much simpler levels than this. 1. Someone thought chmod 777 was a good idea, ever, under any circumstances. Not only is this standard practice in Magento installs (it's a how-to step in many books on Magento), it's all through the actual codebase. The below is from the Magento Enterprise 1.14.0.1 tarball, downloaded from the company (and I double-checked this after someone questioned this last time I brought this up): $ grep -r chmod .|grep 777 ./downloader/lib/Mage/Backup/Filesystem.php: chmod($backupsDir, 0777); ./app/code/core/Mage/Compiler/Model/Process.php: @chmod($dir, 0777); ./app/code/core/Mage/Install/Model/Installer/Console.php: @chmod('var/cache', 0777); ./app/code/core/Mage/Install/Model/Installer/Console.php: @chmod('var/session', 0777); ./app/code/core/Mage/Install/Model/Installer/Config.php: chmod($this->_localConfigFile, 0777); ./app/code/core/Mage/Catalog/Model/Product/Attribute/Backend/Media.php: $ioAdapter->chmod($this->_getConfig()->getTmpMediaPath($fileName), 0777); ./app/Mage.php: chmod($logDir, 0777); ./app/Mage.php: chmod($logFile, 0777); ./lib/Zend/Service/WindowsAzure/CommandLine/PackageScaffolder/PackageScaffolderAbstract.php: @chmod($path, '0777'); ./lib/Zend/Service/WindowsAzure/CommandLine/PackageScaffolder/PackageScaffolderAbstract.php: @chmod($path, 0777); ./lib/Zend/Service/WindowsAzure/CommandLine/PackageScaffolder/PackageScaffolderAbstract.php: @chmod($path, 0777); ./lib/Zend/Cloud/StorageService/Adapter/FileSystem.php: chmod($path, 0777); ./lib/Varien/Autoload.php: @chmod($this->_collectPath, 0777); ./lib/Varien/File/Uploader.php: chmod($destinationFile, 0777); ./lib/Mage/Backup/Filesystem.php: chmod($backupsDir, 0777); ./errors/processor.php: @chmod($this->_reportFile, 0777); 2. The company thinks there's nothing wrong with storing money as floats: https://github.com/magento/magento2/issues/555 https://github.com/magento/magento2/issues/555 The way we eventually dealt with hosting Magento (which we had strongly advised against) was a concrete sarcophagus and a thirty-kilometre exclusion zone: * a cron line specifically to remove o-w permissions from all files in the webroot every minute (which is very inelegant, but the alternative is maintaining our own patches to core). * Files not owned www-data, except where Magento must be able to write to them. * deploy all webroot files as a user the webserver can't write. * cron.sh (Magento's internal cron) runs as root out of the box. We ran it as www-data. * AppArmor to keep Magento from ever, ever being able to pull shit. This caught Magento's more antisocial tendencies on more than one occasion. * Admin login: use a path other than "/admin" to foil quite a lot of attack bots at the very simplest level. We have outsourced our remaining Magento, thankfully, and I don't personally have to maintain the above any more. (You know you've been administering Magento a bit long when you can hum along to bits of "Metal Machine Music" accurately.) 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. Even crap-tier "well technically I can tell my boss's boss we have paid support" support, with a four-day response time for them to ask you a simple question you already put the answer to in the original ticket, is swingeingly expensive. I can't say what we're paying for this standard of quality, but I can say that it's public knowledge that Magento is at least $13k/yr: http://web.archive.org/web/20120215011525/http://www.magentocommerce.com/product/enterprise-pricing-contact http://web.archive.org/web/20120215011525/http://www.magento... The problem Magento seems to solve is when the business wants a quick site without developer involvement. After a few other abortive platforms (Plone, Drupal - which are both fine for what they are, in ways Magento just isn't, but didn't end up matching our needs), our eventual solution to this was Wordpress, which we have outsourced so I don't have to think about that either. Outsourced Wordpress with securing it being the host's problem is totally the right answer. 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. I understand some work has gone into Magento 2.0 to make it less mind-bogglingly horrible.

DCoder 10y ago
> 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 the 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/lib/Varien/Db/Adapter/Pdo/Mysql.php#L2739 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [1]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/lib/Varien/Object.php#L616 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [2]: https://imgur.com/RMxWEgR https://imgur.com/RMxWEgR [3]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/app/code/core/Mage/Catalog/Model/Product.php#L684 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.

DCoder 10y ago

> 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 the 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/lib/Varien/Db/Adapter/Pdo/Mysql.php#L2739 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [1]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/lib/Varien/Object.php#L616 https://github.com/OpenMage/magento-mirror/blob/magento-1.9/... [2]: https://imgur.com/RMxWEgR https://imgur.com/RMxWEgR [3]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/app/code/core/Mage/Catalog/Model/Product.php#L684 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.