WordPress vs. MODx

April 19, 2011 - Reading time: 29 minutes

There are a lot of Content Management Systems (CMS’s) out there, so I wanted to give a blow-by-blow analysis comparing two of them: MODx and WordPress. I feel oddly qualified to do so: Brian and I just authored a book on WordPress plugin plugin development (WordPress 3 Plugin Development), and I am a MODx Solution Partner who was invited to speak at the MODxpo conference in Dallas last year. I’ve used both flavors of MODx (Evolution and Revolution) and WordPress while building somewhere around 50 web sites over the past couple years, and I like both systems. I have even contributed a couple plugins for both systems (e.g. Custom Content Type Manager for WordPress). So after the urging of some friends and colleagues (like Kris), I’m organizing my techno-ramblings into a coherent article.

I’m going to walk through a series of areas and compare and contrast both how both CMSs work in those areas. The comments here apply to WordPress 3.x and (mostly) to MODx Revolution, but MODx Evolution is mentioned where appropriate.

Basic Stuff

System Requirements

	WordPress 3.1	MODx Revolution
Server OS	???	Linux x86, x86-64 Windows XP Mac OS X
Web Server	Apache ??? NGINX ???	Apache 1.3.x or Apache 2.2.x IIS 6.0+ Zeus lighthttpd Cherokee NGINX
Database	MySQL 4.1.20 or higher (5.0+ recommended) SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP privileges MyISAM table types	MySQL 4.1.20 or higher (excludes 5.0.51) Default table encoding of UTF-8 SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP privileges InnoDB and MyISAM table types
PHP Version	4.3+ (5.2+ recommended)	5.1.1+ (excluding 5.1.6/5.2.0)   Running as FastCGI safe_mode off register_globals off magic_quotes_gpc off PHP memory_limit 24MB or more
PHP Modules	???	zlib JSON cURL ImageMagick GD lib PDO, with database driver SimpleXML

*Source: WordPress requirements, MODx requirements

If the requirements for MODx Revo look insanely detailed, ask yourself this: “do you really want to be guessing whether or not your server will support a given app?” MODx Revo does a pretty good job of testing for the necessary requirements during installation, so you don’t have any unexpected surprises.

Installation

WordPress offers its “famous” 5-minute install, and I give them credit where credit is due: WordPress is a simple web app to install, but to be fair, installing MODx Evolution is also very straightforward.

MODx Revolution has beefier requirements, and it’s far more likely you’ll run into troubles setting up your webserver permissions or PHP extensions (e.g. PDO). Moving a Revolution install to a new server is also a tricky operation that requires some patience.

Templating

Hands down, MODx offers the gold standard in templating. Expression Engine is a healthy second place, but only in my days of doing Perl development with the venerable Template Toolkit did I encounter a templating system that followed good MVC architectural principles as well as MODx.

What does that mean? It means that if you’re a front-end designer who likes to roll your own HTML and CSS, then MODx will grant you total freedom to implement the designs you want, whereas WordPress may result in headaches and holes punched in your walls (no comment on the convoluted mess that is Drupal and Joomla templates). I’ve posted previously about creating templates in MODx Evolution and how to import existing layouts into MODx Evolution, and the process in MODx Revolution is nearly identical (the only difference is the format of the placeholders).

In MODx, you can easily have multiple templates (i.e. layouts), and use any one of them for any page. In WordPress, the ability to use a specific template is possible only with pages, not posts. The thing that really gives me convulsions is understanding how WordPress formats its special pages, e.g. a category page, or an author page. See the image below as a reference for how WordPress formats page requests.

See the official WordPress docs for Template Hierarchy for more information. I honestly have a hard time fathoming that this is the solution that actually got implemented… what other crazy ideas were on the drawing board?

Menus

MODx offers nearly infinite menu flexibility through use of menu-generating PHP Snippets, primarily WayFinder, but it’s not aimed at the average user. WordPress has a built-in GUI for creating menus, but I have experienced some bugs with it when using custom content types. Your WordPress theme may not support more than one or two menus, so in the end you may end up writing some code in your tmeplates (e.g. using my Summarize Posts plugin) so you can list the posts that you want to see.

In a nutshell, WordPress offers an easy GUI, but if you need more customization MODx’s flexibility here is far greater.

Plugins

WordPress has a huge number of user-contributed plugins available, whereas MODx has relatively few. The sheer number is not a good comparison, however; I downloaded and tested hundreds of plugins in the process of writing my WordPress book, and the number of plugins that are unusable due to sophmoric errors or plain-old bad coding is huge. I estimate that at least half of the plugins in the WordPress repository are unusable, and perhaps only a tenth of them are worth using. There are crufty plugins in the MODx repo to be sure, but the playing field is more even than you might think.

The real difference here comes when you have to write your own code: MODx is a lot easier to work with with a shorter learning curve for a majority of code, whereas learning the ropes of WordPress plugins requires more guidance (hey, did I mention we wrote a book about that?).

Architecture

This is an area that is hard to discuss unless you’re a geek, but in a word, MODx offers a robust and well-architected MVC framework under the hood that can make writing custom plugins (Snippets, manager pages, et al) a breeze. The work done by Jason Coward and Shaun McCormick is really astounding.

Some of the limitations to WordPress are really staggering: it is basically a stateless application, so by default it does not use sessions, and nearly all of its API functions exist as procedural functions in the main namespace, so naming collisions are a big concern when authoring plugins. This makes certain functionality damn near impossible in WordPress. For example, creating a WordPress application with a login portal and access to custom data models would require an enormous amount of time. Even accessing WordPress’s posts and categories is difficult at times; I basically had to rewrite core WordPress functionality with another plugin (Summarize Posts) just to get the menus and summaries I needed for one recent site.

Another severe limitation is WordPress is that all extensions to the core occur via plugins that are triggered by system events (confusingly they are loosely categorized into “actions” and “filters”). This construct can be awkward at times, and the WordPress architecture is showing its age as the number of events exponentially increases, whereas the amount of documentation for them continually wanes. Realistically you can get WordPress plugins to do just about everything you need using only a handful of events, but debugging someone else’s plugins is a nightmare: there is no centralized location listing which events are being hooked into, and new events are often created and executed on the fly. Debugging WordPress plugins is like Alice’s trip down the rabbit hole: majorly trippy,and you don’t know if you’ll ever come out.

User management is another area where MODx dwarfs WordPress: Revolution can handle totally granular control of permissions, but it is admittedly overly complex for 90%+ of use cases. Evolution offers a much more sensible permissions scheme that covers most use cases.

MODx offers much more sensible implementations of custom code: like WordPress it uses event-driven plugins, but it also uses custom PHP snippets which can be placed anywhere on a page or in a template.

Another impressive feat is how MODx Revolution has abstracted the database into a separate coding layer — that means it is relatively easy to interface with custom database tables (or even to other database engines) using code that is completely database agnostic (support for SQLite and PostGREs is in the works). That’s some seriously geeky stuff that has kept me awake at night trying to comprehend how they accomplished that. MicroSoft has even worked directly with the MODx team because MODx’s architecture is flexible enough that it can run on an all MicroSoft stack (i.e. IIS and MS-SQL). I can’t think of a single other system that switch-hits as well as MODx.

Dashboard

WordPress offers a clean manager dashboard for its administrators which relies on the jQuery JavaScript library to provide AJAX functionality and smooth user experience. It’s pretty easy to find your way around.

MODx underwent a huge change in its manager dashboard between Evolution and Revolution, and the Revolution dashboard is overwhelming for many. Evolution’s dashboard is cleaner and snappier.

MODx Revolution’s manager dashboard is still being optimized. It’s based on ExtJS. For those of you not familiar with ExtJS, it was based on YUI (the Yahoo User Interface library), and it offers some fatastically powerful features for building interfaces for web applications. My only complaint with it is that it’s heavy: the MODx Revo dashboard can take a long time to load, and sometimes clicking on buttons and links feels unresponsive.

Blog

Everybody wants a blog, just like everybody wants a shiny new car. Authoring blogs has been a core competency of WordPress, and they get massive props for making them very simple to setup: out of the box, you can get a blog up and running with integrated tags and categories and comments within minutes. It’s really what WordPress is all about: blogging. WordPress even has some nice security features in place with its Akismet spam filter.

Contrary to some of the on-line murmurings out there, both versions of MODx can run blogs, but until MODX 2.2, the process to set them up was painfully laborious in comparison. The Articles extra for MODX gives you a quick and easy blog — it can even import your posts from WordPress, so the gap between the two systems is closing quickly. The only thing it doesn’t do as well as WordPress right out of the box is its taxonomies (tags and categories): you still have to do some configuration to get those configured how you want them, but as the docs say:

“MODx Revolution is not blogging software, but rather a full-blown Content Application Platform, it doesn’t come pre-packaged with a cookie-cutter blogging solution.” 

Custom Content (CMS functionality)

If blogging is where WordPress shines, then CMS functionality is where MODx clearly has the upper hand. WordPress does support custom fields for its posts and pages, and in version 3.x, they support additional “post types”, so finally WordPress is getting some traction as a CMS, but it’s still a bit of a toy in comparison to MODx.

One of the biggest problems with WordPress as a CMS is its lack of support for sensible custom fields: for each post or page, you have to manually add the same custom fields over and over again, and by default, the custom fields are always simple text fields. I have attempted to rectify this in my Custom Content Type Manager plugin, and my plugin does a lot to give WordPress CMS capabilities, but it still represents a series of awkward workarounds that stretches the WordPress core nearly to its breaking point.

One related area here is how MODx can manage and serve static files via what MODx calls “Static Resources”. This is a great way to enforce permissions on viewing, streaming, or downloading static files (e.g. PDFs or Flash movies). WordPress just flat out can’t do that.

Although MODx offers greater flexibility, WordPress’ integration is a bit cleaner for the manager user (it’s a holy pain in the ass for the developer, but if you download my plugin you should avoid this unpleasantness). When WordPress registers a new “post type”, you get a nice menu icon in your dashboard and it’s really clear to the manager that he/she is adding a new post, page, or movie (etc). For example, if you want to add a movie post, you’d click on “Add Movie”. It’s really quite logical. In MODx, this same type of distinction occurs at the template level. Architecturally, this makes sense, but it’s confusing for the manager user, because it may not be at all clear that they need to add a “normal” page (i.e. resource), and then choose to use the “movie” template. I’m planning a MODx plugin to help rectify this UI “wart”.

SEO

SEO is the an cyclical buzz, and at the moment, a lot of SEO guys are hailing WordPress as the holy grail of search-word wad-shooting. To be blunt, I think SEO is largely an over-hyped crock of crap. If you build a well-structured site with good content, your pages will show up in search results: if there is a site out there with awesome content that is not showing up in relevant search results, I have yet to see it. Search engine optimization is often a pseudo-science practiced by get-rich-quick marketeers who are convinced that they can turn lead into gold by over-hyping a site with various gimmicks. 90% or more of SEO should have to do with creating good content, and perhaps the last 10% of your efforts should go into polishing your site. It can be used to improve search results, but it tends to fail when you try to make search results come out of thin air. Too often I have seen companies do this the wrong way around: they spend 90% of their time publicizing a site that is a vapid cesspool instead of spending their time making a site that’s worth visiting. At best, SEO techniques are constantly changing as Google updates and refines their indexing algorithms. If you optimize your site today and Google farts tomorrow, all of your work may be for naught. Do your due dilligence, but it’s just not worth spending inordinate amounts of time tring to beat Google at their own game.

Rants aside, both systems offer ample ways to do search engine optimization. Assuming that you have good content, the rest of the process boils down to having well structured HTML (which relies on a solid templating system), and the ability to effectively index your pages. WordPress offers built-in taxonomies (categories and tags) for flagging your posts, and MODx can be set up to do this rather easily by using an Auto-Tag custom field (a.k.a. a MODx “Template Variable”).

MODx offers a much more flexible system for generating URLs (basically you can use any URL you want for any page). WordPress does offer flexibility here, except for its special pages (e.g. category listings or author pages).

Security

No system is 100% secure. MODx has had relatively few serious exploits; WordPress has had many, no doubt due in part to its popularity. For what it’s worth, I have had WordPress and MODx Evolution sites hacked, but not yet a Revolution site. It’s hard to quantify how secure an application is… I’d love to see the detailed forensic results of a penetration test against default installations of both CMS’s. In general though, the WordPress architecture is primitive and more ripe for being hacked: it’s more difficult to lock down spaghetti code. WordPress also offers many more plugins, and the plugin authors tend to be less experienced, so their code is more likely to have security holes.

There are many fingerprinting utilities out there that will attempt to locate known weaknesses in plugins, and WordPress is more easily fingerprinted; MODx Revo allows you to change default locations for the MODx manager or to even remove it from public view altogether. There are some discussions in the MODx Forums about how to harden MODx, but I haven’t yet seen a detailed how-to on how to eliminate the most common attack vectors. There are also good posts out there for hardening WordPress.

I reported a nasty vulnerability in phpThumb that affected MODx and numerous other CMS’s (phpThumb is a popular image manipulation library), but the MODx Revo architecture prevented the exploit from succeeding on Revo (good job to Shaun and Jason for architecting the connectors in the way they did).

Support

This is another area that is pretty black and white in my opinion: WordPress support sucks. Although WordPress is more popular if you look at the numbers, you wouldn’t know it if you post questions in the WordPress Forums. I have rarely gotten any useful answers (if I got answers at all): anything beyond simple inquiries tend to go unanswered, leaving me alone in the dark reverse-engineering damn near everything.

My other gripe with WordPres is their weird distinction between WordPress.com and WordPress.org. You can host your blog at WordPress.com, and then you get more support, but it is effectively software as service: you can’t upload plugins and you can’t modify code, so the interface suddenly becomes a bit like BlogSpot.

By contrast, the MODx Forums are full of helpful people. It’s a great place to be: it’s not uncommon to get responses from the core team on almost any level of inquiry, from trivial to cerebral meltdowns. There are some superstar participants, such as Susan Ottwell and Bob Ray, who have both contributed immensely helpful posts and tutorials on how to use MODx. MODx also offers commercial support; it’s still in its infancy, but for a yearly fee, you can get access to a kind of “MODx hotline” and get help resolving MODx issues on your sites.

Documentation

In the same breath as support, I must mention documentation. In general, documentation for both systems is lacking, in some areas painfully so. While using WordPress, I have often I have searched for hours trying to find a way to do a certain thing, only to end up grepping through the code base and deciphering the raw code myself. Frequently the official documentation has holes or in some cases, it’s just plain wrong. The best resources for some advanced WordPress features are blogs written other developers.

MODx’s documentation is also frustratingly AWOL on a number of topics, but least the MODx code base is integrated with a standard documentation publishing system so if needed you can see for yourself how the functions are structured without having to grep through the code base. The vibrant MODx forums fill in a lot of the holes in the documentation, and that’s a huge benefit for any open-source project.

Scalability

WordPress can handle a huge number of posts, but it does get bogged down with a large number of pages, and there are lots of whisperings about this. I suspect it has to do with WordPress’ convoluted templating system (see above), which makes me wonder what the limits are on custom post types.

MODx Evolution suffered from a limit of approximately 5000 resources (in MODx, pages and posts are types of resources), but that limit has been corrected in an upcoming release thanks largely to the efforts of Charlie over at ProWebscape.com.

MODx Revolution has no such limits: it offers a great built-in caching system that allows it to serve pages very quickly. It has been benchmarked as twice as fast as Expression Engine.

More importantly, MODx Revolution was built with scaling in mind: it stores session data in the database, so it is easily deployed on load-balanced servers. This is hugely important if you are building a site that might one day get massive amounts of traffic; WordPress can be deployed like this, but such usage is not generally anticipated.

Conclusion

I do like both systems, and I use them both daily. WordPress has a much lighter footprint and is easier to use for a large number of use-cases: if you just need to get a site out the door fast, then WordPress is really hard to beat. WordPress is plug-and-play for just about everything and that saves you hours of setup time, so it can be the right solution for a majority of sites. But the more customizations you require (particularly in scripts or in layouts), then the more appealing MODx becomes: WordPress has thousands of plugins available, but if those aren’t meeting your needs, I’ve found certain types of customizations to be extremely difficult in WordPress whereas most often, MODx handles them with ease. Doing things like building web applications with strict formatting requirements is much easier in MODx because it’s built more as a launchpad for customizations: it’s really more of a content management framework (CMF). MODx Evolution is the best system I’ve used for building small to medium sized informational/brochure sites, WordPress rules as the blogging king, and I’ve been very impressed with how easily I can build web applications using MODx Revolution. There isn’t one tool that’s right for every job; the more projects you complete, the better idea you’ll have as to which system will accomplish your requirements more easily, and hopefully this article helps you spot more of what each system is good at.

-- Everett Griffiths