In search of a good CMS

I just spent a few days trying to get an overview of all the different CMS out there nowadays.
I restricted my search to free OpenSource PHP CMS. Those are still hundreds, but at least that rules out some like ExpressionEngine, CushyCMS (not free) and PlonedotCMSAlfrescoUmbracoRadiant (not PHP) and DokuWikiWordPressSerendipity (not a CMS). (I was surprised that, according to several sources, WordPress is the most popular CMS by far! Although I can see how you can include it in your definition of a CMS, I only wanted to concentrate on those which were meant to be used as one.)

  1. I had a look at about 100 different CMS at (Their demo for each CMS listed there is a pretty cool feature that let’s you at least see one of the most important parts of a CMS at once: the admin interface.) Then I did a bit of research, i.e. googling what others use and like and don’t like and tried a few others which were not listed at
    A few really popular CMS failed already at that stage: Joomla!TYPO3CMS Made SimpleXOOPSe107 and SilverStripe. (I.e. their admin interface failed to convince me, I haven’t had a look beyond that at that point).
  2. In the end I ended up with 18 different CMS I installed and tested more thoroughly.
  3. I will go into detail about 7 of them below…

But first…

What makes a good CMS?

In my opinion there are 4 points you have to consider:

Usability of the admin interface
Unfortunately that doesn’t seem to be very important to most developers. But I think it’s so important, I wouldn’t recommend using any CMS with an amazing backend, if its admin interface is crap.
It should be easy to create all the plugins and templates you need without hacking the core.
The community should be alive, at least a few contributors to core, plugins and templates existing, the project’s history should be healthy and the code secure.
It should use resources in a responsible way, scale on large projects and caching is vital.

How much can you trust my verdict on those 4 points? Well, I’m more of a front-end than a back-end developer and I haven’t used any of the listed CMS in real-life projects except one. It might well be that I will change my mind about a few aspects after having properly worked with them. But I have used a fair amount of other CMS and can compare most features.
So, I’d say at this stage I can judge the usability of the admin interface 100%, extensibility 50%, sustainability 50%, performance 0%.

I wouldn’t necessarily consider the quantity of features or extensions as important. As I didn’t have a certain use case in mind, I was looking for CMS in general. Obviously there is no “best” CMS, as each individual choice always depends on so many things you need to consider. But at least it’s easy to make a first rough decision on the category you need: For smaller projects you don’t need a full blown CMS and it’s more harmful to choose e.g. Drupal for a 12-page brochure website. In those cases you just need a lite CMS.

The problem with WYSIWYG editors

One important point in the admin interface is how editors can edit the content. There are two ways it can go wrong:

  • don’t provide just a WYSIWYG editor
  • don’t provide just an HTML or simple text editor

Unfortunately those two extremes can be found quite a lot in many CMS. The problem is: If you let your editors edit the content with a WYSIWYG editor, it nearly always destroys the integrity, validity and accessibility of the code and the design of the website. On the other hand, just using HTML is obviously no use to non-technical people and just a simple text editor doesn’t leave you with enough power and flexibility over the text.

The middle and in my opinion best way is using a text markup editor for e.g. Textile or Markdown. Although most clients will be reluctant to try it, make them use it for at least a week, and you’ll see that it’s easier for them than you think. If the editor includes a toolbar, the better. In case your clients are really extremely untechnical, a WYSIWYG editor is fine, as long as it excludes harmful markup, i.e. strip down its functionality (like WordPress does) or use a WYSIWYM editor (like WYMeditor).

You have to balance usability with doing the right thing. It’s important that developers understand that usability is vital for clients and clients understand what harm can be done by choosing to use a full-blown WYSIWYG editor.
In my opinion, a rich CMS which doesn’t provide the right tool here (as a plugin if need be), is an unprofessional choice.

The Verdict

The CMS in the lite category which didn’t make it into the final round: pluck, Symphony, WebsiteBaker and WonderCMS. The latter nearly made it, because I think it’s a brilliant idea to write such a simple and small CMS (11 KB download), but it’s not very client-friendly.

The CMS in the rich category which couldn’t make it: Kryn.cms (which has an interesting admin interface: it looks like a desktop with several windows), MODX, Textpattern (I so wanted to love it, but just can’t) and Zikula.

And finally, here are the remaining seven winners:

Category: Lite


  • Website
  • Demo
  • Download size: 0.5—1 MB
  • Number of extensions: 10—100

It was nearly a draw between Template CMS (which is the simplest and the smallest of these 4), Elefant (which has the most promising back-end and is the only one of these 4 which needs a database), gp|Easy (which has the most functionalities of these 4 and an inline editor) and GetSimple. They are all very similar in functionality, but if I had to decide between them, I would choose GetSimple, mainly for its clean and most intuitive admin interface.

GetSimple stores its data in XML files, so doesn’t need a database (which can be important in simple setups). It features a simple, stripped-down WYSIWYG editor. Most things I missed in the core can be extended by plugins (e.g. cache and custom fields) and it seems to be more stable than its contenders.


  • Website
  • Download size: 0—0.5 MB
  • Number of extensions: 1—10

Stacey is different. You might argue it’s not even a CMS, because it hasn’t got an admin interface at all. Instead it uses text files and other assets (images, pdfs, etc) in a certain folder structure to build the website and uses Markdown to parse those text files.
Stacey’s own templating language is very easy and simple, it’s build with nice and clean OOP and a proper cache is already built-in. The main negative points are the missing interface and that you cannot swap themes easily.

But I found a simple solution to the missing interface problem: Combine Stacey with OneFileCMS!
Despite its name, OneFileCMS is not a CMS. It’s an online file manager with a simple text editor, which consists of one single PHP file. Just copy that file into Stacey’s “./content/” folder and rename it to “index.php”. Then you can go to your Stacey-build website’s URL and append “content” (e.g. “”) and behold, you can login and edit your Stacey files through a simple interface.
Although this solution makes it much easier, it’s admittedly still not very suitable for non-technical people.

Category: Rich


  • Website
  • Demo
  • Download size: 5—10 MB
  • Number of extensions: 100—1000

Concrete5 has a really good and most intuitive admin interface. The editing is done nearly inline. (Well, you can see the original page, its areas and some controls while you’re editing it, but the editing itself happens in a modal window.) Its concept of different block types you can add to any area (not just e.g. WYSIWYG content, but also navigations, videos, page lists, etc) makes it very flexible. This block concept is similar to REDAXO’s concept of modules, but in concrete5 it’s done in a much nicer way. But unfortunately all of those fancy editing options come with a price: The essential parts of the admin won’t work without JavaScript.

One thing which some people might consider an issue: Some of concrete5’s add-ons cost money. Personally, I am fine with that. The only issue which could arise from it is that it will be impossible to support unmaintained add-ons.

Its OOP back-end follows MVC principles only half-heartedly, but seems quite powerful. As this CMS is getting more popular every day, it should be on everyone’s “must try out” list.


  • Website
  • Demo
  • Download size: 1—3 MB
  • Number of extensions: 1000—10000

It’s daunting to write anything about Drupal. Because so many people hate it and so many people love it, and my knowledge about it only just scratched its surface.

From trying to find out why so many developers don’t like Drupal, I gathered it’s mainly because it’s so popular and therefore it’s often used in cases where it shouldn’t be used. (The same goes for WordPress, by the way.)

But from what I saw it’s up there among the top of the most popular CMS for a reason. I wouldn’t consider it to be the best out there, there are too many things I don’t like: The way you can switch between editing and viewing a page is against all common usability sense (the tabs involved don’t function as tabs), forms in the admin are confusing (they all look the same, no matter if they are for real content or just for meta content) and the back-end looks “historically grown”. But the concept of the different components working together looks right to me. And whenever I look up how something works, it becomes clearer to me how powerful it really is.


  • Website
  • Demo
  • Download size: 5—10 MB
  • Number of extensions: 10—100

ProcessWire looks really exciting. The concept is good, the OOP back-end well thought-through and its API takes a refreshingly different approach as it is inspired by jQuery‘s syntax.

Its templating and editing concept is similar to Drupal’s: Templates are populated with the help of fields. And the values of those fields are used in the templates. (It also utilizes a lot of small modules.)
What I don’t like about this is that it means each template is fixed and less flexible (the same goes for Drupal). And unfortunately it hasn’t got any concept of themes yet. (While that is true, I learned that it’s intentional and an important part of its concept not to have themes.)

It’s promising, but it somehow seems to me it’s not quite done yet (e.g. you cannot edit anything without JavaScript) and things might still change. I will definitely keep an eye it.


  • Website
  • Download size: 1—3 MB
  • Number of extensions: 100—1000

REDAXO was my favourite CMS for a long time. Its module concept and editing flexibility is something I haven’t come across in any other CMS before. It might sound strange, but there are very few other CMS with which you can freely add any kind of content in any kind of order. But now concrete5 (see above) is a contender for that.

The only reason why I cannot really recommend this CMS is because its documentation (and website and even inline code comments) are mostly in German. :( This is its biggest flaw and I think the main reason why it’s quite unknown in the CMS world.

One piece of news which gives some hope: Last year a fork of REDAXO, named Sally, was born and it already looks really promising: It’s cleaner, faster and more open.
But unfortunately the makers of Sally haven’t learned from their sister’s mistake: Everything is still only in German. Apart from that, they made the unprofessional choice to require PHP Short Open Tags. But they are still in pre-alpha stage, so let’s hope and check back in a few months.

Wolf CMS

  • Website
  • Demo
  • Download size: 1—3 MB
  • Number of extensions: 10—100

Wolf CMS is my personal winner. It’s a fork of Frog CMS which again is a PHP port of Radiant CMS (written in Ruby).
Although it’s not as sophisticated as Drupal or concrete5 (and might even be seen as a lite CMS), it seems to be doing everything right. Its OOP MVC back-end is really clean and makes sense. The admin interface is extremely easy to use. Its core editor uses either Textile or Markdown (or PHP/HTML) with an editing toolbar.

Its main strength is simply its simplicity.

In my opinion there are only two things missing to make it perfect: The possibility to enter structured content (which also includes different types of content) and the possibility to store the layouts on the file system (which is also a flaw of REDAXO).
What could also improve: More people should be using it! :)

Update (30 October 2011): I updated ProcessWire’s info box to show Ohloh widgets like the rest. (As it was not on Ohloh, I just created that project there myself.)

Update (7 December 2011): I corrected some information for ProcessWire.

Tags: , , , ,

13 Responses to “In search of a good CMS”

  1. what about tiki cms groupware?
    Any Opinion?

    I use that one since the very beginning in 2002 ;-)

  2. diogo says:

    Hi! You should dig a bit more on Processwire. Take a look at the documentation and read some key posts on the forum. The templating system is actually very flexible, so flexible that you can pull any content from the system from any template. Ryan Cramer explains it very well here

    You have good reasons to be excited about it :)

  3. selfthinker says:

    I haven’t included Tiki in the beginning, because of its wiki heritage. I know that Tiki is much more than just a wiki nowadays. But it wouldn’t have survived the first round of my tests, because I find its admin interface not very intuitive.

    I guess there are two ways of seeing the flexibility of templates. The one you mean is from a developer’s perspective, and the one I mean is from the editor’s perspective.
    With ProcessWire, the developer can build whatever he/she wants into the template, but the editor has not a lot of control over anything.
    That is not necessarily a bad thing. On the contrary, it is often bad to let the editor have too much freedom. So, you have to find a good balance between those two extremes.
    But in my opinion (and based on what I know so far), ProcessWire is a bit too strict in that regard.

  4. diogo says:

    I hope you don’t mind that i link to the discussion about this post on ProcessWire forums. It explains my point much better than me.,368.0/topicseen.html/#msg5238

  5. Christoph says:


    SallyCMS works on fixing both problems you’ve mentioned. Code documentation is aimed to be 100% english and starting with Sally 0.6 it does not require short_open_tags anymore.


  6. Dave says:

    hi selfthinker,

    we are developing SallyCMS. Thank you for your thoughts. I have some comments on this:

    * pre-alpha-state
    Sally can be used in production for smaller websites. The reason why Sally is still in a 0.x-version is that the API is not stable yet. At the moment you should be able to update your system without too much worry from bugfix release to bugfix release (in the same minor branch). The API changes from minor to minor releases cause migration effort in most cases. We try to keep a detailed changelog with upgrade notes available, though. Another reason is the missing documentation for many features. At release 1.0 the core API should be stable and there will be a common way for migration tasks. However, we are using Sally in many productive projects and it’s doing quite well.

    * english documentation
    Our goal is to have a multilanguage-documentation of Sally. Currently we are working on German documentation for most features, because this is the fastest way for us to produce the documentation. When the community around Sally is getting larger or when we are near version 1.0, we will translate the documentation in English. Our code documentation is already mostly in English and will only be available inEnglish in future. The current state can be checked here:

    * short open tags
    We decided to follow the PHP 5.4 style here. So we removed all short open tags of the style <? and replaced them with <?php. Since in PHP 5.4 it is always possible to use <?=, we didn't replace this so we will still require short open tags for PHP < 5.4.

    With the development of Sally we focus on professionals. We differentiate between the integrator who is developing with the CMS and wants to use version management for his projects, and the administrator/editor who is using the CMS in the backend to manage content, users and change some settings. – Everything the integrator is working on should be files. Configuration, etc. should only be stored in files to make it easy to work in teams or for deployment purposes. We try to develop a powerful API to use Sally as a backend for typical websites as well as for RIAs in JS/HTML5, Flash or any other technology.

    Because Sally is a fork of REDAXO, it still contains legacy REDAXO code, which is licensed under GPL. Our code is completely under MIT license and our goal is do replace all GPL code to make the CMS more useful for special purpose applications and customers who are suspicious of the GPL. At the moment we think that the GPL code will completely be removed from Sally with release 0.8. At the moment we are at release 0.5.5 and 0.6 will probably be released around december.

    So if you want to give Sally a try, we'd really appreciate every feedback, bug-reports and patches. The source-code is available on bitbucket ( and our bugtracker is available at

    At the moment we don't spend much time in community building, because we still concentrate on our development to make Sally really great. But if a community of ambitious developers is starting to give us valuable feedback or if someone wants to support the Sally development, we'd be glad about this. :)

    Thanks and regards,

  7. selfthinker says:

    Thanks, that’s really great news! :)

    Although I saw the code documentation before, I hadn’t realised that most of it is in English because you have to click through some German-only landing pages to get to the real English content pages.

    I actually didn’t know about “<?=” being completely supported in PHP 5.4. Interesting! But as that PHP version is still very young (or rather not even properly released yet), I would never use that in an Open Source project as long as that version isn’t old enough to be installed on the majority of servers.

    That “everything the integrator is working on” will be in actual files is one of the things I was most excited about when I heard about Sally. That’s definitely a major improvement over Redaxo.

  8. SallyCMSFan says:

    Hi selfthinker,

    we are using SallyCMS in production and it´s great! Give it a try.

  9. Thanks for mentioning WonderCMS in your post, your opinion is very appreciated. Hope it’ll make it further into the finals in the next version.

    Great post and a good way of rating them.

  10. SallyCMSFan says:

    Hello selfthinker,

    have you already checked back SallyCMS? Maybe you can say something about your experience!?

  11. selfthinker says:

    @SallyCMSFan, I very much like where SallyCMS is going. But there is no point in looking at it any further as long as their documentation is still only in German. The fact is that I will never be able to use SallyCMS for any (non-private) projects because of that.

    It would be irresponsible to build something for a non-German client with other non-German developers (which make 100% of the projects I am involved with) with a German-only CMS. Even if I was developing something on my own and I could potentially use it (I speak German), I cannot expect the client to hire specifically only German developers if they need some changes.

    That’s quite sad, because I’d really like to use and recommend it but simply cannot.

  12. OLSA says:

    @selfthinker, and after 2 years this is still one of the best text in “finding better CMS” category!
    My concept is different “take one and customise it”, like I am done with Joomla (build custom media manager the best thing what I had done to get better administration and many other options, also in every project create custom components (not much but 2…3), modules (4..6), plugins for preformated inputs etc…, and few templates), and I know there is much better CMS, but also right now I can do anything in Joomla.

    Best regards!

  13. nobot says:

    I missed a test of “contao” (old name was “typolight”). I am not a webdesign professionel, but I think contao is worth to have a look on this great cms. Especially the great user and group management features were the point of decision for me. Also there is around Leo Feyer, founder of contao, a amazing developerscene for the last years. >

    An other “light” cms for beginners could be “mozilo” > Nice for an little website with very little requiremnts. The cms stores its data in files, no database is needed.

    Hope my tip will be interesting to someone.

    gx nobot

Leave a Reply