Week 52’s primary focus was Housedon: a rebuild of a content-driven site for an arts charity.

The work came in two parts: building up Dean‘s designs in modular, flat HTML, and then building out the WordPress code to back the whole thing.

The flat HTML went fairly smoothly, but the site build is taking long than planned. This is partly down to the amount of content migration necessary.

Content migration is a necessary part of any web rebuild: site architectures change, page requirements change, and sometimes copy needs updating to reflect that as well.

In this case, though it was suggested I could leave that until later, it was clear that wasn’t the case; most of the old site was not stored in a database, but as flat PHP files with inline functions; importing the old content required placing these elements into WordPress, stripping out inline function calls and either replacing them with template elements or shorttags; and so forth. Then, the old content from the small WordPress install that powered part of the site was moved over.

As the week went on, we kept finding new pages buried in the old site, that would need migrating over – and working out how best to do that.

The end result is turning out well, though: every content object is now being stored in the CMS, a few necessary pieces of code have been ported over, and Dean’s focus on mobile-first mean the site works well at all screen-sizes. We’ve used SoundManager 2 to make the site’s audio much less of a bother to play, as well.

WordPress may not seem like an obvious choice for such work in 2013; why not something custom-built, or a flat site generated in something like Jekyll?

The answer to the former is easy: because the budget, both time- and financial- wouldn’t stretch to it – not to mention the impositions on hosting an application server makes. The latter is a more reasonable suggestion – but whilst the output format is swift and robust, the editing process for a static-site generator makes far more demands on editorial staff. In this case, a web-UI for a CMS they likely know makes sense.

But there’s still scope to tailor it to our needs. I’m a strong advocate of modelling information appropriately, so as well as Posts and Pages, we have four other Top Level Objects – Events, Texts, and so forth. These can all be templated separately, given appropriated metadata through custom fields in their own areas of the admin site, and as such, the data-model feels much more robust and future-proof (in the way a system built around WordPress’ categories taxonomy wouldn’t be).

At the end of the week, I was a little behind where I wanted to be, but the work we had done was solid and secure. A few more days next week should wrap things up. It’s been good to keep my hand in in a few particular spaces I hadn’t worked in so much over the past few months – practical front-end development, in particular.

I also had a lunch this week to discuss the previous week’s work on Hegdon which went well: a tricky project, that often felt like it was slipping through my hands at times, but a good discussion around the work that I hope revealed a few things to the client.