A Guy With An Idea

I get asked this one a lot:  Why would you choose WordPress as the content management system (CMS) for Pif Magazine?  The answer is really quite simple: What else would we choose?

Or more precisely, what else could we have chosen?

There are dozens of CMS systems out there, sure.  But to be quite honest about it, most of them stink.  And none of them – not even WordPress – are geared towards magazine publishing (the whole author/editor relationship I’ll address in a  future post).  Many CMS’ come close – some even closer  than WordPress – but none of them did everything we wanted our CMS to do.

11 years ago when we made the migration from static HTML to a database-driven design, we looked around, saw a suite of products not that dissimilar from what’s available today (though modern features have improved dramatically) and decided to use the product that was the closest to being a”magazine” publishing system we could find.  Anyone remember a product called PHP-Nuke?   Granted, it didn’t have all of the bells and whistles we needed – but it was damn close.

2 years worth of customization later it was even closer to being what we ultimately needed, but still not quite.  By the end of the slog we had completely re-written the Nuke code base to meet our specific needs, but still could not keep up with feature requests fast enough.  To make matters worse, the Nuke code base was headed in the opposite direction from where we were headed.  We were trying to modularize the code, separate the presentation from the business logic, while the core code base was moving in the direction of wholesale adoption of every feature request thrown at the team.  Our last code merge with the Nuke base was in 2001, and with that merge we inherited several dozen features from the core that we then had to spend the next 6 weeks removing because they broke our test build.  From that point forward we were officially “forked” from Nuke and headed in our own direction.

It wasn’t pleasant.  Never fork an open source code base unless you have a damn good reason to do so.  And even then, don’t.

When, during the latter part of 2009, we decided to retire SIDney (as we affectionately called our now homegrown codebase) we again looked around for an off-the-shelf replacement.  Only this time we decided to go with something that was relatively feature poor but highly modular.  Given our previous experience, we knew that true modularity was the most important thing in our CMS.  We needed the ability to drop features in and pull them right back out at a moment’s notice – and to do it all without having to recode so much as a stylesheet.   WordPress allows us to do this.  Modularity is one thing this product has nailed – hands down.  Others claim to be modular (and maybe they are in their own minds), but WordPress gets this one important thing right.

I’m not intending to start a flame war with the Joomla vs. Drupal vs. WordPress crowd.  I’m just telling you why we went the way we did.  Your needs and mileage may vary.

In the end, though, I can tell you this: we’re still not confident we made the right decision.  But we made the best one we could, given the circumstances.  More on that in the future.

Happy coding!