Gutenberg is still in beta but developers are already getting ready for creating their own custom blocks. Over the weekend Ahmad Awais released a new project called Gutenberg Boilerplate For Third-Party Custom Blocks. Awais’ introductory post includes a rundown of his thoughts on the current pros and cons of developing for the Gutenberg project. Although he appreciates the technology behind Gutenberg and the improvements over shortcodes, he is not fully sold on the concept of putting everything into blocks. To learn more, he decided to jump into the code.
“I am still making up my mind with how Gutenberg will fit in the WordPress core,” Awais said. “There are so many things which are both good and bad about it. So, instead of ranting about it, I wanted to do something more productive. I went ahead, studied the source code and received a lot of help from Gutenberg contributors (Matias Ventura, James Nylen, Riad Benguella, Andrew Duthie, Joen, etc.) to finally build a Gutenberg Boilerplate project.”
Awais’ Gutenberg Boilerplate is a good starting place for learning more of the basics about developing for the editor. It comes in the form of a plugin that offers four examples of how to build different kinds of custom Gutenberg blocks, with and without a build process:
- A block with custom CSS for editor and front end
- A block with ES6 or ESNext and a Webpack build process
- A block with editable content
- A block to click Tweet the contents of that block
For example, the tweet block, which is something that might previously been handled with a shortcode, is an example that includes four files: block.js to register the custom Gutenberg block, editor.css, style.css, and index.php.
Awais noticed that many developers were wanting to try building third-party blocks, but Gutenberg’s documentation for this was outdated and/or non-existent. He got involved in contributing to the project’s documentation after discovering the docs describing how to enqueue block and block editor assets were not available. This gave him the inspiration to create a boilerplate.
“Both as a theme/plugin developer, I think there’s going to be a steep learning curve here for just about everyone – users as well as developers,” Awais said. “WordPress development just became very complicated with the Gutenberg project. I’m also not sure how devs will start writing extensions. Some users might expect them to keep the shortcodes for the old editor. Some might ask for blocks in the new one. Is there an API or back-compat? In short everything is changing and this change has both pros and cons.”
These concerns also tie into the larger discussion around how Gutenberg can support legacy metaboxes that use the old PHP framework, instead of updating to the new JS.
“New metaboxes should be written in JS, and will appear in the Post Settings sidebar alongside the stock ones,” Gutenberg contributor Joen Asmussen said. “Metaboxes written in PHP should ideally be upgraded to be JS, but should continue to work in their PHP form also.” Asmussen has proposed an “Extended Settings” panel to house legacy metaboxes in a section below the editor. It would appear only when legacy plugins and metaboxes are enabled, as shown in the mockup below.
Discussion regarding how to support metaboxes is still ongoing. With so many important issues like this up in the air, it’s too early to know what the future of extending Gutenberg will look like. At the moment, the project is undergoing rapid development and changes, so extending Gutenberg may evolve drastically over a short period of time. If the editor is to preserve the same flexibility and customization opportunities of its predecessor, the project will need to ensure that it is easy to create custom blocks and extensions while continuing to support older PHP metabox infrastructure that is currently widely used.
This is great. However, this kind of worries me:
This feels like something that should be defined by now by the project leads. Not implemented but things like “is there an API, is there backward compatibility” should be known even if something isn’t targeted as a 1.0 release feature.