Making web content management work

How does a venerable publisher like WIRED.com evolve a website and CMS platform two decades in the making? That’s the challenge WIRED.com’s Director of Engineering Stefan Antonowicz described in a recent blog post foreshadowing changes happening under the hood to make WIRED.com “faster, more stable” and better able to support future ambitious projects.

While the post was a courtesy heads up alerting WIRED.com readers of potential hiccups, the comments included fascinating details on the process as Antonowicz generously engages with readers. The conversation also continues this morning, as apparently, a final load test uncovered enough potential issues to wave off the planned Sunday launch. It’s rare to get such raw, real-time commentary from a large-scale CMS replatforming.

Antonowicz describes WIRED.com’s platform as “a mix of really old stuff pre-2007″ that include flat files, PHP and Perl as well as a WordPress install that dates to around 2007 (although I found a blog post from Matt Mullenweg dated 2009). One of the big challenges, according to Antonowicz, is consolidating 17 separate WordPress blogs into one.

He comments on the difficulty of trying to update a site in so many different places every time there’s a change. A challenge anyone managing large, legacy content platforms knows all too well.

Scaffolding got put over the whole shebang to try to tie everything together, and that worked OK in terms of being able to maintain the site, but new stuff was a Herculean task trying to figure out how the 17 code forks would coordinate.

When asked about the choice to stay with WordPress, he acknowledges it may have made sense to explore alternatives, but the realities of resources, politics and knowledge of the existing platform made sticking with WordPress more realistic path.

From my experience, sometimes reinventing the wheel can cause more headaches than the problem you set out to initially solve. WordPress, for its shortcomings, is something that’s been worked on for many years by large teams of developers – so by hitching my oxen to that wagon I get to reap the time and resources other folks put into it. Additionally, we were in [WordPress] already – so I get to reap some of the benefits of all the devs before us that have put time into the system – which is more currency in the sack for me.

Accordingly to Antonowicz (and to the apparent chagrin of many passionate commenters), this project is purely focused backend architecture — A necessary first step to clean up the house and enable bigger and better front end changes. What’s interesting is that, while keeping WordPress, Antonowicz and team appear to be working to decouple WordPress further in separating the author experience from the front end website and publishing. He comments:

So philosophically I want [WordPress] to do the thing it’s good at (be a CMS that manages data) and separate that from what it’s maybe not great at (displaying that data in a way users can interact with that I can scale limitlessly). This particular project is the first step in making that a possibility – hopefully we can one day pull the display and input of that data completely apart, and then we can do what we like by just writing APIs that interact with the CMS as one of potentially many endpoints.

He also drops some CMS wisdom in the process:

At the end of the day, it gets devs out of the way of everyone else – and I think that’s the key to the job we do. Get Technology Out Of The Way.

A big hat tip to  Antonowicz for engaging WIRED.com’s readers in an honest and transparent (and patient) conversation about the changes happening with the platform. And best of luck with the performance tuning. No small issue when you’re managing a publishing juggernaut like WIRED.com.

Oh, and does anyone still not believe WordPress is a CMS? Didn’t think so.

{ 1 comment }