Greetings, fellow WordPress enthusiasts! Welcome to part 2 of our “Preparing for Gutenberg” blog series. In our last post, we talked about what Gutenberg is and why it’s coming. Now, we’ll dive a little deeper and inspect how the introduction of Gutenberg will affect your current website.
Preparation is necessary
The main critique surrounding Gutenberg, as of now, is that it’s going to become a part of WordPress core. That means that in due time, everyone on WordPress is going to have to adopt Gutenberg. You could, of course, wait to update your core files, but that may leave you vulnerable to security risks.
Teams with experienced developers might be comfortable with putting off core updates, but most likely you’re going to end up on Gutenberg. So, how will it affect what you already have on your website?
Blocks for everyone
For basic websites that use the classic editor to house their content (like blogs, for example), the transition should be relatively painless. What Gutenberg will do is convert all of your text and media into a single HTML block. From there, you can either edit that block as HTML or convert all the content into separate blocks. Gutenberg will detect different paragraphs and components and treat them as their own block, giving you more control over the content structure in the backend.
The good thing is that while content will appear differently in the backend, it will still look the same to front-end users, regardless if you leave it as an HTML block or split it to separate blocks. So, there isn’t necessarily a need to go back into your existing content and make changes.
What about advanced custom fields and custom post types?
Things get a little more complicated for more robust websites that utilize custom post types and the ever-popular advanced custom fields (ACF) plugin. Unfortunately, Gutenberg won’t work with ACF right out of the box. However, there are some solutions to make sure your content won’t break.
One option is to code something that would understand your existing ACF or CPT data. By setting up a system for Gutenberg to read the metadata, you would ensure that all of your content appears correctly on the frontend. Another alternative is to set up a block template that lays out a list of blocks when you create a new post or page. You can “lock” templates so that blocks can’t be added or removed, or leave them unlocked to allow for more flexibility. This essentially creates the same benefit as custom field plugins – structuring the appearance of post data. Riad Benguella made a simple plugin and video demonstrating this exact process.
Stick with the classic
For website managers and developers who want to update WordPress core but still don’t want to use Gutenberg, there’s an option for you too. WordPress contributors are working on a beta build of a “Classic Editor” plugin, which restores the text editor to the one we all know and love. We’ll have to wait and see how well it actually performs when Gutenberg is out.
So, what do I need to do?
When you update WordPress core to 5.0 (and inevitably install Gutenberg), website maintenance will come down to what types of content you have. For simple blogs or websites that contain most of their content in the default text editor, you shouldn’t see any issues on the frontend. You’ll notice that Gutenberg will turn your content into an HTML block, but you only need to touch it if you want to organize the content in the backend. For those of you using ACF or CPT, you’ll likely need the help of a developer to allow Gutenberg to understand your metadata. And if you simply want to update core but not use Gutenberg at all, you can install the classic editor plugin, but beware that there will probably be bugs in the early stages.
What’s the best way to approach these possible problems? Check back for our next and final post which will outline exactly that!