A proposal for a perfect CMS
Leonardo’s Vitruvian Man, showing the ideal proportions for an adult male.
Every web developer, and this includes yours truly, has at some point in their career either deployed, customised or written a CMS.
And again, and again. And then probably a few times more.
Wikipedia lists over 230 CMSs. There are many, many more. It’s not just the general-purpose ones like WordPress or Drupal: there are also countless CMSs written for specific sites, some based on ‘rapid prototyping frameworks’ like Laravel, Django or Ruby on Rails.
And yesterday i was finding myself building a new CMS yet again. I’m rebuilding my projects page, and i needed some kind of data entry system. Obviously i could try to fiddle with custom fields in WordPress (the CMS the rest of the site uses), or i could simply use something like CSV as a ‘database’, but those solutions seemed to be either inadequate or clunky.
So here i was, building yet another CMS.
This doesn’t sound like fun. So that’s why i’ve been thinking about how it would be if we just had one CMS which would, obviously, be perfect. The perfect CMS, or PCMS, for short.
This is how it would work.
Separation of concerns
First of all: complete separation of concerns for data entry (the ‘admin’ part) and data output (the ‘site’ part). Both entry and output should be in a structured format, so reuse is easy.
Input
Data entry should consist of two parts: schema definitions for ‘content types’, and the entry process of the actual content.
Imagine a blog post or a news article: it has a few properties that are common everywhere (title, date, author) and properties that are really specific for a certain site (rating for a movie review site, list of ingredients for a recipe site, etcetera).
In PCMS the first step, before actually entering any content, would be to define these schemas. Most of the systems that i know choose one of two approaches. Either the schema is tied to the system, like in WordPress where the only option for non-standard data is to use ‘custom fields‘. The other option is defining it in application-specific code or a data model, like in Django or Ruby on Rails.
In PCMS, you would use something like JSON Schema on steroids. Instead of just defining basic types (integer, string, etc), you could also define more specific content types like ‘video’, ‘markdown text‘ or ‘image gallery’.
Aside from the content type, you could also define constraints: simple ones like a maximum length for a title, but also ones that are more advanced. Imagine an ingredient type that can be linked to a list of ingredients, maybe pulled from a source like Wikidata, so you can automatically calculate total calories and know if the recipe is gluten-free.
The PCMS schema definition is equivalent to how ‘document-orientated schemaless NoSQL‘ databases like CouchDB or MongoDB operate. It’s not like those databases are completely void of structure, it’s just that it’s very easy to change structure without having to rethink your whole database.
Another difference would be that the creation of schemas happens in the CMS. PCMS could use a simple JSON text editor, but given that this is a perfect system it should be easy for non-technical editors as well.
After defining schemas entering content will be significantly easier. PCMS knows what kind of data you want to enter, so the editor can be completely tailored for its purpose. No fields that you don’t need: if you’re editing a recipe the editor knows that an ingredient list is something different than a simple bullet list. The editor part might be close to how Sir Trevor JS works.
Because everything is JSON, queries would be easy. Imagine being able to run complex MongoDB or ElasticSearch-like queries on all content in your website. ‘Give me all recipes that have chocolate as an ingredient, contain a video, and are written by my favourite chef’ would be a piece of cake.
Output
To show the content in a browser you wouldn’t need to learn a new template language with all its weird commands and quirks. Instead, PCMS would offer you a read-only JSON REST API that just returns the content. It would be up to you to choose the technology stack for developing the actual site/app/whatever.
Imagine that you can simply curl http://www.example.com/recipe/4.json and get a JSON response back that shows you the content.
The advantages of such a system are obvious: if you’re building a native app, you would probably want to use the OS native controls for performance reasons. If you’re building a web site, you can just use any HTTP library and template system you like. Client-side only? Use React or Angular. Server-side? Use PHP with Twig templates.
Basics
Obviously PCMS also has all the basics you expect from a CMS: user logins with a role system (so your intern can’t delete all posts by accident), caching (so it’s speedy) and proper security (so your site can’t be hacked).
It would be tempting to provide PCMS with a default templating / theming system, but this might give people the false impression that it is the only system they can use. Instead of that, PCMS should just provide a JSON API, nothing more.
To make sure PCMS gets as widely used as possible it should be open sourced under a license like the GPL or MIT. I guess there would be enough interested companies to fund development and support.
Considering technology: PHP / MySQL would probably be a good choice because it’s so widely deployed and even people with basic server knowledge know how to deploy CMSs like WordPress. But i guess you can’t have everything, and maybe something like Node.js or Python would be more apt for this system.
Making it real
PCMS doesn’t exist, but many of the concepts mentioned in this article do. Drupal has something called the Content Construction Kit which brings ‘custom fields’ to a new level. The semantic web and linked open data would provide the linking between ‘ingredient’ and the list of ingredients. The separation of concerns backend/frontend with a JSON API is implemented in countless purpose-built applications. Google Spreadsheets combined with Tabletop.js is surprisingly adequate for implementing custom content types with a custom frontend.
But as far as i know, the combination of all those elements in a single, user-friendly system doesn’t exist. Drupal, even with the CCK, is still primarily used for old-fashioned websites. Semantic web and linked open data are fascinating concepts, but they don’t work in the real world. Purpose-built applications are, well, for a very specific purpose.
And i guess you can imagine the disadvantages of using Google Spreadsheets as a CMS.
Maybe the combination of a CMS that is both general enough for most content-centric sites, but also flexible enough for very specific use cases is impossible and automatically leads to scope creep and overengineering.
But maybe, just maybe, shouldn’t we give it a try?
Comments on this article were also posted on Hacker News.
Anonymous
I realize this is a year old, but I wonder if at the time of writing, there were as many headless cms solutions as there are now? Have you heard of them? Like cloudcms or contentful etc?
Michael
By the way, this does exist. It’s called Cloud CMS (https://www.cloudcms.com). Fully dynamic, JSON schema and packed with power. We have a cloud offering and also Docker for on premise and developer installs + a large and prospering customer base. The tech stack is just as you described – MongoDB, Elastic Search + change set versioning for branching, releases and true content publishing.
Ben Hoyt
Hear hear! For work I helped design a CMS somewhat similar to what you’ve described (JSON Schema based), but not quite as general: http://tech.oyster.com/when-building-your-own-cms-is-the-right-choice/ … and at my current company we built something similar: http://tech.jetsetter.com/2016/08/19/json-schema-cms/