content

If you want someone to build you a website, don't let them build you a bespoke CMS to help you manage it. I've fallen prey to this very temptation, although in my defence it was as much an investigation into technology and the structure of my own content as a solution to the problem of managing said content. But after having spent two years struggling in vain---completely and utterly, to the point of not merely writing zero new code but also writing much less content---I've moved to Drupal. Since doing so I've been playing with blocked-out chunks of reusable code and content, and little related-content lists, and automatically generated RSS feeds, and a free-text search that just works. Beat that, my own programming skills!

This sort of slip-up, though---asking someone to build you a thing, be it website, web application, or offline electronic service, and letting them instead build you the tools to build it with---is tremendously common, and I can see why. You want to think that your particular site is the unique snowflake, that your way of working only fits a certain publishing workflow, or moderation structure. Of course you do: to suggest that your notions could be implemented using off-the-shelf tools is to suggest that they too are off the shelf.

But however innovative the idea, eighty percent of its implementation is, if not the same, then of the same form. How many newly-invented white goods couldn't be fitted with a standard wrench, and how many plumbers got customers to pay for them to invent a new, never-before-seen custom tool to fit them? It's not a flattering comparison, but so it is with new ideas for using the web. Every publishing system needs ways of filtering, searching, and unpublishing content; every website with dynamic content needs to address cross-site scripting, error catching and logging, and formatting raw content; and every successful site needs to consider cacheing, spooling, and load balancing or throttling.

And while web development companies can and do solve all of these problems (you didn't necessarily ask, but Torchbox does it quite nicely, thank you very much), they have to justify to you as a client why they're better placed to solve them than people whose core business is to solve them. The same goes for application frameworks: if the company's meant to be building you an application, but they're not recommending a framework like Ruby on Rails or Django, then you should ask why. And they should be able to tell you.

Maybe the system you're end up with won't quite let you moderate content the way you're used to, or the way you're expecting to. There may well be good reasons for that---and the framework or CMS has just stopped you making a very silly mistake---but if it was just a case of it being a reasonable tradeoff of functionality and developer time in the original framework, then that's the point where your web company of choice can start to extend and build on the framework. By that time, that eighty percent is already there, and secure, and the bespoke twenty percent that every site needs can sit on a solid, reliable base.

I can't tell you how happy I've been since moving from my homegrown system---much as I loved its slickness and elegance---to Drupal---much as you can always argue about the quality of other people's code, essentially just whining that it's not quite how you would have done it. Content, after all, is born free; yet it is everywhere in custom-built chains.

Remember in the days before blogs, when we used to have homepages? Well, technically I suppose I still have one, separate from my blog. How retro is that, eh? My online presence is so fragmented (arguably because my offline presence is that of a genre-flitting dilettante who can’t just sit still for five minutes) that the index of www.jpstacey.info is still not my actual blog, even in 2007.

Instead, it’s always been a portal through to existing content—blog, yes, but also short stories, book reviews, the Oxfringe lit-fest and other nonsense—and as such tended to gather dust. Worse than that, I’ve always wanted to put so much of the stuff from my halcyon studenthood there, and have therefore typically run aground creatively after writing two or three pages of copy on the bands I’ve been in and that time nearly eight damn years ago when we did a revue at the Edinburgh Fringe.

Now, though, I’ve redesigned it with a bit more scalability, and minimalism. The index is just a set of slightly Web-2.0ish buttons, all of which lead through to existing sites (although I do need to actually tidy up the navigation on “Other” at some point). That way I’m not condemning myself to writing up my entire past life to this point, of no interest to anyone other than me, my adoring public and the eventual hordes of biographers that will snap and grab in my vast intellectual wake. Or rather: I’m not condemning myself to months of avoiding the very task I mention above.

The tendency when building one’s own website—which a blog neatly avoids, for better or worse, and a CV would never even conscience—is to plan to put one’s whole trophy cabinet online, every bauble and curio. You leave spaces on the shelves for monuments to all the things you’ve done before registering a domain name, but then never remember to unpack them from the boxes in your mental attic. Well, no more.

Since listening to Garrett Coakley speak at the first Geek Night on the topic of Drupal, I’ve been sniffing round that open-source CMS. He kindly came to speak to us again, and very inspiring it was too. We’re now having a deeper look at it, seeing what it can do, what are its strengths and weaknesses; that sort of thing.

Drupal is certainly very interesting. Its notion of presentation is remarkable in that, at a certain level, all content consists of homogeneous nodes, whether that consists of uploaded files, images, blog posts, taxonomy categories, or embedded YouTube videos. In addition its API for templating, both as a library of functions and as a workflow that one can hook into, probably rivals WordPress in its scope and power. At the same time, though, the implicit homogeneity makes it hard to structure fundamentally heterogeneous sites; and the API hooks are very difficult to unravel: frequently you’ll want to get at a function some ten levels deep, and probably three of those levels can be overridden by your own code, but which, and how?

I want to mention more at a later date, to do Drupal justice, but suffice it to say for now that the complex hierarchy of the hook-in workflow is almost entirely opaque in PHP, a language that provides rather terse error reporting, without the function debug_print_backtrace(). Well worth a look if you’re debugging spaghetti-code, especially when all you can see is the White Screen of Death. Sprinkle it around as the gentle British rain from heaven: lightly, but often.

I’m looking for a simple website management system (not necessarily a CMS, just something that can handle templates and a consistent look and feel) and an even simpler blogging system. The latter would have to be in PHP, but I’m easy either way otherwise.

Does anyone have any recommendations?