WordPress’s Conservatism: The Best Worst Thing

At the end of last week, there was a bit of action on the front of the WP (JSON) REST API finally and fully arriving in WordPress core so it can be used universally by plugins and projects without the need for installing an extra plugin. The summary: it’s probably not happening in 4.5, and it may even be some time later than 4.6. (Here’s Sarah Gooding’s story on the Tavern, Adam Silverstein’s meeting summary at make.wordpress.org.) I have opinions on that matter, but this is not an article about them. Rather, it’s an article about why this didn’t really surprise me, and where my lack of surprise comes from. This topic has been on my ideas list for a long time, and these events just pushed me to finally publish it.

Here’s the point: WordPress as a project is deeply conservative. This is, as my title suggests, something I am in turns both quite positive and quite negative about. I’m deeply conflicted, in short. What I hope is that by explaining what I mean by conservative, and the source of the conflict about it for me, I can help you better understand the project, its future, its past, and what it means for how to think about the project in comparison to other technologies you may use.

What I Mean By Conservatism

I mean conservative in the small-c sense: tending to oppose change, to be moderate, cautious, or restrained.

It’s useful, I think, to be quite clear about what I mean by conservatism. I don’t mean that WordPress is run by Torries, Republicans, or what have you. Rather by conservative I mean the small-c sense: tending to oppose change, to be moderate, cautious, or restrained.

Practically, what this means is that the project favors slow evolution rather than drastic change. It favors making serious efforts to accommodate people’s outdated set ups, lack of technical expertise, and has a deep desire to never leave anyone behind for any reason. The project can and does proudly point out that updating from 2.7 to 4.4 is an essentially seamless proposition for most people most of the time. The project has a tendency to deprecate features (discourage their use, but keep them working) but not remove them; that tendency also isn’t a source of embarrassment but a point of pride.

Practically, what this means is that the project favors slow evolution rather than drastic change.

To get specific, in 2003 a cool new feature was added to the young WordPress project: my-hacks.php. I’ll briefly quote from Matt Mullenweg’s announcement post:

In the past if you were going to add a filter or hack you would have to modify one of the existing WP files and your changes would then be overwritten when you upgraded to a new version. No more. I’ve just checked in the code that adds a new option where you can enable or disable a hacks file. When this option is enabled it checks for a file called my-hacks.php in your WordPress root and if the file exists, it includes the code from that file.

This is, as you may have guessed, the very first stab the project took toward making the software extensible in the way that plugins and themes allow today. I bring up this bit of history not just because it’s neat, but because just last year this feature was finally removed from WordPress core. Here’s the post announcing that change. I’ll repeat, a thing that was called in its name my-hacks was only removed twelve years after it went in. What’s more? That feature was actually added back to maintain compatibility. In adding it back Aaron Jorbin wrote:

Keeping myhacks support is a small price to pay for not breaking people’s sites. Even if it is very very very few sites, breaking sites isn’t something that should be encouraged. Even with 10 years of deprecation notices.

Twelve years in a pretty long time in human years. A baby born when support for my-hacks.php went in would have been into middle school when it was (temporarily) removed. 2003 was back in George W. Bush’s first term, in the first year of America’s invasion of Iraq. (I’m sure non-American contexts also had events unfolding…)

If twelve years is a long time in normal years, in software worlds it’s an eternity. In 2003 Facebook didn’t exist. Window XP was the new hotness. You were maybe a really cool web nerd escaping the slow tyranny of Internet Explorer (or Netscape/Mozilla) and browsing the web with this cool new browser called Mozilla Firebird. (It was born as Phoenix, was Firebird for a time, then settled on the Firefox name in 2004.) For Macs, Safari had just come out. (The last of our current “big four” browsers, Google Chrome didn’t come out until 2008.)

One can argue that my-hacks.php is an aberration, but it’s symptomatic of a wider trend. WordPress still proudly runs on PHP 5.2, much to the chagrin of the rest of the PHP community. WordPress still lets users edit from its interface files used to power the site (making it infinitely more likely that a naive user “breaks” his or her site) because that feature seemed cool at the time. WordPress still has tons of globals…

Why WordPress’s Commitment to Compatibility Sucks

Out in the world of programmers, WordPress especially and PHP generally (to quote Rodney Dangerfield) “don’t get no respect.” PHP started as a pragmatic and idiosyncratic language, and you still feel that pain. (I cited a few examples in my recent introduction to functional PHP; the executive summary is simply that the “standard library” is not very standardized.) WordPress started in that language, and in an even earlier version of that language than today’s, when it forced an even more haphazard style than is necessary today.

“It’s a mess of procedural spaghetti-code garbage” is not simply something I’ve heard others say of WordPress, but something I’ve said myself.

WordPress’s yoking itself to compatibility in the way we’ve talked about above makes even PHP programmers (at whom much of the rest of the programming world look down their noses) look down their noses. “It’s a mess of procedural spaghetti-code garbage” is not simply something I’ve heard others say of WordPress, but something I’ve said myself. And that’s because that statement has some truth to it.

And it could be different. If the project was less committed to making old solutions work, even old hacks, it could regularly address some of the deeper problems with WordPress from a software design perspective. Drupal is the quintessential counterpoint to WordPress here. Drupal has, historically, done revolutions rather than evolution. They’ve probably capped their adoption and active install numbers as a result. But Drupal serves many of the same needs as WordPress, but releases new major (read: backward-incompatible) versions regularly. This means that turning a Drupal 6 site into a Drupal 8 site is essentially going to require a complete from-scratch rebuild. But it also means that Drupal 8 is able to take advantages of some of the best of the modern PHP ecosystem: Composer, Symfony (and many other) components, and a design that the average programmer of object-oriented PHP cannot easily sneer at.

Drupal is the quintessential counterpoint to WordPress here. Drupal has, historically, done revolutions rather than evolution.

Because WordPress refuses to really break backward compatibility, semantic versioning is mostly meaningless in the ecosystem. WordPress 2.7 to 4.4 is likely to be a less painful change than Drupal 7 to Drupal 8. But it also means that someone writing code against WordPress 4.4 is still fighting poor design decision made before 2.7. WordPress’s casual use of globals, the weird structure of the files and folders of WordPress themes, the yuckiness that is the Settings API… I could go on, but unquestionably most of the people regularly working with WordPress have at least a thing or two they’d like to wipe the slate clean on and replace. But given the way the project is run, such things happen very, very, very gradually or (more likely) not at all.

This means that the front-end-content-editing that Fred has regularly been wishing for is slowly arriving, or more likely never will. This means that the REST API is slowly inching closer to setting the world on fire in the way WordPress enthusiasts have been dreaming about for nearly half a decade. This means that we’re still likely to hear me complaining about the Settings API for the foreseeable future.

Why WordPress’s Commitment to Compatibility is Great

I’ve been using WordPress since 2007… in that time, I’ve never had to throw out and restart a whole site from scratch. I’ve never even considered it.

I’ve been using WordPress since 2007, for everything from small hobby writing to sites for large companies. And in that time, I’ve never had to throw out and restart a whole site from scratch. I’ve never even considered it. To pick an extreme counterexample, a side project I started without WordPress has been thrown out and rebuilt three times, once for each major version of Laravel (3, 4, & 5) which has come out in the last few years.

My personal and limited anecdote is just one data point, but it fits most people’s broad experience. For non-technical people, owning WordPress is one of the least complicated technologies they deal with. It’s got issues — nontechnical people especially are terrified about security, technical people find the technology kind of backwards in the ways discussed above — but it’s really rather less trouble than almost anything from Windows to a Python OSS project is likely to be for them.

The size and scope of WordPress’s commercial ecosystem is down to more than the simple fact that a theme that worked on WordPress 3.3 also works on WordPress 4.5, but that unquestionably helps.

I touched on this a little in my argument that WordPress is the best possible bridge into web development (or more general web work) but this commitment to compatibility does more than merely reduce the cost of ownership. It also is what allows the ecosystem to be so big and diverse. Commercial themes and plugins (or their equivalents) were tried on other major CMSes, but they only worked out to build a multiplicity of sustainable businesses in the WordPress ecosystem. This is down to more than the simple fact that a theme that worked on WordPress 3.3 also works on WordPress 4.5, but that unquestionably helps.

The conservatism also helps to keep learning resources better up-to-date: it makes it much easier to use two-year-old knowledge about the WordPress interface to do things on the modestly tweaked interface today (say, when you get a new WordPress job after letting your WordPress blog die a few years back). Low cost of ownership, a myriad of learning resources, and the ability to have rather high confidence it’ll keep working so long as it’s not “hacked” makes WordPress more and more popular with marketing departments everywhere from one-person freelancers to the companies of the Fortune 500. Compatibility and conservatism make that possible.

It’s All Down To Trade-offs

WordPress’s history displays more commitment to being reliable and useful to people than it does to offering the most beautiful code or the quickest adoption of new technologies and techniques. This is its conservatism made manifest.

The REST API discussion is more than WordPress’s traditional conservatism butting heads with the reality that many developers like shiny new things. But that’s a big part of it.

The world of technology is largely cyclical. The new hotness one day is the next decade’s obscure and rejected solution. XML-RPC may not have ever been any coder’s idea of “hot,” but it was pretty close to the industry standard when it went into WordPress. Today, XML is out of favor and developers want their JSON REST APIs. I don’t believe that the conversation currently unfolding there is shaped purely by the dynamics of WordPress’s traditional conservatism butting heads with the reality that many developers like shiny new things. But that’s got a fair amount to do with it.

I love — as an owner, publisher, and user — that WordPress doesn’t move my cheese. It basically keeps working so long as I go in once in a while and run my updates and make sure I keep in mind where everything is. I don’t ever need to rebuild my sites from scratch, and I never even have to go through simple but time-consuming upgrade routines. That sounds like a small thing, but spend some time in a faster moving project or ecosystem — these days JavaScript is one — that you realize just how awesome that slower speed is.

But as a person who wishes that I could have radically better code and help people throw off the yoke of some of PHP and WordPress’s history, the project’s conservatism is a point of frustration. How many more times will I be stymied by some poorly-named WordPress function that requires a specific weird incantation before it will actually work? How much longer will I have to create ad-hoc custom endpoints for JavaScript calls because WordPress still doesn’t have the REST API in core?

WordPress is the success it is today in large part because it started long ago and has been consistently the most conservative of the open-source CMSes.

Coming to terms with reality is done by understanding the forces that lead it to be the way it is. WordPress is the success it is today in large part because it started long ago and has been consistently the most conservative of the open-source CMSes. That led to its slow successful evolution from a simple blogging platform to a rather powerful complete CMS. That change hasn’t pervaded to whole tech stack, however, because the pragmatic conservative answer to that transition was that “everything is just secretly a blog post deep down.” The least disruptive way to go usually wins out in WordPress over the most beautiful one. And so I hate that WordPress is so conservative. And I love it too.

Happy (WordPress) hacking!