I’ve been working for a small web development shop for the past few months. It’s interesting work, all open-source, all PHP-based. My first project was with Magento, and it was frakking painful.
I’ve been working for a small web development shop for the past few months. It’s interesting work, all open-source, all PHP-based. My first project was with Magento, and it was frakking painful.
I’m not just talking about the inevitable learning curve of tackling a new code base, and a (to me) whole new kind of CMS. The pain comes from an incredibly unintuitive code architecture that I keep having to wrap my brain around over and over.
From working with WordPress I was used to files for a given theme or plugin sitting together in one directory; this makes sense because they are all part of one module. Not so in Magento. Code, templates and other config elements are spread all across the system. From a design point of view I can sort of see why you’d want your business logic separate from your page templates, and both separate from your javascript, CSS, images and whatnot. You’d think it seems tidier, right? But in practice it makes extensions much harder to code than they should. To enhance or override core functionality, I have to know the exact names of these core classes and where they sit in the code directories, with no tidy hooks or API around which to build my functions.
And that’s not even counting the unholy tag soups in configuration XML files, with weird rules and redundancies that I haven’t been able to grok so far, so I just copy from existing samples and hope it eventually works. For example, according to A book to cook with Magento, config parameters defaults are set in the file config.xml
, but if you want to view and modify them in the Web interface, that form is defined in another file, system.xml
. My jaw literally dropped when I read up on this. How does it make any sense?
Mind-boggling or not, I’m grateful to blogs like A book to cook because there a serious dearth of online Magento documentation, official or otherwise. As often as not, googling particular issues led me to forum threads asking the same question I was researching… and nothing else, except maybe others chiming in to say they’ve got the same problem, or the same guy posting again a few months later to ask “What, nobody can help me?” Magento just doesn’t seem to have the same kind of active online community as, say, WordPress.
So what you end up with is a system that is way harder than it should be to enhance in any substantial way. Magento is open-source, sure, but if the source is a scary and confusing jungle of code, that doesn’t really help. No wonder people are willing to shell out megabucks for what you’d think are pretty minor extensions, instead of working it out themselves. Case in point:
The Backorder Button extension gives you the ability to display to your customers which of your products are currently on backorder.
If one of your products are on backorder, the Backorder Button extension will change the text’s of your “Add to Cart” buttons to “Backorder” (both in the product list, and on the product details pages), and the “Availability: In Stock” text’s (displayed on the product details pages) to “Availability: Available on Backorder.”. You can of course rewrite / customize the replacement text’s from the System Configuration.
$29 for this? Really? It took my coworker a couple of hours to figure out how to do it. But Magento’s deceptive: what looks simple and obvious isn’t always so. For instance, I had to abandon one extension that I thought at first would take me a few days, but later looked like many weeks of tedious hacking. It’s still on my to-do list, though: it’s useful functionality that should be present in an e-commerce system, but as far as I can tell nobody’s done in Magento yet. I tell you, if I ever make it work I’m going to be a fucking millionaire.
And then there’s Drupal
Now, I only have a few weeks’ actual experience with Drupal. I’d started playing with it a few months ago in preparation for a large volunteer web design project—that will end up using another CMS, but that’s another story. Then last month at work I finally got to do some actual Drupal development.
And it’s true, there’s a steep learning curve, which I’m only starting on. But unlike Magento, the learning process really isn’t frustrating. There are plenty of resources to help me with issues, and at the end of the day I just feel productive: Drupal development is way more straightforward—no mucking around with core classes, no having to create a dozen files in five different directories just for a simple “Hello World” module. Drupal is complex, but not overly complicated. It feels elegant. It makes sense, and I like that. Drupal is, frankly, a joy to work with.