The last article I wrote about this topic was criticized as being heavy-handed in my complaints about WordPress, so in this article, I am revisiting the topic from the other side of the fence. There are things about WordPress that are great, and there can many good reasons why you’d choose it as your Content Management System.
WordPress has done a fantastic job of making its product easy to use: each time there is a new version of WordPress, it takes only the click of a button to update your site. MODx still requires an FTP connection and an FTP client that can merge directories, otherwise, the upgrade can be hairy indeed. Unless you’ve got a really nice FTP client like Coda or you’ve got SSH access and you’re comfortable using cp -fr, then MODx can’t compete… MODx-ers will have to wait until version 2.2 or 2.3 when MODx will offer seamless upgrades.
WordPress also lets you easily upgrade all your plugins with a single click. MODx Revolution introduced package management, so you can see which plugins need updating, but it’s still not as streamlined as what WordPress offers.
Although WordPress at times is boneheaded and backwards in how its code is built, it is almost always extendible. MODx, especially Revolution, represents some code that is much more mature. If you are a PHP hobbyist or even a junior level developer, there’s a good chance that you won’t be able to follow the core MODx code because it’s so much more complex. MODx has areas that simply are not easily customizable — for example, the MODx manager is just flat-out hard to programmatically modify. At best, customizations of the MODx manager can be accomplished via configuration, but customizations via plugins can be complicated, and at worst, they may not be impossible. The WordPress manager, by comparison, is nearly always customizable via one event or another, so with a working understanding of PHP, you can usually trick things out to how you want them. WordPress may be completely low-brow in how it implements certain functionality, but as long as you can find an appropriate action or filter to hook into, you can usually customize the dashboard to how you want it.
Some of the more-experienced readers might be raising an eyebrow here as I compare MODx and WordPress in this area, because the MODx architecture is built so much more sensibly and because MODx is entirely object-oriented, it is by definition easier to override behaviors. But my point is that for “Joe Coder”, there are many tweaks that are simply easier to carry out in WordPress. It’s a bit like having a Volkswagon and a Jaguar in your garage: you can carry out most repairs on the VW with a wrench and a screwdriver whereas the Jaguar requires special tools, experience, and patience.
WordPress’ manager is built using jQuery. The MODx Revo manager is built using Ext JS. Although Ext JS offers way more options when it comes to building an application, the experience of using the MODx manager is that it is sluggish and more difficult to customize due to the steeper learning curve. The WordPress manager may not represent the most mature architectural principles, and jQuery may be simplistic for certain uses, but WordPress is generally much faster to use — jQuery has a much lighter footprint so it loads more quickly and doesn’t require as many resources from your server.
Secondly, jQuery, like WordPress itself, is much more widely used than Ext JS. There are lots of jQuery plugins available and it’s generally easier to customize. No, jQuery isn’t going to be the end-all-be-all of your web application, and it isn’t going to scale well when you start demanding more and more complex user-interfaces, but it really fits the bill for a huge number of sites and interfaces.
Any good content management system has to be able to store different types of content. In general, MODx is far better at this from an architectural and from a templating standpoint, but from the viewpoint of the average manager- or editor-user, WordPress generally makes more sense. MODx lets you define custom fields (called Template Variables in MODx parlance), and you associate them with a template. It makes good sense architecturally, but it is a bit… weird.
For example, you may create a “Book” template with custom fields for “Title”, “Author”, and “ISBN”. So the work flow in MODx is that you add a generically-named Document, then once you select the “Book” template, the “Title”, “Author”, “ISBN” custom fields appear, suddenly making the document a “Book” document. That works, but many users just don’t get it: they want to add a Book to their site. WordPress 3 allows for post types, which accomplishes just that — the built-in implementation is very primitive in comparison to MODx, but once it’s up and running, you won’t need to lecture your users about how a “Document will become a Book once you change the template”. If that explanation is confusing to you, then you can appreciate why WordPress’ implementation of this concept is easier to work with as an end-user. The Custom Content Type Manager plugin fixes many of these WordPress warts.
Hopefully this article explains a bit more of WordPress’ strengths: it’s not the best solution for every project, but it can be the right choice for a lot of projects. I still have a long list of gripes about WordPress, but that doesn’t mean it doesn’t have its strengths.
-- Everett Griffiths