Building a better WordPress
WordPress is many things to many people. For some, it’s the tool given to them by agencies to change the copy on their website. For others, it sits right at the core of their entire business, while some see it as a framework and tool to build large applications and data management systems.
This is something WordPress respects, which it has to, in order to maintain its monolithic market share — almost 25% of all websites are built using it. However, it is often this desire to be everything to everybody that keeps it from becoming the modern content management system it has the potential to be. We need to break away from many of the restraints that hold WordPress back, look forwards toward new technologies — both front end and back — that offer innovative solutions that remain simple to use for the every-day user. This starts by moving away from template tags and “the loop”, looking beyond jQuery as a framework, and starting to embrace the almost endless possibilities of the REST API. However, to do this, WordPress needs to change — here’s how.
The New WordPress
Today, WordPress is a jam-packed CMS filled to the brim with features and functionality. Not only that, but it includes an archaic layout system (theming) that requires anyone who wants to work with it to know both PHP and the intricacies of the functions laid out in the WordPress Codex. Our templates become messy (🍝 code) as we mix PHP calls and logic with our HTML and JavaScript. Almost all interactive elements are built using jQuery, which, while a great library in many respects, is weak in comparison to many of the emerging front end frameworks we have today — ReactJS, AngularJS and others. And as we look to the end of this year and into next, every version of WordPress brings more and more functionality into the core, much of which may never get used by the majority. However, it doesn’t have to be this way.
Imagine a world where WordPress is lean, fast, and efficient. In this world, WordPress has just one task: to manage your content. Out of the box, WordPress should contain the bare minimum functionality to get up and running:
- An easy-to-use management interface
- Basic data structure for posts and pages
- Authentication and user management
- A RESTful API for interfacing with your data
- A simple extension architecture
- Basic site configuration — e.g. site title, localisation
Luckily, we have most of this already:
- The WordPress admin interface is it one its best features, and provides a clean and elegant way of viewing and managing data
- We also get our basic data structure, and authentication / user management — great news!
- The work being done by the WP-API team on the REST API is great, and version 2.0 should be out of beta soon. The good news is we can start using this right now (either version 1.x or 2.x), regardless of if and when it makes it into core.
- WordPress’ plugin architecture is reasonably good — however, the dependency on PHP can turn many developers away from using it. Here, we need to investigate the potential of JSON configurations and third-party integrations as a route to offering more people a way of working within the WordPress ecosystem.
It’s worth noting at this point that having a RESTful API eliminates the need for many things plugins are currently relied upon for — although — not everything.
What! No theming?
You might have spotted that I haven’t included any theming functionality in the above list, and with good reason. After building a number of websites and apps using WordPress and the REST API, I’ve come to the conclusion that WordPress isn’t the best tool for handling layout and presentation. Not only is it restrictive in terms of functionality, but it also limits the people who can work on it, as only PHP developers are able to decipher even the most well-structured WordPress theme. Other developers are often left out in the cold.
Yet again, the RESTful API comes to our rescue. Thanks to its simple JSON output, we’re able to use JavaScript to its full potential, using ReactJS or AngularJS to craft beautiful and fast front end experiences, taking advantage of many of the new HTML5 browser APIs that have become available over the past few years, including localStorage and more recently, service workers. Even better, we don’t have to use jQuery.
The other major component missing from this list is menus. In many cases, menus can be unnecessary depending on the nature of the app you’re creating. This functionality should be included as an optional plugin that can be activated to provide it.
Twenty Sixteen — ReactJS + REST
To prove that WordPress no longer needs any theming functionality, I thought there was no better way of demonstrating that than to recreate the new Twenty Sixteen default WordPress theme using ReactJS and the REST API.
This app (note: no longer a ‘theme’) — built over 24 hours — uses ReactJS and the React Router open source project, and consumes all data via the WordPress REST API. As the current version of the REST API doesn’t support additional data such as menus and custom fields, I’ve used plugins to fulfil that requirement. The app uses localStorage to cache requests, meaning that navigating the site feels almost instant. Data is reloaded shortly after the initial request for the page, ensuring the content is always up-to-date.
While only a skeleton structure of the full Twenty Sixteen theme, missing many key features — due to time, not technical limitation — it is clear that not only is it possible to create these great experiences, but also very quick. The potential of sites built using this architecture is considerable, and only time will tell what imaginative ideas the developer community will come up with.
Fixing front end frameworks
I’ve already mentioned using localStorage as a mechanism for providing caching in front end apps, ensuring content is loaded quickly, avoiding ugly loading screens and flashes of blank content, but this only goes so far. As ReactJS (and soon AngularJS 2.0) can be run on the server as well as in the browser, we can pre-render the initial page load for the user on the server, and then hand-off all future content and navigation requests to the browser. This works well, except that servers that run WordPress can’t render ReactJS components. This puts us in a tricky situation, one that — at present — I don’t have an answer for, although I have a few suggestions:
- Run an adjacent Node.js server alongside your WordPress server that also uses the REST API, all requests are served from here
- Find a way to render ReactJS templates in PHP
- Compile ReactJS templates into WordPress templates using a task runner, such as Grunt or Gulp
- Re-build this new WordPress in Node.js, and forget about PHP altogether
While these are probably in descending order of immediate practicality, I’m actually a fan of #1 and #4. It is possible to implement #1 today without significant work, continuing to use WordPress as a great platform for managing content, and using the Node.js server to render ReactJS templates and serve content, all via the REST API. The main drawback here is having to run an additional server, and the cost and time associated with that.
Alternatively, #4 eliminates the need for this additional server, by running this hypothetical CMS on the Node.js server as well. This is — of course — unrealistic in the short term, although projects like Ghost are good examples of how this might work in practice.
Building a better WordPress
It’s perhaps unrealistic to think we’re going to replace the stalwart that is WordPress anytime soon, and I’m not even sure I think that’s the best idea. However, if a Node.js replacement for WordPress was to succeed, there are a few key components it would need to have:
- As easy — if not easier — than WordPress to install and use for non-technical users
- An array of hosted options, that provide a stable and reliable environment (i.e. WP Engine)
- A simple upgrade path from existing WordPress installations
- A community driven development process with regular contributions
In the meantime, we can already get started by putting time and effort into new Rest+React apps that focus on using ReactJS alongside the WordPress REST API.
These initially experimental apps should be used to push the boundaries of front end frameworks when used alongside the REST API, establishing standards and reliable examples that can be taken forward to build apps and sites in the future. They should employ the same level of simplicity and detail that existing WordPress themes have, but should take advantage of everything the modern web offers us.
Of course, the future of WordPress is subject to great debate, and many people may disagree with the approach outlined over the previous 1,600 words. However, since WordPress launched twelve years ago, the web as we know it has changed dramatically, and WordPress should be there right alongside it as a modern and innovative content management platform.
Chris is a Newsroom Developer at The Times and Sunday Times, and lead developer on CardKit — a simple to use image creator for the web. He also maintains ACF to WP-API, a open source WordPress plugin. He is on Twitter @chrishutchinson and GitHub.
