In my first post about the new block editor for WordPress, code named Gutenberg, I commented on the apparent absence of an implementation plan. I was also acutely aware that I didn’t have a plan either. So, since then I’ve been attempting to:
- Evaluate Gutenberg’s compatibility with my sites.
- Estimate effort to develop solutions for my plugin customers.
- Estimate effort to ensure peaceful coexistence.
- Estimate effort to migrate each site to WordPress 5.0.
Note: Most of my work is associated with shortcodes and meta boxes for custom post type’s fields, so this is the focus for my analysis and proposed development.
Current status – April 2018 – TL;DR
- Gut feeling: 33% compatible
- Develop solutions: 200 days
- Peaceful coexistence: 1-2 days per site/sub-site
- Actual migration: As yet unknown
Gutenberg compatibility – Gut feeling
“Gut feeling” is my attempt to estimate Gutenberg’s compatibility with my site’s content and code. Having considered possible problem areas I then determine the likelihood that implementing Gutenberg will require careful consideration. The resulting Gut feeling consists of 3 percentages, which can be represented in a pie chart.
- 33% Compatible – content safe to edit using the block editor.
- 19% Need work – content will need some attention before it can be safely edited.
- 48% Classic – content has to be edited using the Classic editor.
Above figures based on an analysis of 63,000 posts in 14 sites.
Gut feeling for a brand new install
By comparison a brand new install would be
How the figures were calculated
The evaluation process is semi-automated, using new code developed as part of the
For each site determine the total number of editable posts, by post type, and the editor that would be used to edit them. Here are the results for
Ensure as many as possible of the Editable post types are enabled for the REST API ( i.e. each CPT and its associated taxonomies needs to have
show_in_rest=>true ), activate Gutenberg (if not already active), then run the routine to analyse the compatibility of the content.
Accumulate the summary results for each site in a spreadsheet. Create as many pie charts as you feel necessary.
Over time, as you learn more about the potential pitfalls and how to form opinions about them, improve the routines that perform the analysis, re-consider, and adjust the Gut feeling accordingly. The latest results obtained for
qw/bigram , which show very low compatibility, are explained in the following sections.
Analysis routine – oik-block-opinions.php
This batch routine forms opinions about which Editor would be the most suitable for editing content. It works at multiple levels: Site, Type and Post. For each editable post the decision is stored with meta_key
oik-block plugin provides a Preferred Editor meta box which displays for each editable post the Opinions and the Decision. A Mandatory opinion overrules an Optional opinion. Even though the Decision is shown as Mandatory the user may still be able to choose which editor to use.
Here are the results for the
bigram post: ID 2984
In this example, the fact that the
s-word taxonomy has 941 terms and that I’ve marked this as a Mandatory opinion, is what sways the program to recommend using the Classic editor. What the program doesn’t know is that the
s-word taxonomy terms are automatically generated and that there’s only one per post. In a future version this particular opinion may not be Mandatory, or it may only be applied to hierarchical taxonomies ( i.e. categories ).
Clearly, the need and value of each Opinion can be questioned. We don’t really need to see the Optional opinions; some are just comments after all. Anyway, you get the idea… After all, for the analysis we are just trying to put a value to a gut feeling. And for the meta box we’re trying to be proactive.
Effort to develop solutions for customers
I haven’t developed automated tests for all the risks I envisaged but have at least been able to obtain actual figures for my site’s content and Gutenberg’s current ability to deal with it. So now I have some idea what I need to develop to cater for the posts which need attention.
Ignoring for a moment the current limitations of the Gutenberg plugin’s ability to deal with more than 100 of anything, and its niggling usability and performance issues, my biggest concern is that migrating existing content to blocks may cause the front-end display to appear broken.
One in five of my existing posts could be a problem.
However, so long as I don’t need to do anything with the existing content other than display it, I’ll probably be all right. The same is true for my client’s sites, and the sites on which my shortcode / meta box related plugins are being used.
But how will my customers know when it’s safe to install Gutenberg? I can’t answer that question yet since I only know about the plugins and themes that I have installed and activated.
What I can do is to test each of my plugins and, where I find a problem, raise an issue, then prioritise, plan and develop solutions for each issue.
For shortcode related work, I intend to develop blocks that can protect the user from the underlying complexities of the shortcodes. The new blocks will continue to use the existing shortcode functionality, but will have an easier to use User Interface.
I’ve identified about 70 shortcodes that would benefit from being converted to blocks. I can only guestimate how long it’s going to take to develop a block for each shortcode. To date I’ve developed 10 prototype blocks in my new plugin
oik-block. It’s taken quite some time to get this far. I think it’s going to take a while to complete the task.
The current estimate is 200 days.
I have yet to analyse meta box related issues.
Effort to ensure peaceful coexistence with Gutenberg
The process I’m following at present is this.
For my own sites, I have a local development copy. Migration involves
- Upgrade site to WordPress 4.9 or higher
- Upgrade plugins and themes to latest available versions
- Perform stand up test
- Install and activate Gutenberg and the Classic-editor plugin
- Install and activate oik-block
- Run my routine to get a Gut feeling
- Test for obvious problems
- For any problem found
- If the problem is with a third party plugin / theme then consider deactivating, unless the plugins functionality is mandatory.
- If the plugin is mandatory then determine whether or not it’s a known issue and is being worked on.
- If the problem is with my plugin/theme then raise an issue, prioritise and plan to develop a fix / workaround.
- If the problem is with content then attempt to fix the content.
- If unresolved problems remain consider Gutenberg to be incompatible with the site and ensure that the problems are documented as known issues.
Note: For WordPress Multisite installations each sub-site needs to be evaluated separately.
For my client’s sites.
- Clone the production version to a local copy.
- Same process as above.
Current estimate is: 1-2 days per site/sub-site.
Effort to migrate to WordPress 5.0
This is still very much an unknown. Gutenberg is not ready to be merged into core. And when it is, there are likely to be many changes as it gets merged. Some of those changes will require me to make changes to my changes. The same will apply to third party plugins.
The best we can do is to continue to keep an eye on the changes and re-evaluate the position regularly.
In the mean time, I have bitten the bullet and installed Gutenberg on this blog. This post makes use my new block called
For more information on the
oik-block plugin please see the repository: bobbingwide/oik-block.
Gutenberg and the Classic-editor can both be downloaded from wordpress.org.