MODx vs. WordPress (revisited)

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.

Ease of Updating

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.

Post Types

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.

2 thoughts on “MODx vs. WordPress (revisited)

  1. Good article. My friend was talking about MODX and how it addresses security holes. I think the wordpress documentation sux and is very general in its approach.. You can find little real examples that work. They use things like $x = foo; print foo; very few real world examples. I’ve started using drupal and its documentation is better. All in all, all of this CMS use php with variations of javascript and html. If you really want the power at your finger tips then sometimes you must re-invent the wheel when it is necessary. CMS can be great but they leave security holes and bloat out your website. I find it easier to start from a CMS I created awhile ago and just add on to it. Where I worked before the CMS was created from scratch and then reused for different projects. There was no need to worry about how to write plugins or short codes. Which are great but not always needed and they make your sites bloated. You should never just use one programming language.. There are many great languages perl,python,ruby, java, c++,C.. WIth these CMS like wordpress people tend to stick with PHP and wordpress plugins. There can be solutions from perl or python.. Which are sometimes better depending upon the problem… DJANGO and ruby on rails can be great too and offer different solutions for web applications. WordPress is cool and all but I think its bloated out full of security holes.

Comments are closed.