In the previous chapter, we explored Slots and Fills that are part of the
@wordpress/components package and showed you how to make your own plugin better integrate with the WordPress UI, bringing us one step closer to being more interoperable with WordPress.
In this final chapter, we’ll look back at what we’ve created and discuss a few points of interest that we didn’t cover in this series of posts.
In the first chapter of our adventure, we dove into the basic setup of our project and the initial building of two forms, one in jQuery and one in React, that we later used to simulate a WordPress-like environment when it comes to editing a post or page.
After this, in chapter two, we introduced Redux, a framework that ensures that data always flows in a single, consistent direction, ensuring data behaves predictably. We also touched on the subject of stores and reducers and introduced a way to connect these Redux principles to our forms.
Connecting to the WordPress API
Chapter three brought us one step closer to integrating with WordPress’ APIs, where we move from our bare bones Redux implementation and move to the
@wordpress/data package, which introduces a similar approach to managing data, but in a more WordPress-compatible way. We also introduce a new concept: Selectors. These selectors are the way WordPress allows developers to retrieve data in a simplified and structural manner.
Using the core/editor store in your plugin
In chapter four, we looked at the
core/editor package, which is used to manage data from the WordPress editor and makes us more interoperable with WordPress. We altered our project to utilize a ‘dummy’ version of this package to demonstrate its usage and how plugin developers can call functions within this package to retrieve data from the WordPress editor for usage in their own plugins.
Using Slots and Fills
Finally, in chapter five, we looked at the concept of
Fills, which is another method that WordPress 5.0 introduced to allow plugin developers to integrate with the sidebar of the WordPress editor. In this chapter, we created another ‘dummy’ implementation of the WordPress editor, including a sidebar and the underlying parts that ensure data is properly propagated. Implementing this brings us another step closer to our goal of full interoperability with WordPress and its APIs.
The Blocks API
Now, the concepts of blocks might seem familiar. Most page builders use the same concept to make editing the layout for users as intuitive as possible, as it seems almost natural for most people to stack blocks as if they were working with LEGO! However, these implementations mostly use a custom data structure and ‘hijack’ the WordPress editor to achieve this. Unfortunately, this frequently leads to interoperability problems with other plugins, necessitating everyone to start using unreliable methods, such as directly reading out the DOM to retrieve data… So how does the new WordPress editor deal with this?
The answer to this is the Blocks API. This API opens up WordPress like never before, making it possible for plugins to integrate even more and expand the number of available blocks currently present within the editor. Furthermore, it allows developers to translate complex concepts, into a single and contained element within the editor, with a user-friendly UI. One example is the HowTo block we’ve created here at Yoast, which makes the creation of ‘how-to’ articles easier, whilst also ensuring the proper Schema output is added to the HTML of the website.
Sadly, not everything is sunshine and rainbows with the introduction of these APIs. The custom data structures that we mentioned earlier aren’t something that can quickly be converted into something that is 100% compatible with the WordPress APIs. Additionally, the Blocks API is still lacking in a few other areas. For example, widgets are still not available in a block-like manner, which is something that some page builders might rely on.
A possible solution
Luckily, not all hope is lost! If you’re a page builder that wants to integrate into the WordPress editor, there's an option in the form of Dynamic Blocks. What this allows you to do, is register separate blocks that have a (as the name suggests) dynamic component to them. Usually, this dynamic component is something that uses its own data structure internally and communicates with WordPress via a server component, which is written in PHP. What this means is that plugins such as page builders, largely only need to focus on integrating a UI that is compatible with WordPress and don’t need to rewrite everything they’ve created thus far.
One plugin that utilizes these Dynamic Blocks rather well is ACF Pro. We’ve even written an article on the usage of Dynamic Blocks via ACF and how you can use this in your own plugin because it’s rather robust and easy to learn, as they utilize a PHP-based approach. This takes out a large part of the learning curve when switching to React and Redux. At Yoast, we also utilized Dynamic Blocks in our digital story on the subject of diversity, inequality, and prejudice to speed up the development process and have an easier to maintain a project. We’ve also written an article on how that project was built if you’d like to know more.