Do yourself a favor: enforce validation rules for your CMS content types.
One of our specializations here at Makai Digital is helping customers with their e-commerce solutions. One common architectural pattern they share is the use of a Content Management System (CMS) to enhance the master data of an inventory or reservation system with marketing content. Unfortunately, one common issue they also share is production outages because of weakly developed content types (depending on your CMS you may know it as document types, schema types, templates, etc).
The reason? A consuming app of such content expecting a field to always be populated, just to find out that is not the case. Imagine the home page of an e-commerce site that displays the active promotions configured in the CMS. Such functionality was developed by making an API call to the CMS to retrieve the promotions and displaying them in a carousel showing the image and name in uppercase. The developer following requirements performs a promotion.name.toUpperCase()
. This worked great in the test environment and even production for months, until one day it didn't: a content author published a promotion without entering a name.
Now, depending on the complexity of the home page and your observability story, this issue can take from minutes to hours to be resolved. Once we establish there have been no deployments or infrastructure changes, we move on to the theory that this could be a data related issue. If you are lucky your logs might give you a good hint as to where the problem is, but I've had my good share of:
- .NET's NullReferenceException
- Java's NullPointerException
- "Cannot read properties of undefined (reading 'toUpperCase')" in JavaScript.
where the stack trace was not very helpful in pinpointing the problem.
How to do deal with this problem
While the simple and correct solution is to add validation rules to fields, this is not always as straightforward as one could imagine. There is a wide range of CMSs out there and they implement validation differently. Putting aside the number of built-in validation rules and the ability to easily create custom ones, there is the topic of when the validation runs. Typically CMSs fall in one of two groups:
-
Will not allow you to create a content unless all validation rules are satisfied. While this seems fine on the surface, it is extremely inconvenient for content authors. They typically do not have all the information upfront, but rather compose the content little by little as they gather all the necessary information: images, product specifications, language translations, etc. I find this model extremely limiting for real life authoring experiences.
-
Others like Contentful and Strapi have a clear distinction between draft and published content. They allow us to save incomplete/invalid content, but will not allow publishing until all validation rules have been satisfied.
So what do you do if your CMS is in the first group? Well, the options are not great to be honest and they vary depending on the CMS capabilities and extensibility model.
-
Some CMSs have the concept of default values. Applying default values would prevent empty fields from being published. However, this presents other challenges if a certain field is supposed to be unique like a product SKU.
-
Some CMS may allow you to hook into the publishing pipeline. You could then run the validation rules and stop the publishing if it is not valid.
-
Finally, you could offload the responsibility to the consuming apps. While this is a cop-out answer, the reality is that some CMSs are just not well-equipped to deal with this problem. You could improve this solution by creating a middle layer between the CMS and consuming apps in charge of validating the published content and preventing passing along invalid content to consumers.
Conclusion
I've seen production going down enough times because of this issue that I strongly recommend taking action. Unfortunately, depending on your CMS this may be a complex problem to solve.