Gutenberg has been the hot topic of WordPress for quite a while now, and mostly in a controversial way. It’s no secret that there’s been a lot of backlash against the idea of Gutenberg over the past many months, mainly from plugin developers and development companies that have for years relied on page builders and/or metaboxes to build user interfaces for their customers. And in a way, I understand the fears and worries that a lot of people have. It is natural to be phased by change, especially if this change will cost you time and money to re-analyze and re-write the way your plugins and process work.
Page Builder Plugin Users
If you are one of many people using some of the popular page builder plugins, then you will need to make some changes to the way your WordPress sites are set up, once Gutenberg is released in WordPress core. Page Builder plugin providers such as SiteOrigin, Beaver Builder and Elementor have already announced their plans for Gutenberg integration. Elementor has announced that they are rebuilding their plugin from the ground up, with not much detail as to how it will work with Gutenberg. SiteOrigin has been very active with their community about their plans, and they have showcased tutorials and videos of how SiteOrigin’s plugin will integrate with Gutenberg.
It would be a very good idea for you to immediately get familiar with how your Page Builder plugin will adapt with Gutenberg, as this directly impacts how you create your pages, whether you’re a developer, designer or a content editor.
Post Meta & Custom Fields
The other type of users that will get impacted by this is those who use post meta or custom fields plugins to create content within posts. The WordPress metabox and post meta are widely used for various applications, plugins and themes. Using post meta and custom fields, developers have been creating all sorts of form fields, that allow users and clients to edit content easily, adjust layouts, select sidebars, widgets and much more. With the Gutenberg approach, a lot of that will have to evolve into Gutenberg Blocks. Developers should already be looking into building Gutenberg blocks for their plugins and themes.
Custom Post Types
Since Gutenberg relies on the REST API, developers can easily disable Gutenberg from impacting their Custom Post Types by ensuring that show_in_rest is not set to true. This maintains the exact same look and feel that you’re familiar with for your CPTs.
All Aboard the Gutenberg Train
Whether you are a content writer, editor, site designer, plugin developer or a frontend developer, Gutenberg is most likely going to impact you to a certain level. If you are running a business which is based on WordPress, upgrading your plugins and themes to be integrated with Gutenberg is not a small cost. It requires time to learn the how-to, come up with a new process then re-build. The simple approach many developers are thinking is “I will just programatically turn off Gutenberg”. Sure that works, but for how long ? and to what purpose ?
Gutenberg will pave the path for a whole new generation of possibilities in WordPress, focused on flexibility and improved user experience. I encourage anyone who has not looked into Gutenberg, to do so right away. There’s no point in waiting till after it’s released to get familiar with it. The plugin is available on WordPress.org, and there are some great tools that will help you build your first Gutenberg block.
Lastly, if you are one of many developers who are married to jQuery but want to get into modern ES6 or React, Gutenberg is easiest way to do so. With the help of toolkits such as create-guten-block, you can create a “Hello World” block in a few minutes. This toolkit takes away the headaches of the set up, so you can simply focus on writing some JS that will create blocks.