There’s no denying WordPress’ pervasiveness, powering an estimated 20% of the internet. However, the debate lingers as to whether WordPress is a viable development platform, particularly for brands in the agency world. The pros and cons are well documented, but let’s start with a basic list. Admittedly, many of these points are debatable and your mileage may vary.
The Case For:
- In most instances, someone somewhere has tried to do what you think you can’t do with WordPress
- Wealth of available plugins, though buyer beware
- Plugins have become more sophisticated as platform use has increased
- Familiar, intuitive administrative interface
- Custom theming and core concepts are not difficult, which makes it easy to get moving quickly
- Free and open-source
- Large community of developers
The Case Against:
- Performance, data storage, inefficient queries, general slowness
- Caching and tuning required for large, high traffic sites
- Arguably not enterprise ready or best in class CMS for non-blogging needs
- Security issues (both core and plugins), perennial target for exploits and requires regular updates that have the potential to break sites
- Customizations and extending functionality can be cumbersome, a strong understanding of project requirements and approach may be required up front
What many discussions about the finer points of WordPress or platform evaluations in general miss is the practical decision-making process that goes into platform selection. I’m using WordPress as the example here, and these are considerations I review when looking at it as a project solution. However, this is really about selecting the right tool for the right job at the right time, based on a number of factors.
Let’s run through a scenario. A project has come in and here’s what I know: budget is locked, four week development timeline, development starts in one week, light interaction on the user interface, needs a CMS so the client can update content. I have a good idea of what the site does, it’s not complicated, and I have two potential front end resources available. I might be able to get a back end developer for one week. Let’s say hiring a full-time or contract developer is not an option here.
A number of questions immediately come to mind: How big is the site? What are the core content types and their relationships to each other? What content on the site needs to be updated? How savvy is the client with CMSes and how do we lower the barrier to content entry? What’s our model for permissions and workflow? Are there any existing process pain points we need to address? Are there inbound or outbound data from external sources? Which developer is going to build this, and what experience does he or she have with custom or packaged CMSes?
While there are options, the decision here at times can be an illusion of choice. Knowing and experiencing the arguments against WordPress, it may very well be the correct choice, right now, for this particular project.
I could play the resource game, try to free up a back end developer who is most likely working on something complicated that only he or she is able to complete. If we’re not looking at WordPress in this instance, it could be a custom CMS (raw or framework-based) or another pre-packaged solution that may require customization. Depending on that other selection, I’d need to ensure that developers on the project have had experience with it, or exposure at a minimum given the timeline. If it’s raw or framework-based, there’s the possibility I’d need another front end developer at some point to work on the CMS administrative interface and possibly run the risk of data entry being a roadblock to site testing.
Alternatively, we could spend a couple of hours installing, configuring, and stubbing out a relational model in WordPress, ostensibly negating the need for a back end developer. That back end developer could then continue to focus on the projects that were assigned without disruption or impact to schedule, and, for example, I could get the benefit of exposing a front end developer to concepting out a relational data model that would be used to support the site. The CMS is ready out of the box, and we can focus on theming, plugin selection, and evaluating functional gaps.
In an agency context, it’s critical to make technology decisions given the client’s expectations, scope, budget, timeline, and resources (availability and skill set) relative to a particular point in time. The real question is not whether WordPress sucks, but does WordPress suck for this? The answer? Sometimes.