CMS’s Should Manage Content, Not Display It
A CMS that interferes too much with the display and rendering of content can drive you nuts.
I don’t like content management systems that try to handle the displaying of content. I alluded to this last year, when I wrote: There are two sides to publishing Web content: First you create the content, store it, edit it, send it through workflow, get it approved, then stage it somewhere until…
The author argues that content management systems (CMS) should focus on managing content, not displaying it. They argue that CMS that have a display component often end up trying to replicate Web programming languages, which often fails and can be difficult to use. The author suggests that CMS vendors should handle all content administration, then provide an API for developers to convert content into a data construct in their choice of language.
Generated by Azure AI on June 24, 2024I don’t like content management systems that try to handle the displaying of content. I alluded to this last year, when I wrote:
There are two sides to publishing Web content: First you create the content, store it, edit it, send it through workflow, get it approved, then stage it somewhere until it’s published. Second, you display the content on a Web page. The first is infinitely more complex than the second.
This still holds true. Managing the content is the tricky part, publishing it is easy. Any Web developer worth his or her paycheck can spin a recordset and write out some HTML.
Content management systems that have a display component end up trying to replicate one of the dozens of Web programming languages out there, and they do an inferior job of it. ASP, ColdFusion, PHP – these languages have a big programmer base. I don’t care how much thought you put into it, your proprietary CMS templating language is going to come up short.
I’m working with an open-source content management system now that’s first-rate. However, a big part of it is the display component. It has its own templating language, its own URL format, its own object theory, etc.
There are some problems with this.
- It’s very, very slow
- The language is inferior compared to even the most basic Web programming language
- I like my URLs a specific way and I need to maintain URL consistency
- I don’t want to learn yet another language.
My solution was to write a function library to make raw database calls to get everything out in a nice, big, nested PHP array. I essentially built an API for the CMS to make pulling content easy, but I do all the HTML processing in PHP, abandoning completely the display side of this CMS. I still use it for administration, workflow, etc. (which it excels at), but when PHP is such a fantastic, mature language, why reinvent the wheel?
Some people may claim that templating languages are made for non-programmers to use, but they often end up being just as complex as a real programming language. As the language develops, you find that you need to add this function and that control structure until, in the end, you’ve essentially re-written an existing language.
And if you just give the developers a decent API for getting the data out, most of the heavy-lifting is done. Code to format text, numbers, dates, do some simple if…thens, etc. – this isn’t hard and can be abstracted to easily-digestible function calls.
(Also, the sad fact is that sometimes the displaying of content is, in fact, complicated. Especially when you get into things like personalization. We may just have to live with the fact that the logic to display some content is beyond the scope of a non-programmer.)
CMS vendors: handle all the administration of the content, then just publish it to a database and give us a solid API for getting the content into a data construct in the language of our choice. We’ll handle it from there.