Code all the way

At Network Publications, we work with Drupal all day every day. We build dozens of sites a year and almost every single one of them runs on Drupal. We live and breathe Drupal. For us, it's the tool of choice when it comes to building a CMS-backed site. But should I build a site for my own company, I'd go a very different, a lot more lo-tech path.

When I say lo-tech, I don't mean one of those Dreamweaver-built pre-compiled horror shows that were all the rage in the 90s. No, I mean a site that lives entirely in the codebase.

Building sites on Drupal - or on almost any other CMS for that matter - means using a rather complicated development workflow. Synchronizing a local development environment with a live production site means synchronizing three different things using three different methods:

• Source code, documentation and parts of configuration are synchronized using version control.
• Content files (like content images or attachments) are synchronized using traditional file transfer methods.
• Content, site structure and the rest of the configuration are synchronized by creating a database dump on the live server, downloading it and importing it to the development database.

That means a lot of hoops to jump through when you need to do this stuff several times a day. If the whole site was just a big pile of source code, you could synchronize everything by issuing a simple git pull command. No more clunky file transfers, no more moving massive database dumps around.

Storing everything as code in version control would also mean:

• Revisions for everything. The entire history of the site would be visible in the commit log of the code repository.
• Total, site-wide branching. You could build a vast array of different versions of the site and switch back and forth between them with ease. Want to try a different content strategy? Knock yourself out! Need to prepare for a merger that has about a 50% chance of happening? Get a new branch ready, merge it to master if the merger happens and push it live.

Of course, there are drawbacks to this approach. Not differentiating between source code and content would mean everyone allowed to make content updates would also be allowed to make updates to the source code. Also, content authoring experience could be less than optimal. Sensible content format selection could take some of the pain out of authoring - I'd suppose using Markdown and SVG would provide the best authoring experience.

Oh, and then there's the problem with performance. Disk I/O in a virtualized environment is slooooooooow and storing content as text files could possibly make the site crawl. However, I'm pretty sure this could be overcome by using a smart caching strategy. As I have quite a bit of experience with Drupal, I'm no stranger to piling up multiple cache layers on top of each other. :)

So, to wrap things up: having a site that consists only of code has some very nifty benefits and some huge drawbacks. However, a site that has a moderate amount of content and requires frequent development and/or redesign efforts, this approach could prove to be a viable one. There are some rather nice open source projects that aim to facilitate this approach (e.g. Pico) and I expect to see a lot more of them in the future.

Keep it simple, keep it in code!