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 Chapter 10, 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.

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,¹ 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.