The Road to 100%: One Future for WordPress

I see the next 3–5 years as a time of transformative growth for the world’s most popular CMS

It’s the day after Christmas, and I find myself thinking of the themes that bind religions together. The stories and legends we pass on to our children reflect the seasonal cycles of the natural world. The annual wheel of death and rebirth, of planting and reaping, becomes the lives of our gods themselves: Jesus, Osiris, Dionysus; the pervasive tale of the dying-and-rising god.

In some respects, WordPress has never been healthier. But it's starting to show its age. If we cling to the WordPress we love, it may whither and die, alone and forgotten. If we let it succumb to the natural order of things, I feel it can rise again to empower publishers in the 2020s and beyond.

To crush your enemies, see them driven before you…

The public first experienced WordPress in 2003. In those early days, we saw PHP 4.x’s first attempts to graft object-oriented programming onto a language originally designed as just a way to put some dynamic elements in a static web page. There’s a “PHP style” that dates back to these days, with markup and code intermingled, objects with barely more than a few static methods, and custom database routines wrapping PHP’s wretched pre-PDO database support.

The oldest, darkest corners of WordPress bear scars of a warrior who grew stronger, wiser with each fallen enemy. Parts of the wp-admin directory reflect the best practices of a decade ago. Given WordPress’s devotion to legacy support, is it any surprise Automattic developed Calypso rather than wedging a new admin experience into the legacy one’s footprint?

The old warrior must REST

The most recent WordPress release introduced a highly-anticipated REST API. Automattic’s own JSON API powers Calypso and the WordPress data source for Microsoft’s Windows App Studio. Our community obviously sees a future in making WordPress’s data accessible over some API.

Matt Mullenweg’s 2015 State of the Word heralds JavaScript’s growing role in WordPress development. He won’t suggest we’re about to abandon PHP, but urges developers to learn JavaScript deeply. Calypso has shown how modern JavaScript and a REST API transform WordPress’s editing experience, and I feel applications like Calypso and the APIs that power them will evolve over the next couple years until wp-admin can be universally replaced by desktop, mobile, and browser apps.

Calypso doesn’t currently support custom postmeta fields, so the bespoke editing experiences developers build their clients aren’t available. But Scott Kingsley Clark’s proposal to give WordPress a Fields API would offer a standard way to define fields and editing controls in code. Make those definitions available over the API and tools can tailor their metadata fields to each site without any custom development.

I already know one large publisher intending to roll out a site that divorces its public-facing front-end from WordPress completely except it retrieves content from the REST API. This certainly looks to be the future of WordPress theme development. The WordPress.org Theme Review Team already allows themes that rely on the REST API into the WordPress.org theme repository. We’ve officially freed theme developers from The Loop and other idioms of legacy WordPress development.

With all this focus on APIs, the WordPress community needs to standardize on one. I expect Automattic will need to deprecate their JSON API and work with vendors to phase it out. Developers will be less confused when there’s a single API to support. JSON API may live on through some sort of compatibility layer in WordPress, deprecated and barely supported, until it’s ultimately removed.

Rebirth as an API

The legendary Phoenix dies in a show of flames, only to be born again from its own ashes. REST API will be that flame.

In this new world, two people could use two different WordPress editors, even if they’re sitting right next to each other, working on the same site. A web browser, news reader, and assistive device could access the same content yet render it in their unique ways.

When everyone interacts with WordPress through a standard API, it doesn’t need to live on as a singular PHP application. WordPress becomes a lingua franca for content management. WordPress as an API can be implemented in PHP or any other programming language, and support any database or other storage engine. Implementations can be swapped out at will as technologies mature and evolve. Even CMSs which were once our competition can implement our API and continue on as they are, but with access to the same tools our authors use.

Community, philosophy…religion?

Today’s content creators love WordPress’s approach to organizing content, its language of post types, media, taxonomy, and metadata. They love the community’s spirit, the Code is Poetry metaphor, and Matt’s quirky obsession with jazz. We don’t need to abandon any of these things. If anything, developers turned off by the current state of our code will have new reasons to join our family, as will authors sick of TinyMCE. We’ll all benefit.

This is only my vision, and it’s only one of the possible ways for WordPress to reach toward that impossible dream of 100% market penetration. Despite its warts and aging underpinnings, WordPress is loved. Every day, I see folks excited to be building projects atop it. I’ve met hundreds of people who swear by its content authoring experiences. I see no reason for WordPress to just fade away. But we have to embrace the future and face our discomfort with its changing nature if we’re going to continue using it into the next decade.