The Best CMS

So what’s the best CMS? WordPress, Drupal, ExpressionEngine, another? A question I’m often asked and to which I can only answer: it depends. It depends both on who you are and what you are trying to do.

When to use a packaged solution

Packaged CMSs give a lot of functionality for free and people who take the time to learn them, love them. I think this is especially true for designers and content publishers as it allows them to do things that they weren’t capable of before. As they work with the platform more and more they see with a little plugin here, a little tweak there, they can solve many of their problems.

However, I would recommend these rough guidelines for when and what to use to avoid the “when all you got is a hammer everything looks like a nail” syndrome:

• Most packages are good in what they are trying to do; often bad when forcing them to do something else.
• WordPress, Drupal, and ExpressionEngine seem best suited for one-man teams.
• If you stray far from the built-in features, consider building by hand.

Use a CMS when what you are coding is primarily a CMS

Don’t try to build a picture sharing site using WordPress, or a multi-lingual e-commerce solution using ExpressionEngine. I’m sure it can be done, but the more that you try to stuff a square peg in a round hole, the more inefficiencies and frustrations await you.

The right peg

• Use WordPress if you are primarily making a blog or publishing articles, a one-man team will be implementing the product, and/or do not have the internal technical resources to roll your own.
• EE for more complex sites with multiple data models, are a one-man team, and the site is primarily manipulating content blocks.
• Drupal I have much less experience with, but seems to also have its die-hard fans. My understanding is that it would be in the same realm as EE.

I am curious where others feel about this broadsword evaluation and how they would evaluate other packaged CMS products. Please add your comments below :)

The one-man team

Most of the above-mentioned CMSs use the database to store configuration, data models, and, in some cases, display templates. This is probably fine if you are working on it by yourself, but makes it difficult to use Git, Subversion, or other version control tools that allow multiple developers to code simultaneously (I also find it very annoying to be forced to write any code in a browser and find that it makes developing on local and deploying to production a pain).

Packaged CMS for companies with limited technical resources

I say this in partly in retrospect from what we did with the site you are looking at: theplant.jp. We built this on WordPress.

With a site that is primarily static contents and extremely simple functionality we should have rolled our own simple CMS for updating the only contents that changes frequently: the blog and comments. We could have pumped that out in just a few hours. The static contents are, well, static. All of us here could more easily edit a text file and deploy it to the server and not have to worry about:

• Learning the WordPress-specific library of functions
• Trying to force it to be a multi-lingual company CMS when it was not made to be one.
• Wading through the admin. The development of all platforms with additional features both gives and takes. We actually only need one feature: add/edit/delete and article. However, each time we login, we are always faced with an admin full of tools to administer features and contents that we don’t need.
• Being attacked by WP-targeting spam and attacks and associated hassle of continually updating the software for security fixes.
• Speed issues for creating dynamic contents when, in fact, they don’t need to be dynamic. Cacheing and other strategies will help this, but they are really a kludge when the contents are primarily static in nature.

This is no fault of WordPress per say, it does what it does extremely well: enables people to publish blogs/articles, it was just a bad choice for us as we were not lacking technical resources to solve our problem more elegantly.

What we are doing from now on: QorCMS

We are using are experience over the years from developing custom solutions for MTV Japan, ASICS, OnitsukaTiger, and CMS solutions for many others and have developed a beta version that we will soon release of what we are calling internally QorCMS.

If Rails is like a piece of cloth which can be customized into all kinds of clothes, QorCMS is a well tailored business suit for the business man. QorCMS is still a framework for developers instead of a final product, but it enables us to rapidly develop custom solutions.

QorCMS includes lots of common modules that a CMS needs (auth, upload, file serve), a flexible content model map and other enhancements to Rails (it’s based on Rails, but has many utilities and fancy helpers). QorCMS code is backed by a battery of coded test cases so that we can depend on the features. Again, the goal of QorCMS is a basic framework, not an instant fantastic CMS. Our clients will get this after some configuration and coding to match their specific needs.

It may seem like this is just another CMS, and in some ways it is, but we wrote it and that makes all the difference because we:

• Are driving the bus and don’t need to be tied to an external development team’s roadmap for feature enhancement or having to hack our own features that may break in the next update.
• Can extend it extremely easily.
• Administer the features through code, not through a GUI which we find to be much more efficient.
• Keep data models, templates, and configurations in the code, not in the database, so it is very easy for several developers to work on the same project at the same time.
• Integrate with the 3rd party services we like best, like GoogleDocs, GoogleMaps, Amazon Webservices, and Mailchimp
• Make our code safer, with (hopefully) less flaws than we have seen in other solutions.

The downside for our clients is that it is our code, so they may perceive themselves as being more tightly bound to a single developer. However, unless it is a vanilla install of a CMS with no alteration, they will be probably end up being just as tied to another vendor and, hey, we are not a bad company to be in cahoots with anyway.