Ever since I started developing websites I have come up against problems in working out how to efficiently host content. When a site is run by a single person and content is static it's very straight-forward - just hard code it! Beyond that, some kind of content-management system (CMS) is required.

Back in 2009, I was involved in a medical education project based at Newcastle University aiming to deliver content produced by medical students. A huge surge in enthusiasm lead us to move to creating content in Google Docs - fantastic for project managing, editing and easy for authors to use with minimal training. Our website was based on Wordpress, a CMS initially designed to host blog content which had branched out and was being widely used for other websites. Again, this has a user-friendly UI - but when you have specific content in a specific format this causes a lot of problems and giving non-tech-savvy authors the keys to your entire look-and-feel is always going to give you a headache! 

A natural progression for my next project was a custom CMS - more control over content and user experience as well as simplifying the database administration. This worked really well initially - back-end forms were mapped to a MySQL database and then data was pulled directly from the database with PHP into the web pages. Also a common solution for many web packages, but tension headaches quickly became migraines as the specifications changed! Want to put an extra field in there? That'll be updates to backend UI, database, frontend code. All of which create opportunities for bugs to slip in, aside from the inevitable headache with version controlling code and "diff"-ing databases. Time to move on....

Sometime around the 4th year of medical school I was introduced to the Symphony CMS. It was around version 2.2 (latest version is 2.6.3) back then. I was instantly impressed by how customisable everything was. Content types are defined in "sections" (think of database tables), queried by "datasources" (your SQL queries) and passed through to your frontend in the form of XML. Your front-end code is the standard HTML, CSS, JS but with XSLT sprinkled in to transform the XML data into useful front-end data. This creates a beautiful set of side-effects:

• Easy creation of data storage areas - your authors can get writing after a few administrator clicks, even before the whole concept is developed.
• Modification of data storage - adding a url field? or want to upload images to content? 2-3 minutes of admin time. No rebuilds of code!
• Complex data formats - file uploads, tagging posts, section links are all dealt with by custom input fields.
• Consistent UI - If you can use Google Docs you can use this!
• Separation of front-end and back-end. I can keep working whilst data is going in. If data changes, it will sit happily in the backend until I'm ready to modify my datasource or XSLT.

And on top of all this, if there's something you really want that Symphony can't give you - it can be extended! Symphony Extensions has hundreds of extensions built by the community, from search functions through to Facebook integrations. Of course, you can always code something yourself. Medisense is packed full with custom code to deliver what our authors and users want, and as a web developer I wouldn't have it any other way!

Sure you have to learn XSLT, but if you can code already this isn't much of a chore. Source control can be an issue (I'll be blogging about our solution soon!), but I honestly love the Symphony CMS as a perfect mix of backend, content storage and ease of delivery. I wouldn't even swap it for a cute little puppy.