The benefits of decoupling your CMS

A common disease of software development is the "not-invented-here" syndrome, a tendency to write new implementations instead of leveraging existing solutions. We then just write it as part of the application we're currently building, thinking it's a small thing. Over time, such helper or utility classes grow as new things are added, but usually stay tightly coupled to the application.

This disease also applies to content management applications. By choosing a CMS, you need to accept not only the language it's written in, but also its editing and administration interface, templating system, databases it supports, and so on. The decoupled content management movement aims to improve this situation.

Focus on the added value

Leveraging existing solutions usually requires greater initial effort from developers, but in the long run the community is enriched by reusable components that focus on doing one task really well, rather than every application having its own mediocre implementation of the same thing.

Using third-party components also creates boundaries, which make it easier to swap them out for different or customized implementations. The Node.js ecosystem is pushing this to the extreme, with many packages consisting of only one or two files.

On a more coarse-grained scale, the same is happening in the PHP world. It is very promising to see major CMS systems focus on their CMS functionality and leveraging a framework to have a solid base. ezPublish 5 is built on the Symfony 2 full stack framework. Drupal 8 leverages many Symfony framework components. Typo3 went in the opposite direction, separating out its framework and releasing it separately.

Still, all of these systems are coupled to a set of specific databases and carry a lot of weight around for their storage.

Content repositories

Content-centric applications have high requirements on their storage backends. The idea of a content repository is to decouple the content storage logic from the actual application. The content repository provides a higher-level abstraction than a classical database. It can be improved separately from the application and provide advanced features like search, versioning, access control on document level, and so on.

Having a clear boundary between the application and the repository allows to swap one repository for another.

For Java, there is the Java Content Repository (JCR) specified in JSR-283. JCR defines an API (and not a protocol) for content repositories. The reference implementation is Apache Jackrabbit, used in the Adobe Experience Manager and by the Magnolia CMS.

JCR has been ported to PHP as PHPCR. The PHP implementation RFDa approach proposed by Henri Bergius annotates the front-end content with semantic information to allow a client-side editing system to identify which parts of the page are editable and how to store them back. With a Javascript library, this allows seamless, inline editing directly in the front-end in a truly WYSIWYG way.

The backchannel to store changes is asynchronous Javascript sending JSON-LD data. Bergius wrote Create.js to demonstrate this idea. Create leverages backbone for storing the data and uses the HTML5 content editable element to load a choice of WYSIWYG editors. Create also handles collections to add or reorder items and supports workflows and plugins.

A decoupled content management system only needs to annotate the content with RFDa and provide an endpoint for the JSON-LD requests.

An illustrating case: The Symfony CMF

The Symfony Content Management Framework is an initiative to provide content management for the Symfony framework in a radically decoupled way. It leverages PHPCR as content repository and Create.js for editing. Even the framework itself is split into small components, allowing a mix-and-match approach of using only what makes sense. It also makes the CMF a good base for building a custom content management system. With the basic building blocks provided, development can focus on the tasks needed for the specific use case.

This approach is an offer to solve the framework versus CMS dilemma. Instead of writing custom applications locked into a specific CMS application or having to reinvent basic CMS functionality, there are clear boundaries to replace those parts of the CMS that are different from standard cases with a custom implementation.

This article is part of the The Open CMS column coordinated by Robin Muilwijk. Share your stories about working with open source content management systems (CMS) and platforms like Drupal, Joomla, Plone, WordPress, and more.