In August, the Core developers will probably publish WordPress 5.0, the long-awaited WordPress update. One of its changes: It replaces the current editor with the Gutenberg editor. No matter if the update is coming in August or later – you already have to think about it. Because Gutenberg is a challenge both for website owners and WordPress developers. Many WordPress developers need to rework their established workflows to individualize the editor page. Because with WordPress 5.0, they will mostly need to interact with a React application. So, how to develop for Gutenberg?
Most Gutenberg discussions focus on the question of how to develop custom blocks. Already, the Gutenberg developer handbook offers much useful information on this topic. Additional to that you can find many How To’s and tutorials to register your own blocks in the Internet. However, what hasn’t been much discussed yet, is how to enhance Gutenberg beyond blocks.
But those who have experience with the development of WordPress plugins and themes for customers know that customer desires are more than just the development of blocks. Instead, they require highly individualized editor customizations. That’s why we concerned ourselves with Gutenberg in our Developer Meeting lately. Amongst other things we took a look at the presentation “Beyond the Block” which offers a deeper insight into the Gutenberg application. There are only few information on this topic yet. That’s why we thought other developers might like to hear something about that topic, too. So here it is:
You are currently viewing a placeholder content from Youtube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
Develop for Gutenberg: About the presentation “Beyond the block”
With the help of an example plugin and a fictional customer, we discussed important Gutenberg aspects by means of individual features. These features are then developed in separate branches. As the discussed code in the presentation focuses on the problem talked about, a git diff
between a branch and his precursor branch enables a more detailed overview about the code needed.
The presentation itself focuses on data stores which are responsible for the state management in WordPress. They contain important information, for example which post is currently edited, which certain content has been edited or which blocks are in use. So, with the help of these data stores it is possible to get information about the current post and to edit the current post.
An example. In case you run the following code in the Console, the post title will be “Another title” and the previous title is overwritten:
wp.data.select('core/editor').editPost({title:'Another title'})
Besides to an overview of Gutenberg’s state management, the presentation also introduces the Slot/Fill concept. It answers the question of how to render your own content into an already existing component.
Edit: Since WordPress 5.0 is now published, I have updated the Github repository. Since my talk there have been quite some changes, which are now reflected in the master branch of the repository.
6 comments
Great post David
I’ve seen just plain gutenberg block article until now
Do you plan other posts like this on extending gutenberg data, slot and fill ?
Hi seth,
thanks 🙂
Currently I do not have further plans for more posts on this topic unfortunately. But there are also other great posts and talks out there already.
For example Josh Pollocks “Redux(-like) State Management In And Around WordPress”
https://joshpress.net/redux-like-state-management-in-and-around-wordpress/
Also Riad Benguella’s blog is a good source for Gutenberg development, like for example his article “Efficient client data management for WordPress Plugins”
https://riad.blog/2018/06/07/efficient-client-data-management-for-wordpress-plugins/
I understand why there is so much talk about blocks. Its a great concept with a scope which will impact WordPress and the way we will think about elements in WordPress for a long time. But while this discussion is a necessary one, customization for clients are often more than “give me a block”. I hope my talk helped to spread some information on other types of customizations, we will face with WordPress 5.0 coming up.
Thanks again for your kind words. Much appreciated 🙂
Hi david
I install your plugin but I get an error :
Parse error: syntax error, unexpected ‘:’, expecting ‘;’ or ‘{‘ in C:\wamp64\www\wordpress\wp-content\plugins\gutenberg-ink\src\Hooks\CoreHooks.php on line 22
Hi abigail,
thanks for your interest. This plugin needs to run on PHP 7+, could it be, you try to run it in an older PHP version?
Hi David
your presentation is awesome. I’ve leaned a lot in 30 mn.
I’ve just have one question : you say that everything that is inside PluginPostStatusInfo renders where the fills variable is
but if we create mutiple component (for exemple EditorPicks and EditorSelect ) how fills will know which one to choose ?
Thanks a lot severine.
I assume, you mean something like this?
const foo = () => {
return (
<PluginPostStatusInfo>
<p>
Foo
</p>
</PluginPostStatusInfo>
)
}
registerPlugin(‘foo-element’, {
render: foo
})
const bar = () => {
return (
<PluginPostStatusInfo>
<p>
Bar
</p>
</PluginPostStatusInfo>
)
}
registerPlugin(‘bar-element’, {
render: bar
})
Both components would populate the fills variable and get rendered.
All the best,
David.
Comments are closed.