WordPress vs. MODx

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 (see this how-to).

Summary

In short, WordPress and MODx Evolution are easily installed on practically any web server that supports PHP and MySQL. MODx Revo takes longer to install and configure and it requires a beefier server.

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.

WordPress Template Hierarchy

WordPress Template Hierarchy

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?

Summary

If having a specific HTML/CSS layout for your site is more than a “nice-to-have”, then MODx will save you many hours; the time to rework layouts in WordPress can be considerable and some of the PHP hacks are not trivial, whereas MODx templates are easy to create, modify, and maintain.

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.

Summary

If the site you are building is more of a web application that requires a lot of custom coding, go with MODx; the level of maturity in the underlying MODx framework is light years ahead of WordPress, but be advised that the coding in MODx is sometimes so advanced, it takes a very senior developer to understand what’s going on. If you decide to do a more serious application-type-project in WordPress, be sure to allocate extra time to augment or rewrite the core code. If you’re doing basic extensions or variations of a simple site/blog, then WordPress plugins can do that pretty well, so don’t overcomplicate things.

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.

WordPress Manager dashboard

WordPress Manager dashboard

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 Evolution Dashboard

MODx Evolution Dashboard

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.

MODx Revo dashboard

MODx Revo dashboard

Summary

Do not make your decision about which system to use based on the dashboard alone — that’s like marrying a girl for how big her tits are. I know some clients who have loved and hated the dashboards in both systems. Again, MODx offers more flexibility if you want to change the dashboard behavior. The big difference here is simple: WordPress gives you a super clean view of your posts based on time whereas MODx gives you a hierarchical view of your posts.

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.” 

Summary

If your priority is to get a blog up and running as quickly as possible, and you have few requirements for supporting any other content, then WordPress is the way to go. Starting with MODX 2.2, however, you can use its “Articles” extra, which gives you simple blogging functionality, with many of the features available to WordPress.

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”.

A custom post type in WordPress

A custom post type in WordPress

Summary

If you have to display multiple types of content on your site (e.g. an eCommerce site), then MODx offers far greater flexibility, but it does take longer to configure. If your CMS requirements are simple and you don’t need to worry too much about customizations, then WordPress can do that very well and very quickly.

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).

Summary

Comparing SEO features between MODx and WordPress is a moot point: both systems allow you to adequately structure your content and your site.

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).

Summary

I feel that MODx Revolution is probably more secure, but there are no guarantees when it comes to security. No system is bulletproof, so you best have redundant backups on hand and follow the recommendations of Basic Web Security no matter which system you’re on.

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.

Summary

If you need support for your site, especially guaranteed support, then only MODx offers a paid support service; WordPress doesn’t offer a paid support option.

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 (e.g. here). 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 (see this blog post).

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. I don’t know of many large commercial sites running WordPress (in fact, I only found one: 9rules.com).

Summary

MODx is by far the more mature option here if you anticipate building a large site.

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.

25 thoughts on “WordPress vs. MODx

  1. Great article Everett…I really appreciate you writing this to give a side by side comparison. For whatever reason, I’ve been getting a lot of phone calls lately from clients that hear WP is all the rage but yet don’t understand why. While one CMS is not perfect for every situation, I find MODx right for about 97% of my projects. WP definitely has its place when it comes to blogging, but once you move past that needed functionality, we’ve found a lot of challenges that MODx handles with extreme ease.

  2. Well written article. I personally love MODX revolution and have been developing big sites such as The Loughborough building society site and although I encountered some problems, there was always a solution through writing custom PHP snippets. WordPress on the other hand doesn’t feel like real web development to me as you can easily buy a premium template and change the images before rolling out a site in hours and every site has the same structure.

  3. Great comparision. we started to use MODx since last 9 months. Personally i haven’t used it yet as i was in magento group and just moved to MODx group in my company and hope to start using it soon :)

  4. Might just be the writing style, but you seem to have made your mind up long before doing any actual in-depth comparison – as such this whole piece feels amazingly biased and weighted toward MODx, often not giving WordPress credit where due. And you use the fact that you’ve authored a book on WP Plugin Development to give weight to some pretty hairy conclusions.

    I’m no fanboy – a tool is a tool and every tool has its purpose – but the reality is that both are very powerful platforms, capable of very different things. For example – the WordPress template hierarchy is one of its strong points, and you seem to be using the fact that you find it difficult to grasp as proof that it’s a bad design decision.

    WordPress will always have a stronger plugin-development community because (at the moment) it’s just easier to develop WordPress plugins, in terms of the learning curve – of course (with it being open-source software) this means that there will be more cruft, as people can more easily get started with it – but I don’t think that’s a weakness.

    A few points to consider:

    “If you are a developer or you require custom development of plugins for your site, go with MODx; the level of maturity in the underlying MODx framework is light years ahead of WordPress. If you decide to do a more serious project in WordPress, be sure to allocate extra time to augment or rewrite the core code.” – I find it amazing that someone who’s co-authored a book on WP plugin Development could come up with this summary. Sure, MODx is very powerful in terms of customising functionality, but the learning curve is harder, the community (as yet) smaller), and the architecture much more difficult to get to grips with.

    “MODx is by far the more mature option here if you anticipate building a large site.” – Spotify.com (http://www.spotify.com/) runs on WordPress – along with thousands of other massive sites, with complex functionality. Not saying that MODx is immature for the purpose, but you’re comparing apples to oranges and getting, er, durian.

    Sorry to sound negative but this article is really not winning it for me – would love to hear your response.

    Cheers,

  5. Joss, no need to apologize — it’s your opinion, and it’s not my intention to “win it for you” — it’s just me sharing conclusions after spending a lot of time with both systems. And yes, my writing style pretty much aims for the jugular, and I don’t apologize for that: I do (and did) take aim at things that I feel are in need of improvement.

    I have spent thousands of hours with both systems to reach the conclusions I’ve reached, so your comment about me “having made up my mind before doing any in-depth comparison” is … well… ridiculous. Consider the possibility that my opinions were extremely well thought out.

    Oiy… the WP template hierarchy… just because I hate it doesn’t mean I don’t GRASP it. I GET it. And I find it completely poorly designed because it flies in the face sound architectural principles, : WordPress templates come out being like little applications that blur the distinction between logic and presentation layers in very unhealthy ways, and kudos to you if you can point out the design pattern that this supposedly follows. I stand by my opinions of this: having this kind of application logic in the view layer is a surefire way to make an application buggy and difficult to maintain, but PHP devs in particular tolerate an amazing amount of cruft like this. You rewrite a few applications coded by junior developers and you start smelling the stink of that stuff from a mile away. The most PC thing I can say about this is that as a designer or developer, you end up wasting a lot of time working with a system like that.

    The WordPress plugin community… wow… throughout the course of writing the book and developing several WP sites, I got virtually NO responses from anyone in the forums, so I’m not sure which community you’re referring to… the community there seems damn near a ghost town to me. And I disagree that WP is easier to develop in, at least for basic PHP stuff. Writing a MODx Snippet to print out “Hello World” inside one of your pages is simply trivial; to do that same task in WordPress requires a series of functions and hooks. MODx can get into head-splitting complexity too, but it also makes simple things simple, whereas WP is more of a constant medium-level of difficulty for most tasks, and certain advanced situations simply aren’t possible.

    Re warnings to “to allocate extra time to augment or rewrite the core code”… that conclusion specifically came FROM writing the book and from coding several WP sites over the past few months. If it’s hard for you swallow that, just imagine how hard it was for me to swallow how incomplete and arbitrarily limited some of the core WP functions were. My thought process went like this on multiple occasions: “Surely, there’s an API function that does that…” and then I’d spend sometimes entire days looking for something (remember: the “community” was largely unhelpful for stuff like this), then finally crawling through the WP code base only to realize to my horror that “Holy @%~@ing Sh*T! IT DOESN’T DO THAT!!! NOT EVEN CLOSE!!!” I bet that if you wrote a similar book and started putting WP through its paces, you’d start finding the same gaping holes. Of course, stuff like that has happened to me on every platform, but it simply happened a whole lot more while using WP. So as a developer, I found that WP made for a lousy wingman — it never had my back.

    Just because a massive site *can* run on WordPress doesn’t mean WordPress is well-suited for that purpose. I don’t think it’s apples to durian either. You can look at the maximum number of requests served per second or look at your bill from the sysadmins to set up both systems on load-balanced servers and you’ll get raw facts: numbers to numbers. And knowing the underlying architecture of both systems, I know that MODx is easier to scale because it was built with scaling in mind. It’s sorta like comparing 2 cities, say Los Angeles and Bogotá, Colombia: if you dump 15 million cars on the roads in both cities, you’ll see real quick which city has the better-architected freeway system.

  6. Great to see a detailed comparison between my two favourite CMS’s, and having built many websites using both over the years I wholly agree with your findings.

    With so much buzz around WordPress with clients and account personnel, it can be hard to persuade them that sometimes it is not always the best solution. I know its fun to use, but for serious data manipulation and management it often falls short.

    Thanks for your insight, it justifies much that I have felt in the past.

  7. Thanks for the article… interesting points. I used a number of CMS before coming across MODx and realising I’d found a darn good system. You mentioned ExpressionEngine (which I’ve used a fair bit) but my list of reservations seem to have slowly grown over time – however I recognise it’s often very personal and directly related to the types of project you’re individually involved in, plus no CMS/CMF is ever going to be ideal in all scenarios.

    Re WP I think you may have been a little harsh and the core team have been cautious in expanding the possibilities beyond essentially a blogging platform (where it’s hard to beat if you need something up and running ‘yesterday’ with pretty much all the bells and whistles blogging folk have become used to). I’d put much of the success of WP down to being so easy to get started with, but, much like PHP you could argue that the low barrier to getting started is potentially also it’s greatest weakness and as you say not hard to find some very bad coding in themes and plugins. Having said that, I think the core team have recognised there’d be a lot of benefits if the core capabilities were extended and looks like some promising signs in that direction; plus I think they recognise weaknesses in the underlying architecture which are at least partly due to being early in the arena and now being held back by requirement of backward compatibility. MODx took the brave gamble of a ground-up rewrite to produce Revolution but looks like it’s paying off now as this version starts to reap the rewards of a design based on some of the best modern software design patterns…

    I think it’s definitely worth taking a look at the work being done by the PodsCMS plugin team http://podscms.org/ if you’re looking to use WP for more general content management beyond blogging (and the new PodsCMS 2.0 looking good); however, agree that if you’re looking to do a big really scalable site then MODx a much ‘cleaner’ and robust starting point. Whilst I’m on this point I think SilverStripe http://silverstripe.org/ is probably the closest competitor to MODx (especially with the forthcoming 3.0 version) and newcomer ProcessWire definitely worth keeping and eye on ;)

  8. Anyone got a dedicated server I could use to benchmark these 2 systems? I’d love to do that…

    ocPortal? I haven’t heard of it… gonna try downloading it and poking around. They have a weird download process. And 17 mb is a big package. Heheh… big package.

  9. Well, my initial thoughts of ocPortal are that it’s not for me… that was a LONG install and jeez… they should have summarized all the permissions errors on one page instead of popping them up one… after… another. There is a 10 step wizard for just about everything. I don’t like this much hand-holding because I have no idea where they’re taking me. Right off the bat, I can see that the architecture is funneling you towards simplicity, so I’m wondering how customizable this is… e.g. having to pick which menu a page shows up in when creating a page? Weird. Also got a few JS errors, and found pop-up windows to control functionality is a bad move in my opinion. But that’s just simple comments after spending a few minutes with it. I don’t think I’ll spend enough time with it to merit a separate article, unfortunately.

  10. Martin – thanks for your input. Those are very fair points: I was pretty harsh. I have been massively frustrated with some of the core and the lack of responses in the WP forums and the virtual stonewalling from the WP people itself (I can only take so much of “talk to the hand”). To be fair, WordPress IS much easier to use. You can get a WP site out the door in a matter of minutes. MODx tends to take quite a bit longer (both Evo and Revo)… MODx allows for lots of customizations, but at a cost of time. WP custom work is at a higher premium due to the simplistic architecture.

    I have heard very good things about Silverstripe, so it’s high on my list of systems to look into. EE is popular, and I frankly love the simplicity of CodeIgniter (save for a few boggling omissions, e.g. support for $_GET parameters), but EE seems to have lost some of that MVC logic stuff when it built on CI (don’t know why). I haven’t looked at podscms either… looks like I could have some fun digging around.

  11. Some point you got it right but some are wrong from my perspective. I explain it a little bit further.

    About templating I like the way WordPress does it. In my eyes it is better then MODx because MODx let you define complete templates you can do that to in WordPress if you really want. But from a user perspective it just want to add content in the way it needs without thinking about which template it need to select. I do think templating is something you can’t make everyone happy with.

    With menus I wonder why you say that wayfinder is more flexible. It really a code string what a normal user probably won’t understand. The new menu in WordPress 3.0 let the user create his own menu. If the template only support 1 or 2 then indeed the template should change but I don’t see the problem there.

    The Custom Content i do like in WordPress. Never really played it within MODx till now. I do have to say that I never use custom fields. In my opinion this is something that should never been in the core. It really on the memory of the user. I always create own meta boxes so the user knows what it do.
    I think the reason why I never tried it in MODx is that it is pretty hard to get stuff done. WordPress does a really good job with the registration proces. It is easy and fast to get something showed. Of course this has a problem because things that aren’t possible within the registration proces will be hard to get done.

    The security I only can say the following: I reported a big issue related to the login plugin the core MODx support and I got wimped by them. Bug report get closed without any message. In my opinion that is a big issue. I though Shaun closed it. Problem was that MODx saves form input within a session and also the password.

    Community
    Within support it always depends on the quality of the people on it. And in my experience the quality change by time. If i look to WordPress I think the community is pretty big and helping. I posted questions on both forums and I had with both I didn’t get an answer. If you ask core question in a WordPress forum indeed ou will not get helped.

    About the documentation I think both system fails. For function examples I think WordPress is better. Easy to find stuff within the codex. But indeed sometimes the information is outdated or not completely filled in. But with MODx I have a hard time to find information.

    About your complains for the virtual stonewalling it is in my opinion bullshit. I do talk sometimes with the people and they really listen. What you can expect is that they do everything you say. For a system with so much users they can’t just rewrite everything. I believe they also want to change a lot of thing in the core but it takes time to do it right and without to much troubles

  12. Marko,

    I think Everett is talking about the differences between WP and MODX from the implementation side and making his argument about why as a developer preparing a site for turning over to a client user is different in MODX than in WP. End users in MODX shouldn’t ever need to think about Wayfinder or the Templates just as a blog author in WP shouldn’t have to think about the theme. Users don’t need to know about templates at all really. If you assign a template to a particular set of resources below a parent in the case of a blog or a staff directory to auto inherit the template and customize the resource fields using Form Customization they get to just fill out the fields that apply to the content type.

    The fact that you don’t use custom fields (or TVs as they are termed in MODX) baffles me. WordPress, MODX, Drupal, and most other Web CMS applications offer the ability to associate custom content fields with a document (resource) because it allows people to interact with forms and the content output is a result of those inputs and the designer’s vision and not dependent on the ability of an end user to manage HTML formatting which is what I am assuming you are doing for your clients.

    As far as your bug report being closed there are any number of reasons a bug report will get closed without comment but most of the time it is due to the fact it is a duplicate or is fixed. We never ignore bug reports but can’t answer every single incorrectly filed issue. I am not blaming you for this as we need to always do a better job of helping folks understand why something happened. It can make you feel rejected or like we don’t care that you took the time to offer what you thought was a completely valid issue.

  13. Thanks Jay, yes, I really approached this from the standpoint of the developer. I fully concede that if your goal is to get a site out the door FAST, then WordPress is a great option.

    Marko, I will stick to my guns: the WP template integration is just poor; it’s not as bad as Drupal’s, but that’s not saying much. WordPress could have done EVERYTHING you like about having a set of dedicated templates and they could have done it in way that followed sound architectural principles. But they did not: wading through the loop and the blurring of logic and presentation layers is just completely unnecessary and ultimately it bites you in the ass if you need to customize the templates.

    Re WayFinder being more flexible: it may not be made for the end user , but it is unquestionably more flexible. To use the WP menus in the GUI is great until you start wanting to list specific posts or if you need to create several different menus on several different pages. I’ve had to rewrite that stuff to pull it off in WordPress on damn near every site I’ve done. Same with Drupal: the GUI menu options are nice, but they are very limited. My argument is about flexibility, not about ease of use.

    Re the stonewalling: if you got someone over at WordPress who listens to you and answers technical questions about the software, then you are a luckier man than I. I got no detailed answers from anyone in the forums and no responses to repeated emails. I feel like every trivial little thing I learned about WordPress I had to figure out on my own. If you think that my conclusions from that are bullshit, that’s your opinion. The facts remain: I got none of my questions answered via any of the official WordPress channels. I wasn’t asking them to change anything, I was just asking how to accomplish certain things, and the repeated lack of responses really stood out.

    Every developer I know has had bug reports and feature requests rejected. It’s part of software development.

    Overall I stand by the conclusions that I’ve gleaned from my experiences: WordPress is awesome for cranking out quick blog sites, but MODx is the more mature architecture and it lends itself to customization far more easily. There’s no one tool that’s right for every job, but MODx can field a lot more scenarios with much greater ease.

  14. Here’s a nice related article with a good comparison chart: http://davidchu.net/wblog/index.php/2010/04/modx-and-wordpress-a-comparison-chart/

    I will say that WordPress’ core competency from a UI perspective is plug-and-play functionality. MODx can do a whole lot of stuff, but it often takes a fair amount of time to do it. WordPress will get you a lot of places with the click of the mouse, but it hits a brick wall at a certain point when it comes to certain customizations. MODx always requires more time-intensive customizations for simple and for more complicated things. I’m trying to capture a good analogy for that…

  15. I notice you have ease of installation but not updating. In the WP administration panel their will be a notification and, a few clicks later, WP will be updated. This is something MODx needs, especially with Revo undergoing so many updates at the moment.

    If you are on a Mac and trying to update through your third party hosting server (Bluehost, Godaddy, whoever) it is almost easier, and quicker, to delete MODx and start over.

    That said, I work with both and still prefer MODx.

  16. Wow… I’ve never had that much trouble upgrading MODx, but you’re right, this is much much easier in WP. MODx has this planned for version 2.2 or 2.3 (?), and it will be a welcome feature.

    When I do updates, I jump into the command line, wget the zip file and extract it. Then I simply do a recursive copy operation over the current install (after making a backup of course). The shell command looks something like this:

    \cp -fr modx-2.0.8-pl/* /path/to/existing/html

    The \ before the cp command will trump the default option to prompt you for overwrites at every hiccup.

    Some FTP clients have an option to do a “merge” option when you can copy one folder into another recursively.

    Once you’ve merged the upgrade with the existing, you just have to run the setup. It usually only takes me 5 or 10 minutes.

    1. “Wow… I’ve never had that much trouble upgrading MODx”

      Lucky you.

      “Some FTP clients have an option to do a “merge” option when you can copy one folder into another recursively.”

      I’m guessing Fetch is not the way to go as it merrily overwrites files and folders alike. Any suggestions for a Mac, or PC, which will make the seemingly endless updates possible? It looks like Panic’s Transmit might work but I’m open to suggestions. If I have to wait till 2.2 or 2.3 I will most likely be spending my days downing Prozac like Skittles.

  17. As Han Solo never said: “Hokey protocols and ancient FTP clients are no match for a SSH login at your side, kid.”

    SSH is really the way to go in my opinion, but I do own both Coda and Transmit, and they both will do the merging options: that saves HOURS of time for updates like this.

  18. An unbelievably thorough, well-thought-out and helpful post! I’ve been a MODXer for a little over a year and I love it. It’s by far my CMS of choice. However I’ve been digging into WordPress out of necessity and am definitely experiencing its power. It’s great to read an article about someone who uses both (which is where I’m headed).

    The big differentiator in my opinion is, you guessed it, templating! With MODX there’s no convoluted theme structure to learn and you don’t have to be a PHP person to integrate custom design. MODX gives you 100% control over markup which is a beautiful thing. With custom design in WordPress you’re better off learning how to template using a WordPress framework or modifying an existing theme to meet your needs.

  19. The killer app for Revo is the Articles package. It provides a drop-in blogging solution for Revo 2.2 (at this time in beta) that has to be experienced to be believed. While the Revo beta interface is still a bit buggy, it’s worth putting it up as a development installation just to experience Articles.

Comments are closed.