The world's greatest DIY platform, but don't use a Swiss Army knife when you need a powerdrill - or just a single blade
WordPress is ubiquitous. Since its birth the little blogging engine that could has gone from powering one-off blogs to some of the world’s most widely read (such as Mashable). And it’s gone from straight blogging engine to even taking on the role of CMS, thanks to extended theme functionality and plugins.
But we don’t use it. Not for ourselves and not for our clients.
We’re not WordPress haters. I’ve recommended it to friends, and we’ve happily helped clients that have an existing WordPress site and need to maintain the platform. But not for new projects.
What about the great things WordPress offers, you say? A 5-minute install, tons of themes, simple plugin installation, SEO capabilities…
Yes, WordPress installation is a snap. In fact, last time I installed a copy it took less than the advertised 5 minutes. Huzzah!
But I’ve never worked on a project where saving a few minutes on the installation - even a couple hours - was a priority. That would mean looking at the project and the timeline and saying, “Well, we better pick a platform that we can install in a few minutes, and totally ignore how it will affect the end product and these next few weeks/months of work.”
Who does that?
Yes, for the hobbyist blogger this matters. A lot. But for a professional web project where the timeline is typically months, saving a few minutes is not worth the consideration.
If for no other reason, lots of agencies pick WordPress because of themes. You know, those bundles of layout, styles, and even functionality all packaged together. You can add a new stylesheet or configure the theme in the admin’s interface to make it look just like your own.
Now, design-wise our clients are typically most concerned with having a design that fits their project, so they’re not terribly interested in saving a few bucks to buy someone else’s recycled theme and adding their logo.
When it comes to starting with a baseline of HTML, we like to start out with, well, a baseline of HTML. That means just the HTML, Jack. Customizing site designs is easier and faster when you’re working with components that can be brought together, rather than pieced apart and configured from a whole. Here WordPres is great if you want to add an out-of-the-box update to your personal blog. But remember, we’re talking about what we need for a professional web project.
With a framework or CMS like Django-CMS or SilverStripe, we’re updating (and reusing) functionality that’s totally distinct from how pages look on the site. And all those templates can be edited the way web designers best do so - in HTML and CSS, without logic code.
Look, there’s a reason there are so many books and guides to WordPress theming, and nary a book on doing so in any of the popular MVC based frameworks. It’s because the latter make template design natural for web designers.
A couple months ago we took on a small project for a client of a friend that entailed moving their WordPress site from one host to another. I wasn’t in the right frame of mind when I started, because the first thing I looked for was the version control repository. Surely the site and updates would all be stored in a repository, right?
No. You can’t well do that when your installation directory includes the application, the themes, user uploads, plugins, and even cache files, all mixed in together. And when you’re installing themes and plugins, you’re doing that from the admin interface, bypassing any attempt at version control.
This is why special WordPress backup sites have become so popular. It’s not a matter of backing up a database and maybe a single user uploads folder (because everything else is in a source repository), you need to backup the whole shebang.
Again, not a big deal if it’s your own blog. But when you’re dealing with a larger project, especially for a client’s organization, you want to make sure you’ve got your components separated and your versions controlled.
A quick “wordpress seo” search on Google will show you that WordPress is the darling of the SEO community. You can create readable permalinks to blog posts and pages, and install themes that follow search engine optimization best practices.
Thing is, this stuff is pretty much standard.
Pretty URLs are part and parcel of URL routing, from Django to Ruby on Rails to SilverStripe. Here’s a walkthrough on different ways to configure Django URLs. And CMSs from Django-CMS to SilverStripe help you manage page metadata, alt text, and sitemaps.
Most of the tech solutions pertinent to SEO stems from good HTML. So what you really want is a system that lets you code semantic, accessible HTML easily to your project’s requirements. Given the choice between “themes” and designer friendly HTML templates, I’ll take the latter any day.
Every CMS and framework suffers the occasional security flaw. However, WordPress has a “richer” history of security bugs and choices in the system that lead to vulnerabilities, including various exploits and vulnerabilities in downloadable themes and plugins.
Part of this stems from the model. WordPress makes it super easy to install themes and plugins through the administrative interface. Which means being able to drop in executable code via the admin interface.
There are quite a few major WordPress sites running out there without a single security glitch. And no framework or CMS is wholly free of security flaws. But we’re more comfortable building for our clients using a framework with security baked into the design.
This is “only” an issue of opinion, but a damn critical one.
One of the big reasons for WordPress’s ubiquity is its technology stack. It’s written in PHP. You’d be hard pressed to find a web host that doesn’t run PHP on their servers. So there’s no extra configuration or installation necessary, or need to search for a better web host, for that matter.
So what’s the problem? PHP, that’s the problem. We’ve found that not only is Python a more enjoyable language to program in, we’ve been more productive with it, producing better projects for our clients in less time. Much of that has to do with the Django framework, specifically, but you don’t get Django without Python. Check out what the fine folks at Heroku have to say about Python.
We’re not in the business of persuading people to use or not use one CMS or one framework (unless they’re our clients, and it’s definitely our business).
There are cases where WordPress is not only a good choice, but a great choice. Sites that are blog heavy with basic information architecture, for instance. But for basic brochure ware sites it’s often overkill (this site was created using a static generator called Jekyll). And for anything beyond that, using a framework or framework based CMS gets the job done with more productivity and less hassle.
Again, WordPress is a great DIY tool for creating blogs. However as professional web designers and developers it simply doesn’t afford us any benefits that we can’t exceed - for ourselves or our clients - using tools like Django, Django-CMS, or SilverStripe.
This is a brief explanation of why we don’t use WordPress to develop content oriented websites for our clients, not why no one should ever use it. We think the alternatives better serve our clients. If you’re looking for an allegedly unbiased opinion, here is a whitepaper (pdf) comparing a handful of open source content management systems.