The first edition of Building Web Apps with WordPress was published in 2014. A lot has changed in the five years between the first and second editions. A lot is going to change in the five years after this second edition is published.
In this final post, we will briefly point out some of the big changes in WordPress over the past few years. If you’ve read the book up to this point, you should have a good handle on these topics.
We will also make some predictions about the future of WordPress. Some of these predictions might miss the mark, but in general these are topics worth keeping tabs on for the next few years.
Where We’ve Been
WordPress version 3.0, released in June 2010, was the first to provide support for CPTs (these are covered in detail in This Post). The addition of CPTs was the final step in the transition of WordPress from blogging software to a content management system. The addition of CPTs empowered developers like us to start using WordPress as an application framework.
WordPress version 4.7, released in December 2016, included REST API endpoints for posts, comments, terms, users, meta, and settings (the REST API is covered in detail in This Post). While a feature plugin that enabled REST API support had been available for a couple years before this release, the existence of the REST API in the core WordPress plugin “blessed” the use of the REST API and encouraged developers to start building with it.
WordPress version 5.0, released in December 2018, included the new Gutenberg block editor (Gutenberg, blocks, and CPTs are covered in detail in This Article). The block editor is new, and it will take time for sites, plugins, and themes to start taking full advantage of it. Still, the block editor enables a new paradigm for managing site content, layouts, and other settings. The Gutenberg project also showcased the use of a modern JavaScript development stack, embracing tools like Node.js, npm, React, webpack, and Git. In many ways, the Gutenberg project and feature plugins are setting the standards for WordPress development in general.
The REST API
Even though the REST API was fully added to WordPress in version 4.7, it has taken a few years for developers and development stacks to start using and supporting API-enabled apps to their full potential. The REST API is now being used in various areas of WordPress core and many important plugins. Over time, we will see the REST API become an even more important feature of the WordPress platform.
WordPress Plugins Will Focus More on APIs
Many projects now are starting out with an API-first mindset. Build the APIs your app will need separate from the frontend. Then decide what stack will work best for your frontend. This makes it easier to maintain the data layer of your app and also easier to add more view layers for your apps. The same WordPress content can power a blog website, a mobile app, and an email campaign, and any other app that needs that data.
Plugins like WooCommerce and BuddyPress have APIs with nearly 100% coverage for every plugin feature. This makes it easier to integrate data from those plugins with the apps plugged into your WordPress site.
Headless WordPress
It is becoming more common to see WordPress used solely as a content data store for larger web apps that access that data through the REST API. Using WordPress in this way, where the administrator dashboard is used without using the built-in themes and frontend, is known as “headless WordPress.”
Static site generators like GatsbyJS offer a way to host static sites that are secure, fast, and relatively cheap to host. You can configure GatsbyJS to use WordPress as a data source. The WordPress installation managing the content doesn’t even have to be hosted online and could even be run from a local environment.
Even dynamic sites can make use of headless WordPress if the dynamic bits of the sites are coded in JavaScript running in the client and using third-party services or APIs running on their own servers coded specific to what is required.
This kind of component-based development is popular now. There are pros and cons to having your app distributed across several different servers and services.
On the pro side, using several different services to run your app makes sure that each of those services is optimized for its purpose. If one component fails, the rest of your app may be able to run without it for a while. If one component has a security issue, you may avoid exposing your entire app. If one component needs to be replaced, it should be easier to replace just that one component versus the entire platform.
On the downside, using several different services to run your app means that you will spend more time learning new platforms and working out integration issues. Sometimes the various services won’t work together so seamlessly, and you will need to get clever to make things work.
There seems to be a cycle in development best practices from self-contained apps to ones spread out across several services. Over time a collection of individual tools that work together well will get bundled up into hosting packages, integrated development environments, or managed containers. These bundles will mitigate some of those integration issues and make it easier to use a specific collection of tools. Then, over more time, these bundles will be viewed as a single platform. When you sign up for a WordPress-managed host now, you generally don’t have to think about the web server, database, PHP modules, or other tools that are running on the host to get WordPress working. In the future, there will be similar one-click installations for WordPress apps using a different collection of technologies, hosted across different servers.
GraphQL
GraphQL is a query language for APIs, and is likely to replace REST APIs everywhere, including in WordPress. We spent a lot of time, all of This Blog, describing and praising the REST API. So what makes GraphQL so much better?
With a traditional REST API, the API has to define the endpoints, including what data must be passed into and out of requests. With GraphQL, the service making the requests defines the query and the format in which it wants the data returned. This means there is less work required to publish and maintain the API, while giving services using that API more flexibility in how the API is used.
Using a REST API is like using a function in PHP. There are predefined parameters (although some are optional) and data is generally returned in the same format. GraphQL is like making a SQL query. You can query any available data, join data how you want, and define the values you would like returned.
To learn more about GraphQL, visit https://graphql.org/ or read Learning GraphQL by Alex Banks and Eve Porcello (O’Reilly). WP GraphQL is a plugin for WordPress that enables GraphQL queries against your WordPress site. Learn more at https://www.wpgraphql.com.
Gutenberg
Since the introduction of the new block editor in WordPress 5.0, we’ve seen rapid development of new blocks and use cases for the block editor, both in WordPress core and in other projects. In this section we cover a collection of predictions around Gutenberg and the block editor.
The Administrator Interface Will Move to React/Gutenberg
Any setting related to how content is displayed visually on the frontend of your website is a perfect candidate to be ported to blocks. And so as part of Phase 2 of the Gutenberg project, widgets and navigation menus will be ported to blocks.
Moving other admin screens to use React and API calls can greatly increase the performance and usability of the WordPress dashboard. Some prototyping around how the WordPress List Tables view can be ported to React can be found on the New List Tables GitHub repository.
Gutenberg Will Power a Frontend Editing Experience for WordPress
Already, the WordPress core developers and block developers try their best to have the block editor resemble as much as possible how content is displayed on the frontend. As things like menus, sidebars, and other parts of the layout of a web page move into the block editor, you will basically be able to change any aspect of your site’s design by arranging and editing blocks.
There may be disagreement over what it actually means to have a frontend editing experience for WordPress. At the same time, swapping to the dashboard may become so quick and seamless, that the current editor experience may become “good enough” for many who desire frontend editing. While an official “frontend editing experience” may get delayed, there will be something close to it or plugins to fill the gap.
Block Templates Will Replace Themes
WordPress themes define the look and feel of your website through choices of color, font, and layout. Most themes allow for flexibility of color and font through customizer options, and now layouts can be controlled through block templates.
This is a gross simplification of website design, and a good design will include a lot of subtle art outside of colors, fonts, and layouts. At the same time, this is the level of control that users have come to expect when selecting a theme for WordPress.
The job of a good theme will be to make sure that popular blocks and block templates look good with the theme’s design.
For a while, themes that added complex features would have those features labeled as “plugin territory.” The core principal behind this label is that a user should be able to change their theme without losing any content or functionality in their website. Anything that breaks this principal should be coded into a plugin instead. Themes in the WordPress.org repository had to follow this rule completely, and many themes sold outside the repository tried their best to honor the rule while still having their themes stand out and support specific use cases.
Many theme shops have basically become plugin shops, selling premium plugins that allow their themes to reach their full potential. The “plugin territory” of many of these themes is now “block territory.”
Themes will not go away. But the theme you select will set the tone for how your website looks, but over time the handling of headers, footers, sidebars, and other layout components will be controlled in the block editor.
Blocks Will Replace Plugins
A common refrain in the WordPress community has been “there’s a plugin for that.” With more than 50,000 plugins in the WordPress.org repository alone, there is a good chance that there is a plugin for nearly any feature or integration you are looking for. You just have to find it.
As the block editor controls more of the attention and focus of the users building sites with WordPress, those users will be trained to look first for blocks to meet their needs. Many of those blocks will be delivered by plugins, but blocks can also be added by loading a JavaScript file from a shared server.
Plugins will not go away, but users will more and more think about them as they relate to blocks. Instead of a membership plugin, users will search for a membership block. While existing plugins can add blocks,1 plugins that are built from the ground up as blocks will be more approachable for users and better able to iterate on the new tech stack and development paradigms standardized with Gutenberg.
WordPress Market Share Will Increase and Decrease
WordPress powers about one-third of all websites on the internet. Between 2011 and 2019 WordPress market share has increased from 13.1% of all sites to 34%. Statistically, this rate of increase doesn’t seem to be slowing down much.
From an end user standpoint, WordPress competes with self-hosted services like Squarespace and Shopify. WordPress-based hosts have streamlined the process for setting up a new website, and the new block-based editor has streamlined the process for laying out content. These improvements mean that WordPress will continue to compete favorably with the self-hosted solutions.
Vertical consolidation of WordPress companies, with hosting companies buying plugin and theme companies, will further streamline the process of creating WordPress-based websites.
While the number of websites fully developed with WordPress might flatline or decrease a bit, the increase in decoupled websites using WordPress as part of a broader application stack will increase.
WordPress Will Become a More Popular Platform for Mobile Development
The REST API, standards for Progressive Web Apps, and tools like AppPresser make it easier than ever to create mobile apps with WordPress. If you’re building a web app using React and a headless instance of WordPress, it makes sense to use that same WordPress instance to power a mobile frontend developed with React Native.
WordPress Will Continue to Be Useful for Developing Apps of All Kinds
Five years from now, WordPress will still be around and powering even more of the internet. The platform will be better. The APIs will be better. The tools will be better. Hosting and other services will be better. This book will have published another edition or two.
We’re excited by all of the great work you and other WordPress developers will do. If you build something awesome with WordPress, share it with us on Twitter at @BWAwWP or contact us at https://bwawwp.com.
1 Paid Memberships Pro definitely did soon after the release of the block editor.
