In the universe of Content Management Systems (CMSs), content is the most important. In the Internet there are some standards that define formats to exchange content, like RSS and ATOM, enabling interoperability. What about interoperability and migration among different versions of the same CMS? Could functionality be de-coupled from content? What if a CMS would let its content standards evolve independently from their functionality implementation?
One thing I love from C-language is that it is an standard, where data types have almost not changed from the very beginning. Data types are not content, data stored in variables is. One can define custom data structures and functions that perform operations over the values. Defining “data types” for content might be an answer, allowing to develop better functionalities and optimized implementations in the future.
Content de-coupled from the CMS
Say for example, that a CMS v1.0 has a content standard v1.0. As the software evolves, as well as the underlaying architecture (i.e: LAMP), CMS v2.0 will be required, and content standard might need some improvements, so content standard v1.1 is released. Let’s iterate 10 times. At some point in the future, there will be CMS v9.0 and content standard v3.5. Latest software version should support content standard from v1.0 to v3.5, allowing to upgrade content painless.
Spreadsheets and Word Processors are an example of this. LibreOffice supports formats from ancient times (in computer science terms), doing its best to preserve formatting, content stays intact. It would be great to have a CMS that supports content standards from other CMSs.
So what do we need to cook our first standard?
- To define DB agnostic data types, a.k.a “fields”. A number is an easy example.
- Make fields optionally versionable.
- To allow to define new raw fields. Example: A file field.
- To allow to build new fields based off existing fields, in a nested structure. Example: A link field is a group of four text fields (src, title, alt, text).
- To define standard content structures (grouped fields with a common interface). A blog post is a good example.
Point #1 is key here. A field should have a defined structure, but the Database layer handles the physical implementation (MariaDB, SQLite, plain text, etc.).
The extra layer
One extra layer is needed for all this to work: the driver.
A driver should be implemented for each content standard version, that is the cost of durability. The use of classes is encouraged here, allowing future versions of the CMS to easily instance the drivers. Functionality should be flexible enough to support different versions of the same content, and to work across similar data structures. What makes data structures similar? Let’s use slideshows as an example, they require 3 things:
- A URL (optional)
- A text title (optional)
- An image
The slideshow functionality should empower site builders to pick the content structures that have at least one image field.
Fork the code often
Whenever the content standard changes, migration is required. Let’s put more effort on improving the code, making it more stable and perform better. Different implementations of the same functionality may arise, each with its own advantages, the content will stay durable. Forks of the code are encouraged for this to happen, everyone is free to collaborate through competition, market demand will do the rest.
Cross-posted to Devtome