With the release of WordPress version 4.9.8 users will now be presented with the option to try out Gutenberg as a plugin, this is a significant step, and should be taken as a warning to prepare for its full and permanent implementation into WordPress as the primary editor.
What Is Gutenberg?
Gutenberg is a project focused on modernizing WordPress - specifically the editor experience. This shouldn't be taken as a cosmetic overhaul, as this intends to replace the current classic editor utilized for creating Posts and Pages. According to the Gutenberg FAQ TinyMCE will still be utilized, but within blocks, which can be thought of as movable objects within the new editor.
When Will Gutenberg Be Released?
As of December 6, 2018 - WordPress 5.0 Bebo has been released, making Gutenberg the defacto editor on WordPress applications.
What Will Pagely's Role Be in This?
As your managed web hosting provider, Pagely strives to keep all applications up to date, ensuring not only that the latest version is available to you, but is being utilized. There are a plethora of reasons behind this (security not being the least of them), but given the magnitude of this update we wanted to address some steps you can take to ensure compatibility in this article. In short, our role will be the same as its always been - to upgrade you to the latest version of WordPress as soon as it's safe and possible. Please see our plans for Rolling out Gutenberg here.
What Are Some Areas of Concern?
How Should We Test Our Application's Compatibility with Gutenberg?
A staging or development environment that is a direct clone of your production environment would be ideal. We suggest doing some heavy unit testing, perhaps using the block unit test plugin.
If you find issues that you don't believe you can resolve before Gutenberg release, you can try installing the Classic Editor Plugin which will replace the new Gutenberg editor with the old tried and true method. Alternatively, your developer may find the information below useful...
Custom Post Types
So far every custom post type we've tested has worked. In fact, your custom post type will default to classic editor unless the following lines exist in the post type registration...
// add custom route to WordPress API
'show_in_rest' => true,
/* supports with Editor en tandem with show_in_rest set to true is required for
Gutenberg to be enabled. Once that's done, you'll have access to both Classic
and Gutenberg. Editor alone without enabling rest API will default to classic
'supports' => array('editor')
If, for example, a Professor post type had the values above enabled you'd see something like this in the WordPress dashboard...
You should still proceed as if it this feature will not function until your test environment proves otherwise.
It should be noted that PHP meta boxes we've tested appear to be working, but are inconveniently pushed to the bottom when the Gutenberg Editor is active. It is the position of WordPress.org (as stated in their documentation below) that porting PHP meta boxes to blocks is "highly encouraged!"
Please read WordPress.org's Gutenberg handbook on meta-box extensibility. A general rule of thumb you should assume that if your theme or plugin modifies anything on the page/post editor screens you should test this out in a development environment. it is best to presume anything can and will break unless fully vetted first.
Where Can I Find Out More About Gutenberg?
About Advanced Custom Fields...
Originally we were not planning to reference any plugins directly, but we wanted to mention that the test application above did utilize Advanced Custom Fields. The troubleshooting steps taken above were to compensate (or be surprised by its compatibility) right out of the box. To reiterate, PHP metaboxes in most instances should display, but in an unseemly way - pushed towards the bottom of the Gutenberg editor page. Still, there are some specific use cases we were not able to test. These are discussed Further in the plugin author's site under the article "The state of ACF in a Gutenberg World".