A bit of history
delta-9.net has been around since 2001 (see how it’s evolved on archive.org). It was intended as a space for everyone who’d been involved in the early days to keep in touch, and to keep our community going. The message board was built one rainy bank holiday as an excuse to teach myself PHP. We started using the site to share mixes later that year. These turned out to be rather popular and we realised there was potential for the site to become a resource for the wider electronic music community.
With this in mind I developed the platform that supported the old site in PHP/MySQL. Not really a CMS – it managed a number of things: some types of content in full, meta-data for other types, user registration, permissions, message board, bulk mail, user-submitted listings. New modules were tacked on as the site evolved, everything worked and for the time it was great.
So what happened? Essentially, the site’s information architecture was dependent on having new content and this was difficult to sustain. I could see no future for music reviews, which had been an important area of content. Finding hosting for the mix downloads was a constant battle, we were consuming more bandwidth than we could continue to blag and couldn’t offer the high-bitrate audio people wanted. The CMS needed development to properly support the free tracks and live sets that artists were giving us. Much of the presentation layer dated from the 2001 site and was not exactly up to web standards. In summary, it needed a complete re-architecture.
Faced with hosting problems, not really knowing where the site should go editorially and not having time for the technical work, in 2005 we stopped maintaining the site.
It wasn’t until autumn 2009 that I gave into peer pressure and started thinking about a new site. I had ideas: more of an editorial voice, focus on audio and multimedia content, a community of contributors, enabling discussions around content rather than limited to a message board. Our hosting problems had already been solved by our good friends at Spannered, so that just left the implementation to think about.
Choosing a platform
Modifying the existing platform was just too much work (maybe more than starting from scratch), and having a bespoke CMS didn’t make sense any more. I decided to build the new site on WordPress which is a blogging engine. It gave me a lot of what I wanted for free: a user-friendly admin site, RSS (replacing bulk mail as the way we push updates out to users), user management, author profiles, search, import/export, easy installation and a large pool of free, third-party plugins (more about those later).
Sounds great, doesn’t it? Not quite. Many people will tell you that WordPress is a CMS – it’s not. It has no custom content types and terrible support for navigation, but where it fails the most is in having clear separation of content, function and presentation layers – they’re all mixed up together. The documentation is patchy, the default themes are packed with unsemantic mark-up and offer a terrible user experience. That said, this is my sixth WordPress site so I have a good idea how to beat it into submission. If I had gone with Drupal, or a more heavyweight system with advanced user/community support I would no doubt be facing a different and unfamiliar set of issues.
Tailoring WordPress
In order for this project not to take over my life I set myself some rules for the beta version:
- Don’t fight the system – build the site around WordPress, not the other way around
- Keep design work to a minimum
- Absolutely no plugin development*
If WordPress had a strap line it would be ‘everything’s a post’. Taking multiple content types and representing them in a system with just one (well, two if you count ‘page’ as different, but basically it’s a post) is a bit of a challenge. There’s an amazing plugin called Custom Field Template that makes this possible. It adds a form of custom fields to your post or page based on the category that it’s in, allowing you to define a set of meta-data for each type of post. IMHO Custom Field Template is the single most useful WordPress plugin in existence. It doesn’t, however, force required fields or do any validation, so extra logic is needed in the templates to account for this.
Other plugins worth mentioning are Ozh’ Better Feed (lets you put copyright notices and share functionality in your feed, deterring link farms from harvesting you content) and WP Page Numbers (replaces those horrible ‘next’ and ‘previous’ links with nicely coded pagination). I’ve used a number of other plugins but I’ve hacked them all, normally because the front-end HTML they spit out is so terrible. The sad truth is that the WordPress plugin database is full of crap.
Interface
There’s nothing ground-breaking about the theme in the current release – standards compliant mark-up, CSS layout, and category (rather than date or tag) based navigation, added author templates. There’s a lot of logic in the theme – but this can’t be helped with WordPress. What is unusual is that I haven’t used a single graphical asset, not even a logo, purely in order to get it out the door as quickly as possible. Our site look and feel was quite distinctive and I’ve done what I can to capture it with pure CSS, but don’t worry – I’ll be delivering something a bit more polished in a future release 🙂
*Plugin development
So I broke the third rule, but for the first plugin at least this was to save myself time. Content migration from the old site into WordPress was a big, ugly, cut and paste job. I brought across over 250 content items, a lot more than I had anticipated, even though I didn’t keep everything. I hit a big problem when I got to the event galleries, containing over 500 photos. WordPress’s inbuilt image management sucks and there was no way I was going to rebuild them by hand.
Using Flickr to manage our photos was an obvious choice – organisation through tags and a moderated group allowing other users to potentially contribute photos. None of the WordPress Flickr plugins I found fit the bill so I built one, knowing the reduction in migration time would more than pay back the development time, and I wanted an excuse to play with the Flickr API (which turns out to be a dream).
My Flickr plugin uses the WordPress shortcode API to insert an RSS friendly thumbnails gallery into a post and a JavaScript layer (JQuery is my JS library of choice for DHTML) transforms the thumbnails gallery into an image enlarger (I ditched the slideshow functionality for version 1), see it in action. I’m particularly pleased with this plugin for its simplicity and I may well pack it up and make it publicly available.
The nice thing about the wordpress shortcode API is that the RSS output is exactly the same as the web output, ensuring that people accessing the site using feed readers don’t miss out on content. I developed another shortcode-based plugin for inserting into posts dynamic links to contributors, posts and pages. Getting audio downloads to work was quite involved and I wrote a plugin for that, again using shortcodes. Shortcodes were not ideal here, it would have been nicer to code audio meta-data and download buttons into the template, but again, I needed the RSS output. It would be really, really nice if feeds were templated in WP, but they’re not.
I also wrote a plugin to generate the breadcrumb trails – I’m annoyed that I had to do this but WordPress wouldn’t give me the output I wanted. This plugin was the biggest headache of the whole project thanks to WordPress’s incomplete, inconsistent taxonomy support.
What’s next
I still have a number of outstanding bugs and technical enhancements to work through, but the next phase will include designing a shiny, new interface. If you spot anything that needs attention, please contact us or post a comment.
However, I’m holding off on planning the next version until I have an idea how people are using the new site and where our content is going. Again, if you have any thoughts I’d love to hear from you.
Thanks
I didn’t do this on my own – thanks go to Heidi for design advice (none of which I’ve had time to implement yet), Rob for coding advice, Joseph at A Little Poison for WordPress help.
