Every CMS is terrible

In which I explain why everyone hates CMSes, for their own special reasons. I also do a quick overview of a number of alternative CMSes that you may not have heard of.

Note: This article was originally published on October 28 2015 on the SthlmConnection company blog. The CMS landscape has changed since then, but maybe not as much as you would hope.

The web is really rather strange. On the one hand, everything changes super fast all the time, and on the other hand we are still using the same basic principles as when the web was new. The same goes for the tools we’re using to build the web: JavaScript frameworks are born and die like mayflies, while CMS platforms live on for decades.

Both phenomenons can be equally frustrating. No-one wants to spend time on a tool that will be obsolete within a year, but at the same time, no-one wants to work with a tool that looked the same for 10 years. In this article, I’ll give the CMS concept some tough love, while asking myself why CMSes seem so dated. I’ll also tell you about our recent evaluation of different CMS solutions.

The dreaded CMS sickness

The CMS concept has been around since the 90s, and has seen many incarnations since then. It should really be a solved problem, but something about CMSes seems to always make things complicated. Many CMS based projects end up as something of a nightmare, where none of the involved are happy:

• Content people think the CMS is too complicated, limiting — or both.
• Designers think the CMS is too technical and rigid, and stands in the way of the desired look and feel.
• Developers think the CMS is both complex and stifling, and keeps them from working in an efficient manner.
• Project owners think the CMS is bad because it doesn’t provide exactly the features the project needs out of the box.
• Since the CMS really tries its very best in working to please everyone, it ends up very big and complex. So, the IT people who manage web servers etc. get frustrated with the resource hungry CMS.

And just like heavy metals that are emitted from factories flow into the ocean, get absorbed by fish and end up in our bodies, the consumers of the web are also exposed to this cumulative dissatisfaction through a product built upon compromises.

The core of the issue may be that CMSes too often try to be everything to everyone, and that clients too often want a single system to solve all of their web needs in one swoop, instead of using specialized tools for different parts.

But there is hope. After all, the end result is often quite decent, and when that happens it is entirely owing to teams who work well together and make wise decisions throughout the project. (It’s never because they used the Right CMS.)

After all, the end result is often quite decent, and when that happens it is entirely owing to teams who work well together and make wise decisions throughout the project.

No CMS

With time, many of us get something of a CMS fatigue. We long to sit down with an empty sheet and create a unique produce, perfectly adjusted to the audience’s needs — rather than just running the printing press one more time.

During the last couple of years, we have been striving more and more towards skipping the CMS entirely, and instead working with a framework that gives us more freedom (and with projects that fit this workflow). But there’s no use pretending that there’s never a need for a CMS, and when there is, there’s no use reinventing the concept.

It often feels like there should be a middle ground — a perfectly balanced tool that gives adequate support (CMS) and enough freedom (framework) at the same time. Maybe that’s utopian, and in real life it varies a great deal between projects what that perfect balance would be.

Headless

One might ask oneself if a CMS should be generating UI and functionality for end users at all — shouldn’t it be focussing 100 % on handling content, and let other tools worry about the rest? Such an arrangement is usually referred to as headless CMS.

Separating the CMS from the presentation of what’s facing the end user can have many advantages. Traditionally, a CMS is an all-in-one solution where editors, admins and end users are exposed to the same application. Splitting the project into one piece that focusses 100 % on content management and one that deals with presentation and fetches the content through an API, gives a naturas separation of concerns and can be a great compromise in many situations.

Services like Contentful and prismic.io offer pluggable solutions for this. And there is nothing preventing traditional CMSes like Drupal to act headlessly.

You can read more about the benefits of decoupled CMS solutions in the article CMS done right.

The perfect CMS

We have spent a lot of time researching what alternative CMSes are out there. Is there anything outside of the mainstream that resembles the perfect picture? (Even though there is no best CMS, there is no harm in looking for it!) We have searched for focussed, modern and efficient open source web tools that provide freedom where it is most needed, while assisting us in areas where we don’t feel that we need to be very creative.

We have searched for focussed, modern and efficient open source web tools that provide freedom where it is most needed, while assisting us in areas where we don’t feel that we need to be very creative.

A good CMS helps you create structured content. In other words, we don’t want a CMS where you create pages with arbitrary content in a non-structured way, but one where you define content types where content is kept and fetched from automatically to create pages based on well-defined templates. Furthermore, we want to be able to use a web API to access the content from other applications (the headless way).

So, what’s wrong with Drupal or WordPress for instance? Well, they are both old PHP projects with all that that entails. Both also show different symptoms of CMS sickness. We have a long experience with Drupal, but we often look for other solutions for these reasons. And we have been avoiding Wordpress since it isn’t a manageable development platform in our eyes. (We have written before about how to choose between Drupal, Wordpress, Ruby on Rails, Jekyll and others, but a lot has changed since then.)

We like working in Ruby, so we started there. Is there a good CMS built on Ruby on Rails, that gives you all of the benefits of the framework while at the same time letting you avoid developing you own CMS? We looked at LocomotiveCMS, BrowserCMS and Comfortable Mexican Sofa. (In our toolbox we also have the Ruby based Jekyll and Middleman, but those can’t really be considered CMSes.) We then turned to the new PHP world and found two interesting projects: Bolt and October.

There are probably benefits and drawbacks with all of these — and we have only done just cursory research — but in the end, we’ve chosen to go with Bolt, and have built a couple of fairly simple projects with it this year.

The following is a brief report of how we’ve evaluated these CMSes.

LocomotiveCMS (Ruby/Rails)

Locomotive is an odd bird in that it is split into two separate environments — one for web development and one for content management. The site development happens locally in Wagon — an environment where content types, templates, styling and site structure are managed. Wagon gives a preview of the end result, but without any dynamic data from the actual website. It feels a little bit like working in Jekyll or Middleman. The building blocks in Wagon are then synced over to Engine, which is the server environment built on Ruby on Rails. Here you’ll find the nice admin interface which is used by editors and others.

This concept seems elegant and efficient at first, but it becomes a bit awkward considering that pages and templates can be handled both in Wagon and in Engine’s admin interface. It seems easy to lose control of where the latest version is, and in which direction a template should be synced, etc. — especially when there is more than one developer involved.

Another thing that makes me hesitant is the fact that the development environment is completely separated from the dynamic server application. Server based features will of course have to be developed in a local copy of the Engine environment, which means that there are two code bases to deal with. There is nothing wrong with this separation per se, but Engine doesn’t seem to be meant to be integrated with other Rails components, but rather appears like a finished product which, on top of everything, only works in Rails 3.2 at the moment. It seems that the whole point of being Rails based is somewhat lost. But the project is trotting along, and version 3 is just about to get finished.

BrowserCMS (Ruby/Rails)

This was a promising project which unfortunately seems dead now. Compared to Locomotive, it is well integrated in Rails, as all building blocks are variants of ordinary Rails components. Unfortunately, we’ll have to leave it at that and move on.

Comfortable Mexican Sofa (Ruby/Rails)

This CMS, which cleverly spells “C-M-S”, or “Comfy” for short, makes no claims to be competing with any of the big CMS players. It’s more of an indie project — which is good in way. It is easy to imagine embedding it in a Rails application and letting do its own thing in parallell with the rest of the application. It is possible to use Comfy content from other parts of the application, or to reuse the Comfy admin interface for things outside of Comfy.

On the negative side, templates and pages live primarily in the database, which probably complicates the development and deployment process, in teams especially. Comfy is also centered around pages in a tree structure, and has no built in way of defining structured content. The most suitable use case is probably a separate content area in a larger Rails app that doesn’t mainly deal with content.

October (PHP/Laravel)

October is a very new project. At its core, it’s built around pages and layouts that are defined in code files that are editable through the modern admin interface. All dynamic content is generated by Components that you can insert into pages while passing on relevant data. It’s a quite nice way of separating layout and navigation from dynamic features.

Components are defined by plugins, which you can write yourself or download from October’s Marketplace. Plugins may also define content types for dynamic content like blog posts.

Working with pages in the system is quite technical, but powerful if you know how it’s done. This task will probably be handled by a developer of some kind, while editors will be responsible for managing dynamic content that is then automatically inserted on different pages.

There doesn’t seem to be a very comprehensive interface through which plugins can communicate with each other. Plugins define page components and admin views, and that seems to more or less it. There are no common structures for content types, categories, relations etc. that are shared between plugins, but each plugin seems to define its data separately from the rest. This makes it hard to see how a content-heavy site could be built with October, and this is the main reason for why we have chosen not to use it at the moment.

Bolt (PHP/Silex)

Like I said, we’ve come to like Bolt, and have built a couple of projects (yet unpublished) with it recently. It’s a versatile but focussed CMS with a clear framework for how content is structured and administered. It’s similar to Drupal in that the main building blocks are content types, fields and taxonomies. But while all Drupal configuration by default is made through an admin UI, Bolt uses YAML files for everything, which is very convenient and efficient. Why work with slow admin pages and a thousand mouse clicks when you can edit a simple text file instead? The configuration also becomes searchable, portable and easy to put in version control.

I have trouble seeing how it could be more difficult to learn Bolt’s YAML files than Drupal’s admin UI.

Some might miss Drupal’s ability to build sites without coding, but I have trouble seeing how it could be more difficult to learn Bolt’s YAML files than Drupal’s admin UI. Bolt doesn’t try to build websites without coding, and with this assumption the result is a platform that is much simpler to develop in and to maintain. On the other hand, Bolt’s admin UI is well optimized for its main purpose: managing content.

Building end user interfaces in Bolt is a joy compared to other CMSes. Here too, you’re spared from clicking around in an admin UI in order to get something that almost resembles the desired result. Instead, you build the markup exactly as you want it using Twig templates.

At the same time it’s important to realize that Bolt has its limitations, being a somewhat immature platform that focusses primarily on simpler use cases. A couple of things that we have been missing is support for multiple languages, fields with multiple values, and hierarchical categories. But at the same time, these are limitations that we’ve been able to work around, and in a way the limitations are what makes Bolt easy to work with.

There is no built-in support for community features or anything like that, but you can build your own PHP extensions where you have access to the Bolt, Silex and Symfony APIs. There are also contributed extensions from third pardy developers. Using external PHP packages in your own extensions is also trivial through Composer — in this sense Bolt is a real player in the modern PHP ecosystem. You can even embed Bolt in a parent Composer project if you like.

If I’d wish for one feature it would be a web API for reading from and writing to Bolts content from external applications. In other words, a standard solution for working headlessly. There is an extension that looks very promising, but it lacks support for saving content, and in my opinion, it would be a good idea to have a web API bundled with the system.

This fall, we’ve got a couple of our bug fixes and improvements added to Bolt, which we’re extra happy about. We’ve also contributed an extension for redirects.

Conclusion

To summarize, I think we can say that we have a new favorite CMS. So far, Bolt is quite spared from CMS sickness. But as always, it’s important to point out that no tool is suitable in all contexts, and we’ll continue to choose technical solutions completely based on the unique needs of each project.

Photos by Orin Zebest and drcliffordchoi

Originally published at www.sthlmconnection.com.