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
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.
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.
A ReactJS web app that mirrors the look, feel, and functionality of the Twenty Sixteen WordPress…github.com
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.