The Great CMS Roundup
Everyone's done it and now it's my turn. Since I started working on the web professionally in late-2004, I've hand my hands on Drupal, Joomla, WordPress, ExpressionEngine, and SilverStripe. I've cried and lauded aspects of each one and I'm here today to give my objective comparison of all 5. So, without further ado, let's begin.
Drupal is one of the Big 2 open source CMS's out there. It has a pretty rabid and dedicated community and has definitely been around from the early days of CMS software. It is also maligned by developers who have "moved beyond" its limitations and on to "better" CMS's (I don't mean the quotes in any derisive way, merely just quoting words I've heard people use in context. You're entitled to your opinion about which CMS is the best and so am I). The problems I've found with Drupal are that it's rooted in old coding practices from back when it was released in 2001 in the early days of PHP4. I'm not positive if it was originally written in PHP 3 or 4 but the last time I had my hands in it with a Drupal 5 installation (around 2008), I was still working with procedural code with no sightings of anything resembling OOP practices. I feel it suffers from a problem of any software that's been around for a while in that rebuilding the code under the hood would be such a huge undertaking that new versions just strap on new functionality in some hybrid coding practice of the old and the new.
The admin panel is not very intuitive either. In order to make a new page on the site, you have to jump around to 3 or 4 different panels for doing something that should be pretty simple. There's also so many sections for changing settings and such that it's easy to get lost and impossible to find what you need, especially for a non-tech-savvy site maintainer. Drupal has evolved to be very flexible but it has become extremely complicated along the way as a side effect.
One thing I can't argue with is the plethora of modules that extend the functionality. With its age comes a lot of time to build and refine the modules for it AND to have choices in what flavor of blog, store, forum, etc. Also, the community is huge now which means lots of support and pro developers. However, despite that, I feel that the fragmented and old coding style of the software which makes for a steep learning curve to develop for it and the enormous admin panel which I wouldn't wish upon any client of mine makes it one to leave where it belongs with the coding dinosaurs. I feel like it's better for the Drupal devoted to develop their own sites with it and find a different solution for their clients.
Joomla is the other of the Big 2 CMS's out there. It's a lot like Drupal except that it's not the fault of its developers that its code is old and dated like Drupal. Joomla branched from the Mambo CMS back in 2005 due to some differences in opinion of the company that produced Mambo and the developer community that had formed around it. Mambo had been around since 2000 and Joomla branched off to begin its own evolution. Joomla felt a little nicer and simpler than Drupal. However, despite its large developer community, many developers have also "moved on to better CMS's." Drupal and Joomla are the CMS's that a lot of new CMS's try to NOT be like and fix the problems that each one has.
The admin interface is still more complex than it needs to be, mired down with large sections of customizable settings and multi-step page creation processes. However, it is definitely a step up from Drupal's. One thing I think people don't realize is that, even though Joomla hasn't versioned up much in its 5 years of life, its maintainers have been taking on the enormous task of rewriting its codebase to OOP and MVC patterns. Version 1.0 was largely a rebranded snapshot of Mambo with some tweaks, but version 1.5 introduced the new OOP and MVC codebase they were working toward. 1.5 served as a transition point with the core developers giving the community until 1.6 to port over their modules to the new codebase at which point 1.6 would drop support for the old modules. I had a job for about a year back in 2007-2008 during the time Joomla had released its 1.5 beta releases and my company was a Joomla shop so I was in the Joomla loop.
Like Drupal, it has an enormous developer community for support and a wealth of modules to choose from to add functionalty. I think it's definitely one to keep an eye on. Maybe once it gets to 2.0 and they have the new direction of the codebase firmly established, it may become better to develop with. Only time will tell.
Wordpress has come up a lot in the world of CMS's. Starting off as a solid blogging platform, version 3.0 offers more CMS-like functionality. I launced one small website with Wordpress 2.3 since I felt it was much better than Drupal or Joomla at the time. I'm am amazed at the kinds of functionality built for Wordpress when it was really a blog platform, especially the store module(s). Not bad for a codebase built to work as a blog. I'd bet there was a huge amount of custom coding for that module.
Anyway, as I mentioned above, Wordpress's codebase is (or was last time I used it) very blog-centric. It's also written (or was, maybe) in a mostly procedural fashion with very little OOP methods used. One thing I find interesting about it, and I give kudos to its core developers for this, is that most of its functions that get used in the templates, are made to look like tags that belong in the HTML. Many systems use a custom templating engine to make life easier for frontend coders who only really know HTML and CSS to not have to learn PHP or whatever language powers the system. Using a templating engine also adds some processing overhead to each time a page loads. Wordpress tailored their functions for the templates to look as much like a simple templating engine while still being raw PHP. Seeing <?php the_header() ?> and <?php the_footer() ?> in the template is about as simple as you can get.
Since I've only built one site with Wordpress and it was a small, blog-centric one, I didn't get my hands too dirty with custom development. I don't think I wrote much custom PHP, mainly relying on the exsiting API so I can't speak much for developing for it. I do know that there are also a lot of faithful developers for it. I could see myself coming back to it one day if my current CMS of choice died or fell apart.
My current job has me using the ExpressionEngine CMS. By far, it's the CMS I have the second-most experience with. Among the CMS's I've used, EE is the only one that requires purchase. All the others are open source. I've been working with it for about 7 months now and I just can't get into it. Don't get me wrong, EE has a lot of good things going for it. It has a very dedicated developer community of people who appreciate quality and who I've had the good fortune of meeting some of. There's a large collection of add-ons that do things from improving the backend UI to strapping on whole forums and e-commerce systems. There's also a very active forum that is an extremely valuable resource for answering questions that come up. Both the veteran developers in the community and the members of EllisLab (the development company behind EE) will answer questions there. The admin panel (or Control Panel, or CP if you're hip to the jive), looks nice and is pretty well organized. You can even edit what shows up in the CP for different users, providing the ability to lock the site maintainers out of areas they shouldn't be poking around in. It has a pretty flexible templating engine that allows you to access the content in the templates and have access to some simple control structures without writing a single line of PHP. You can easily get away with building a small to medium site without writing a lick of PHP which is pretty impressive in my book. It uses OOP coding methods which make the code cleaner and more portable.
Despite all this, the thing that gets me the most can be summed up like this: EE is a designer's CMS. If you can write HTML and CSS, you can use EE. If you're a programmer, EE may drive you nuts as it has with me. If you start nesting too deep with the templating code, things stop working consistently. It has a very strange sense of scope and context that makes the templating engine work harder than it needs to. For example, I recently found out that if you put a simple if/else structure in your template, if will render both blocks and then parse the if/else to choose which one to go with. Conversely in a programming language, it tests each "if" statement and will skip down the list until it finds a condition to run and THEN it processes that block and ignores the rest. Imagine having an if/else block with some "else if's" in there and each block required some intensive processing to render. Can we say performance hit. However, I found this out by being introduced to an add-on that fixes this behavior. Also, if I get too deep nesting in the template, things stop working as expected. If you give me control structures and loops like in a programming language, I expect them to work consistently, no matter how deep the nesting goes. It's the programmer in me.
Another pro for EE is that you can define your own data structures through the CP. If I want a staff detail page, I can make a page type that has a name field (usually the page title), a photo upload field, a generic WYSIWYG field for bio, description or whatever, and any number of other fields you want for custom content. I've come to realize this is huge, especially because it's baked into the core functionality.
Writing PHP for EE isn't bad, either. I have written some small add-ons that mainly just add new template tags to the CMS. That IS another thing I dig about EE. It's very easy to extend the templating language. God forbid you have to get into the database though. The database is a bizarre land of abstracted data structures. The core table that stores all the content is huge and inefficient. Every new custom field you add through the UI gets added as a column onto this table. So if you've created 50 different custom fields for use across mutliple page types, it's all stored in the same table and the able will have 50+ columns and many of them will be empty on each row. If you want to pull data from DB in the PHP, you need to map the columns to their fields, and... it's just a huge mess.
One last note I will say about EE before concluding on it. EE version 2 has been rebuilt from the ground up on EllisLab's renowned PHP framework CodeIgniter. CodeIgniter is a simple, elegant, and excellent framework and has been recognized and used by some major companies out there. I've also done a little development with it while I was looking for a new CMS to use and it's pretty nice. Developing for EE2 is allegedly much easier now that it is built on CodeIgniter.
There's a lot more good and bad I could say about EE but I'll sum it all up in a couple sentences. EE is a designer's CMS. I've seen someone else say the same thing. If you're a designer and don't have a developer to build the custom CMS functionality, EE is the CMS for you. If you're a developer, EE can be restricting, confining and frustrating but not impossible. For me, it's hard to like a piece of software when you have already found one that works well for you.
Last we come to SilverStripe, my current CMS of choice and one that I don't see getting de-throned from that status anytime soon. There are so many reasons why SS has won out for me. Using SilverStripe has shown me what doesn't work in all the other CMS's I've used. Much of what I've pointed out about the others, and more, is largely in comparison to how SS does things. To me, SilverStripe just does so many things right. It recently won the New Zealand Open Source Awards for 2010 for Best Open Source Project. Before I get into details, I'll give a little backstory.
SilverStripe is pretty young in the open source CMS world and, where I am on the west coast of the USA, SilverStripe developers for it are pretty sparse. Between myself and a colleague of mine in San Francisco who introduced me to SilverStripe in his quest for a better CMS, we're the only choices in the San Francisco Bay Area. The further east you go between where I am and SilverStripe's source company of the same name in New Zealand, SilverStripe adoption increases. While SilverStripe may be relatively young (it's version 2 got open sourced back around 2005-2006), it uses PHP5 and leverages some very advanced features of PHP5 to make developing for it very easy, intelligent, and flexible.
So, what are the things SilverStripe does right that I compare back to other CMS's?
- An installation of SilverStripe is extremely portable between different server environments. As long as a server supports the base requirements, I can move the all the files into another webroot, enter the DB credentials (or even make the system detect what server its on and have the correct DB credentials load), run the build script through the web browser, and we're good to go. Server paths and domain names don't get stored in the database like with most other systems.
- None of its configurations or settings are stored in the database. Where most CMS's make the settings available in the admin UI, SilverStripe relegates that to the code level, citing that the end maintainer doesn't ever need access to those settings.
- The admin panel is for managing content ONLY. With a base installation, I get the ability to manage the site's pages, uploaded files, comments (which is getting abstracted out in a future release), and user accounts.
- The amount of SQL I need to write is almost none. At most, it's little snippets of a full SQL statement but I rarely have to write a full SQL statement in the code.
- Creating a new page is as simple as choosing where you want to create the new page, filling in the content, and publishing it, all in one place.
- Managing pages in your site is really easy and you can see the structure of the site at a glance.
- It has a very simple templating language that provides simple conditional and looping structures, template variable to output content, and a few other minor things. These template files are converted to PHP and cached and it's these cached versions that get used when a request comes in. Since the templates are parsed as PHP in the end, you can next as deep as you want and you get no performance drop since it's PHP that gets parsed in the end and you get consistent behavior.
- It uses SEF URL's out of the box, period.
- It uses OOP, MVC, ORM, Decorator Pattern, Singleton Pattern to name a few methods and they all play really nicely.
- It's bundled with a RESTful API for easy web service and AJAX development.
- It's a CMS built on top of a generic development framework called Sapphire, also produced by the SilverStripe company. This is huge and makes the CMS more easily extendable since the CMS itself is merely a module built on top of the framework. ExpressionEngine got the same right idea with its version 2.0 release.
- Creating a custom page type with custom data needs is as simple as extending 2 classes and creating a template file.
- The database is very intelligently laid out. It resembles a collection of PHP classes and subclasses. When you create a subclass of the ORM class, it creates a new table with columns matching the fields you define in the ORM subclass. If I subclass that subclass and add some new fields to the new subclass, a new table is created with only those new columns and the system joins the entries on the two tables as needed.
- It comes with built-in image manipulation class for easy cached resizing of images and a robust form building collection for easy form building and tying into the database.
- And more......
Despite all these things it does right, it does have its weak points, but they are few:
- Managing the page entries is not scalable. The SiteTree that allows you to view the pages on your site resembles a folder/file structure on a computer and lazy loads the subpages as you open the "folders" which is great for static pages. When you get into blogs, forums, and anything that has new content added to it often, managing it can without a special interface (which is relatively simple to build) bogs down in the long run.
- The selection of available modules is pretty slim but many have great promise and are quite good despite their early stages.
- The Sapphire framework is big. Not Zend big, but I've been working on SilverStripe for a couple years now and I still find new things I didn't know about.
- The documentation on the framework and CMS is not great. CodeIgniter and Wordpress both have excellent documentation. SilverStripe's needs some work. There's a lot of classes in the framework and some of them are pretty vague in their function.
I hope this helps you find the right CMS for you, even if it's not among the ones I talked about here. I will continue to bask in the glory of SilverStripe until... ummm... ya.