The Content Management System of my dreams (part 4) — Lets dream!

Previously on: Static Site Generators with a side of toml/yaml soup.

If you have read this whole series and reached this last episode of The Content Management System of my dreams, I thank you! If not, while they provide some background of the sorry state of current Content Managment Systems and Static Sites Generators, they are not a mandatory reading if you are just looking for the specifications of what would be the best CMS ever (at least in my dreams).

Now…

Lets dream!

TL;DR: The Content Management System of my dreams allows easy web content management for editors, easy theming for designers, and publishing the best performing websites using the least amount of human and hardware ressources as possible.

The ultimate CMS specifications

This CMS:

is open source and can be self-hosted (I'd prefer it free, freemium even for extra value added outside this list, commercial license is OK)
runs self-hosted on Linux
is architecturally separated from the web server, it makes no assumption regarding the web server and its concerns, it does not serve public-facing content unless asked to (like handling comments or searches). It does not take down the site with it for serving a file
produces files on a disk and an easy and fast way to publish those on the web. Whether those files are “static” or “dynamic” is not a concern of the CMS but of the web server
has a UI and UX tailored for non-technical users (content contributors, editors and non-specialized web designers)
offers a Rich Text and WYSIWYG editor that hides the underlying markup (both HTML and Mardown as a minimum), supports semantic and accessible content, and provides site-defined validation of metadata and content (e.g. allow/disallow use of certain HTML tags and attributes)
allows to manage everything from a web browser, including site design, templates, content types, taxonomies, metadata and validation rules, system configuration. File management on disk with a text editor is a nice to have, not a requirement
provides fine grained custom roles and permissions management for users processes (e.g. for content editing: contribution, moderation, publication etc.)
handles versionning of changes with rollback (using git is good provided it is completly transparent for the non technical end users)
provides a human readable journal of all actions (at a minimum of any change to any data)
provides search and replace capability for any textual file managed by it (this includes templates)
provides a search engine for the website or means to plug in any external search engine
allows customization or its interface, behavior and template features via configuration or plugins
provides architectural security by forbiding a template designer or an external plugin to bypass the content management layer
provides theming capability
has top notch internationalization support (supporting Russian is a good Litmus test) that handles source changes nicely and actually helps translators
is easy to upgrade without the risk of breaking things
has no mandatory dependancy to an external service (providing a plugins market is fine, as long as not using it does not restrict any feature)
forces no specific database engine (e.g. if it requires a database, I want to have the choice between Postgres and MySQL)
provides a complete API (at minimum a Data API to manage content)
provides backup and restore facilities for everything it stores (content, templates, configuration etc.)
has a fast and smart template architecture that knows where and when to regenerate files according to what content is changed. It does not force blind full rebuilds for a single change. It provides template caching and inclusions for easier templating and faster rebuilds

In story form:

What I want	CMS requirements	Story
Manage any kind of files the way I want	Make no assumptions on the types of files and directory structure	While the CMS allows me to manage files, it is not involved in serving those on the web. Whether I want the CMS to generate HTML, PDF, PHP, text etc. this is not its concern. However I want to organise those files on disk, basically my site structure, is my business.
Allow me to freely use any valid URL, with my own schemas and validations	Make no assumptions on the site structure and URLs. The CMS routes have no bearing on the website routes.	I want to be able to define the entirety of the site URLs without unnecessary constraints from the CMS. OK: check that URLs are unique Not OK: force me to use a specific way of generating a list, or serving multilanguages sites Viewed another way: if I move from another CMS, the new site can work with the same exact URLs (unless technically impossible because the previous CMS has specific URLs).
My site must work^(*) behind just a web server, even if the CMS is down or if I want a strict separation between both	Have no role in serving public content, unless specifically used for	The CMS can be totally separated from the website if required. It does not serve content unless I decide to use a dynamic call to it (like the result of a search). It does not impose any constraint on the public site web server (typically WordPress and CMS rules in .htaccess files are out). (*) Losing some CMS-provided capability (like search) is acceptable as long as I chose to use them.
I can manage any number of sites, independant or related, from the same dashboard	Related sites can be grouped hierarchically	Provide the means to nest related sites and a cascade for templates to simplify site design (e.g. if a template does not exist in the child site, defer to the parent template, or a system-wide one).
I can change the site layout, design, content types, custom fields etc. without needing a code developer	Everyday changes require zero development	All content and design concerns can be managed through the CMS. Editors and designers can use the web UI to do anything they need. A CMS developer should never be needed during the normal life of the website, except when it makes sense (e.g. developing a plugin).
I can manage any custom data and generate any kind of files with it	Provide custom content types, taxonomies, fields etc., and a template engine capable of generating anything from the data	Make no assumption whatsoever about the generated files. Provide a template engine that takes custom data and generate files according to a custom routing: indexes, individual files, lists of files with custom URLs and custom facets derived from custom data.

Wait, is this only a dream?

It is not only feasible, it has been available for decades.

Movable Type has been providing pretty much all these features since 2000. The only things it does not do in the laundry list above are: being open source, being usable by anyone, I18n support, no specific database engine (it forces use of MySQL). Those do not qualify as dreams.

If you are reading this as a CMS software editor and do not know Movable Type and its architecture, you are missing something big. Trust me. If your software lacks one key thing from what MT is capable of, especially its really well thought architecture, you are missing something.

So why not use Movable Type?

I still do for a few sites. I could still do when it is the perfect match. But the trouble with MT boils down to its editor, Six Apart, a Japanese company that does not help its alien community to expand its usage outside Japan (where it still enjoys the lyon share of the CMS local market). I used to do its French translation, but they stopped asking me to. The only reasonnably up to date documentation is in Japanase and has not been updated in English for quite a while (one becomes tired of reading it through Google Translate). One simply cannot use it without existing knowledge of MT or of Japanese. Six Apart is thriving in Japan, where it enjoys a whooping 88% market share, and is pretty much non existent anywhere else.
It is their business decision, and our loss.

Additional thoughts and advice for CMS developers

Please stop plaguing the world with yet another SSG or “Your CMS in the cloud” horror. Companies are already fighting against bad web agencies that capture their sites to hold them captive. Thinking that you can grab their entire site, content included, as a way to make money migth be a business plan, I call it a Bad Business Folly (both for clients and yourself, this is not a sustainable business).

A requirement could be that the files are managed, under the hood, in a git repository. This would take care of several features: auditable versioning, logs, staging and publishing via a CI, and a lot of other things (not the least this being a possible mandatory requirement for a company). What you absolutely have to do, is provide a user-friendly web UI and experience that isolates the CMS users from git jargon. They want to see “save” not “commit”, “publish” not “merge”, they don't want to hear about a “repository”. We all want to be able to use the best tools for our jobs, those being very different depending on roles. If you are developing a CMS, your real users are not other developers.

Providing a native application for content editors would be very nice to have. It might even be paid-for as a source of revenue for the product development.

Speed matters. In short, the CMS will be doing all the generation of content, server-side (generating content from the client side is a big no-no for me). Be very careful about the performance of rendering a complex site holding hundreds of thousands objects (this is a real world site, which MT takes many hours to process).

Comments

You can join the conversation either on Mastodon or on Twitter.