Editor’s note: Graham put together the comparison PDF (which we’ve mirrored here) that was passed around and commented on last weekend. Before writing anything up about it we contacted Graham to find out more about it. His response was very interesting, so we asked if we might post it here for further discussion.
This PDF was put together for a client project. I’m working on a website redesign for a major university faculty, inclusive of about 6 different semi-autonomous department sites. The dream is to build a network of websites that comprise the faculty, sharing core information where necessary (such as membership, global navigation and aggregated content like news & events from each department), while maintaining discrete control for each department to manage their own content.
The big debate at the onset of this project was which content management system to go with.
The general consensus was that WordPress should be used, because it is “open source” and “popular”. As the designer and developer of the project, I strongly pushed for ExpressionEngine. I put together this PDF to back up my case.
My thesis here is that WordPress is designed as a single content channel system. Typically, this means a “blog”, with posts. Over the years, WordPress has (admirably) evolved to encompass much, much more than this, through third-party plugins, hacks and now the merger of WordPressμ and custom taxonomies in WordPress 3.0. I have no question about the power of WordPress and the incredible flexibility, ease-of-use and sexy turn-key solutions provided by thousands of ready-made themes.
My thesis here is that WordPress is designed as a single content channel system.
By contrast, ExpressionEngine is designed as a multiple content channel system. It makes no assumptions from the beginning about how the website will be structured, or how data will be used. It simply aims to bring the tools to the hands of the developer necessary to build the kind of site they need, while abstracting as much as possible away from the core PHP (ExpressionEngine is built on CodeIgnitor, a PHP framework, and it’s certainly possibly to use straight PHP within ExpressionEngine. But why? ExpressionEngine’s tagging system adds a more user/developer-friendly layer to site development).
My contention is that WordPress is not a proper content management system. As a developer, I’ve found it to be potentially disastrous to work with on large scale, complex projects, involving many content channels. It’s simply not designed to handle this architecture very well. Not that it can’t in many ways, if pushed, poked, prodded, tweaked, hacked, and jimmied. But that’s beside the point.
My PDF outlines the core architectural differences between WordPress and ExpressionEngine. Highlighting the differences is really the point of it. The bits about security and support costs are dubious. I’m sure WordPress is plenty secure, and I’m aware the support from the public community is tremendous. I know there’s probably some other bias in the sources; this PDF was quite intentionally designed by me as a pitching tool for ExpressionEngine, not as a fair and neutral analysis.
Apples and oranges
In fairness, I wish I didn’t even have to produce a PDF like this in the first place. To me, ExpressionEngine and WP are not designed for the same thing, and shouldn’t really be compared one to one like this. However, as a testament to the success of WordPress, it occupies a huge mindshare with the casual user. I often have clients come to me requesting to use WordPress simply because they’ve heard about it.
Brandon Kelly, a developer of ExpressionEngine plug-ins, put together what I think is probably the best articulated discussion I’ve seen on this topic, in general: http://brandon-kelly.com/blog/custom-fields
I especially love the quote from Rick Ellis, designer of ExpressionEngine:
Bruce Lee said that the ultimate technique is no technique. What he meant is that the goal of a martial artist is to posses such well developed knowledge, awareness, fluidity, timing, and sensitivity, that the specific techniques don’t matter anymore; the goal is to go beyond technique into a state of pure effectiveness.
So in a way I have this vague idea that Custom Fields should evolve into a vehicle that is so transparent, intuitive, flexible, and useful, that it allows a pure expression of information, without the constraints of boxes on a page. I don’t have a design concept yet, but I do believe we’re far from having perfect tools.
This philosophy really is core to ExpressionEngine’s design, which is what I believe fundamentally separates it from WordPress.
If WordPress has a mandate, I imagine it to be something like, “Blogging for the people” — a simple, easy-to-use, but powerful system that brings simple content publishing to the masses. The keyword is simple. I don’t mean this as an insult, but simply as a description of its design—a single content channel system is, by definition, much simpler when compared to a multiple content channel system. To this end, WordPress is extremely successful — people with no website experience whatsoever can have a beautiful WordPress-powered site running in minutes.
By contrast, ExpressionEngine’s mandate is something along the lines of “a blank canvas for your data”. As ExpressionEngine evolves, it is moving further and further away from “blogging” (indeed, with ExpressionEngine 2, EllisLabs intentionally dropped “weblog” as a term, replacing it with the more generic “channel”). The point of ExpressionEngine is to be as unassuming as possible about the final end form of that data.
Derek Jones makes this point well, regarding the new Publish Layout feature in ExpressionEngine 2:
This came about entirely in response to the demands being made on ExpressionEngine for publishing wider varieties of content. The HTML form that is well suited to publishing articles for a newspaper or online magazine are entirely different from the form that is well suited to entering hundreds of business addresses and phone numbers. Extending on EE’s principle of making no assumptions about your data, we decided to make no assumption about what your client’s publish form needs to look like, and let you decide.
This really lends itself to large scale, custom projects, where the form of data is anything but a standard theme. For instance, a university faculty website featuring six very distinct departments, each with their own content needs.
WordPress 3.0 was a step (leap?) in the right direction, to open up WordPress to a broader context of use. I applaud the movement. But as a developer, I can’t say it is there yet for the kinds of sites I develop. WordPress’ custom fields and taxonomies are still very primitive (the PHP is nasty, sorry—I don’t want to have to pop the hood to turn on the windshield wipers, so to speak) and structured for a single content channel. Because of this, the prospect of having to work in WordPress was giving me cold sweats before my client mercifully agreed to move forward with ExpressionEngine. I couldn’t imagine how I would accomplish the things I needed to under this model without a lot of headache—and no official support.
Use the best tool for each job
At the end of the day, both are PHP, and mostly just a fancy frontend to a MySQL database. Which is “best” doesn’t actually matter that much. What matters is what tool will get the job done in the hands of the developer who is developing it. In my case, the best tool is ExpressionEngine. I know it, I love it, and I wouldn’t trade it in a second for WordPress. In the case of many WPCandy readers, I suspect the exact opposite may be true.
There’s often a great deal of (possibly misplaced) passion on the subject of WordPress “vs” ExpressionEngine, when—as noted above—the two are really apples to oranges.