Stephen Beattie

The Content Management System I'm currently working on has some known and reasoned limitations. It was designed a couple of years back for immediate ease-of-use by clients with simple needs and so i more an Adobe Contribute replacement rather than a full blown enterprise-ready überapp. There are some dynamic/shared elements such as 'Common Content' (think footer/sidebar content) and Collections (think FAQs and lists of things that need to be managed separately but appear on multiple pages). The navigation also builds itself from the site structure. It works well and I get good feedback from the clients and developers using it.

However, there normally comes a point when the client wants to do something a bit different. Lets say that rather than maintaining a simple list of FAQs with Collections, they want to create a knowledge base of articles. Up to this point clients have had to re-purpose a set list of properties for each 'Collection Item'. The fields were: publish date, title, summary, thumbnail and link. Thanks to a bit of ingenuity on the part of our developers, these properties were sufficiently generic to be useful in a range of scenarios from making a randomly rotating banner to an events list to a simple photo gallery with albums. I was surprised how flexible something so statically defined could be. That said, the fields weren't all used all the time and since the labels were generic, sometimes it has hard for the client to relate which form fields affected the final output on the website. In short we needed something more scalable and user-friendly. We needed 'custom' Collections where the form fields could be configured for each type of content the client required. We needed a way to model content.

It so happened that the way in which I'd designed the database earlier abstracted the notion of a schema for Collection Items away in favour of storing name/value pairs to facilitate versioning. In fact the static properties discussed above (title, summary etc.) were only enforced as hard-coded items in PHP. Good so far but I needed a way of mapping some sort of structure to the data on its way into the database as well as on its way out.

XML was the answer. For each 'Collection' of content added to the site, a collection type is used to provide a 'content schema' for the data. The basic idea is to have a single XML file that carries just enough information to build a form, validate the user input (and filter it if necessary) and then store the data entered.

A sample collection type is shown below:

As you can see the XML schema is fairly simple. Each collection type gets a node with a unique identifier by way of the 'guid' attribute. This GUID gets stored in the database along with the name and description node values for each Collection and the GUID is used in an XPath query to retrieve the schema from this document at runtime.

The property nodes define the actual form fields that appear when the user adds/edits Collection Items. There are various property types which relate to the interface elements used when the form is rendered. Other attributes on each property node relate to how the data should be validated and filtered (such as have the entered text made uppercase or hyperlinks made clickable). Some more attributes specify default values that should be used, whether values should match another field, be unique etc.

The settings node in the XML document is used when the Collection records are viewed in the Content Management System. The attribute values are used to determine which properties are displayed in a datagrid and which can be searched.

And so, the XML simply defines a form to be rendered but also, the fact that we have a record of the structure of the stored content means that we can use this to publish content from the database into HTML (by means of templating), XML (by using the 'id' attribute of each property node as the tag names) and even to an SQLite database. Since SQLite supports only a few simple data types I was able to simply map the property types (taking into account their validation rules) and create an SQLite database for each Collection on the fly. This proved to be an ideal solution for reasons I've mentioned before.

So modeling simple content with XML is a very useful way to make your Content Management System flexible and because the content model is not stored recursively in your database, getting at the schema is simple and quick. If you're planning a CMS then I'd strongly recommend this approach

I've been reading Deane's posts on Gadgetopia a lot recently and one of them refers to the notions of ' Data Push' and 'Template Pull' in terms of how content gets to the page driven by a CMS. This was an interesting post for me as I've recently found that a combination of these models provided a solution to a problem I was having.

As part of my work for Golley Slater Digital I've been architecting a PHP5-based CMS that uses the 'Push' model where content authored on a private 'admin' server is published to a public 'live' server to be viewed by end-users. Essentially, the CMS stores content in MySQL, writing it out as a hierarchy of static HTML (well PHP really) pages when the user elects to publish. These static pages, along with the other assets are 'pushed' live using RSync which copies them from one server to the other.

In addition to regular page content, there are other types of content such as 'Collections' that are used in the CMS and that need to be copied to the live server. A Collection is a list of structured data types, Collection Items, that are managed independently from page content. Collection Items have their own approval workflow, go-live dates etc. and can be bound to pages through the admin UI. Typically, Collections are used for News, Events, FAQ's etc. but really any content type that can be modeled with a simple structure is a candidate.

Now up to last month I had stored published Collection Items in XML which was parsed at runtime on the live site (The XML would get conveniently pushed live with RSync along with the pages). With PHP 5's improved XML support this was a reasonably performant solution and provided a basic storage mechanism for the structured data. But what if I had thousands of items in a Collection and wanted to perform a complex search to display the results over a few pages? Hmmmm. It was achievable with XML but was going to get tricky with XPath expressions and server resources would definitely suffer when parsing the XML and sorting arrays of data. I needed another way.

Enter SQLite! This database engine is embedded into PHP5, and was the answer to my woes. SQLite databases require no setup, passwords and are nothing more than regular files so they play very nicely with the RSync deployment scheme I use. On top of that since the vast majority of SQL can be used to query SQLite databases, searching and paging of results was going to be a breeze. So I made a change to the CMS that saw published collection items going into a local database rather than the XML.

Using SQLite means that the CMS can effectively queue-up content ahead of a display date and expire content at some point in the future. What's even better is that the published sites are still standalone in nature and do not need any knowledge of the CMS which created them.

O.k. so using SQLite is nothing groundbreaking but the application of it in this context made me stop thinking of a database as something at the bottom of a technology stack and as an portable and intelligent file format that can be shared between applications. Revelation!

If you're planning a CMS then I recommend you look at SQLite for creating hybrid static/dynamic pages. It certainly opened some doors for me.

Disclaimer: Yes, I used the word 'performant' in this post.  Apparently it's not a word but I like it. So Sue me.