On choosing a CMS

Posted on January 7, 2012

Most of the work I’ve done in the past few months has been centered around building a number of websites for a large company. The main requirements were that the sites all had to work off of the same database (as there would be sharing of data), and that each site had to have its own local translations. We had to make a decision on how best to implement this, and the choices were basically Drupal, WordPress, or a custom solution. Immediately off the bat we decided that Drupal was out. I’ve spent enough time on here talking about why Drupal sucks, but it just wouldn’t have worked here for a number of reasons. We were under a time crunch, so rolling our own backend solution would’ve taken too long, so we decided on WordPress. I fully admit that this site is built in WordPress, and I’ve come to be rather familiar with it over time.But now I wonder if WordPress really was the right solution. Between multiple domains, languages, and custom post types and fields, we’re really sort of pushing WordPress to the limit, and I can’t help but think if it would have been more stable to have built a custom CMS.

Part of the problem is that, with all large CMSes like Drupal and WordPress, you use third-party plugins. It makes sense: someone else has implemented some common functionality, so rather than reinventing the wheel, you just download and use the plugin. The problems start, though, when a plugin doesn’t do exactly what you want it to. Yes, that’s why forking exists, but then the option to get new functionality for your plugins is lost. The main issue that comes to mind is the intersect between the translate and custom fields plugins we used: they didn’t work together. Luckily someone else had built a plugin to get them to work with each other, but it didn’t do it for all fields, so I had to write a whole lot of custom code to get everything to play nicely. Sometimes it’s that the plugins need to be written to be as open as WordPress is – for example, building their own filters so content can be modified – but it may also just be that the functionality that you need is just beyond the scope of the plugin in itself.

Or perhaps the CMS itself is the problem. I’m not a huge fan of how WordPress stores some of its data (take a look at the wp_postmeta table, for example). Moving a WordPress site from a dev or staging environment onto production is also quite a bit of a hassle. (Sidebar – I’ll have a post coming soon about how to mitigate the pain from that.) Had we rolled our own solution in this case, much of this would not have been an issue.

I do sort of wish that there was a really viable third way: a CMS built on a good framework. I’ve interacted with a few in the past, but none really ever really struck me as good enough to use for a large scale project. Basically I want the backend style of WordPress and some of its functionality, but built on a framework (Symfony, Zend, whatever) where I can add anything I want on top of it. Bonus points if the developer maintains the CMS and doesn’t let it fall into disrepair: all too many of the current CMS-on-framework solutions have gone down that path.

Leave a Reply

Your email address will not be published. Required fields are marked *