CoPress

Daniel asked me to write up some thoughts about internal CMS development after we recently went through the process here in Spokane. For years, we’d been publishing on a fairly cluttered newspaper site running ASP and SQL Server. We were (and are) a pretty small staff, but in December we relaunched our main news site powered by Django ponies. I’ll share a bit about our development process – if you’re considering something similar, maybe you’ll find this helpful.

Where We Began: Decisions Before Coding

Our project started with a pretty traditional task force, assigned to explore and present options to the executives at our company. We had put off a site redesign for quite a while, knowing that while we might be able to dress up an ASP site in prettier templates, that wouldn’t give us the security we needed, or a platform capable of features that readers have come to expect. That required a complete technology overhaul. We had a few “musts” in mind, things like:

• Pretty URLs, and the SEO that comes with them. No more story.asp?ID=23984.
• The ability to do custom data design and specialized apps. The traditional newspaper content types – stories, videos, blog posts, etc. – don’t cover all the fun stuff (like pet names databases) or all the serious stuff (like a news report on diploma mill recipients)
• Getting into a development framework with an active user base. (Ever tried to find troubleshooting help on your ASP-powered image uploader? Good luck)

And so on. I’m sure our list of “musts” looked pretty much like yours would. We investigated a couple mass-market CMS options, but didn’t find any that were even close to providing the flexibility we wanted. (Not to mention, pbcs.dll does not a pretty URL make.) That left us with open-source systems, and I was pretty sure from the start that we’d end up wanting to go Django. For any Drupal fans out there, we certainly thought it was a good option – Django’s strengths just matched up with ours in a better way. It more than answered our needs.

The top two options we presented to our executives were:

1. Rolling our own Django-powered CMS
2. Buying Ellington

While we were comfortable developing a homegrown system (and had done so for the previous incarnation of the site), we bought the Ellington source code for two main reasons. First, this would be our first Django project, and a pretty high-profile one within the company. The advantage of starting with tried-and-tested code was really attractive. And second, starting with Ellington would obviously give us a big head start on the development timeline.

At the time, though, the commercial version of Ellington ran on Django 0.91, and there wasn’t a concrete timeline for bringing it current. Right as we began working with the framework, Django 1.0 started to pick up steam, promising some excellent features we wanted to use (GeoDjango, for example, and newforms-admin. Forwards-compatibility!). We also knew that we’d want to adopt and/or tweak a number of third-party Django apps, and there just wasn’t much development like that going on against 0.91. So we made a tough call. To future-proof ourselves, and not spend time in 0.91 that we’d have to re-spend updating to trunk, we decided against launching on Ellington. Instead we’d use that code as reference, and go back to developing our own CMS. We took to calling it Cannonball, in keeping with Django’s jazz-name tradition.

(Just to be really clear: I’d hate for anyone to think that decision represented any kind of qualitative judgment. The crew in Lawrence is awesome, and Ellington is a great product that I wholeheartedly recommend still. It’s on Django trunk now – our switch was a peculiarity of timing, and wouldn’t have been the right choice for everyone.)

In deciding to build our own CMS, we knew by launch time that we’d have given up some functionality that Ellington offered out of the box. But not only would this put us on trunk and let us tap into current developments in the Django community, we also had workflow and features that we wanted to handle differently than Ellington did. tagging, for one, was a big deal for us. I badly wanted to have a sitewide tumblelog, and so on.

Timeline for Building the CMS

After framing up our new project requirements, we started development again in May 2008. Besides me, the team included two great developers on staff, a super-smart intern from Mizzou, and about half the newsroom admin that handles our front-end publishing system (CCI, if you’re curious). Our IT department assigned one server admin to the project, so we also had his time for certain things. The first two months of our project were basically a sprint to get the essential content types in place, and port across legacy data (which is always a pain). By July we had the stories, photos, galleries, and videos moved over. With the first milestone out of the way, we spent the next two months on a number of tasks, fleshing out more features we wanted to add, updating everything to newsforms-admin (which dropped in the middle of our projects), and building templates for our initial design. We also had plenty of training to do with newsroom staff, so they’d be prepared to manage content in a completely different way.

By Sept. 1, we had a fully functional CMS, full of legacy data and ready to run a public-facing site.

Ultimately, we didn’t end up launching for another couple months, but that was over some pretty specific internal issues. For one, our publisher wanted some different things from the design (which ended up being a good thing in the end – I’m happier with what we have vs. the initial look). And the main reason: We had huge layoffs in early September, right as we would have been going live. But those were pretty special circumstances. We spent right about four months on a complete overhaul, from servers to software to data architecture to design.

Our new site is by no means perfect; there are apps we still need to add, and a number of design issues I’d still like to address. But it was our first Django project and I’m extremely pleased with how well it went. Of course, if we were just starting now, we’d be able to take advantage of some really nice Django features that weren’t in place when we started. Model inheritance, for example – something that The Washington Times’ multimedia app uses nicely. And we wouldn’t be newbies either.