Create batch routine to set the preferred editor ( _oik_block_editor )

[bobbingwide]

As part of the project to estimate the effort to migrate to the new block editor ( Gutenberg ) I want to analyse the existing content of a subset of my websites.

For each post that can currently be edited using the Classic editor, and which can therefore potentially be edited using the Block editor, I want to determine the preferred editor. This value will be set in post meta data keyed by _oik_block_editor.

The Preferred Editor meta box ( see #18 ) will provide the end user view of the setting for each post.

Requirement

We need a batch routine that can work through the many thousands of posts in the subset of sites.
It needs to be able to set the value for each post, and produce a summary report on the current status of the site.

It will be possible to complete the estimation stage of the project when the routine has analysed all the posts that we will allow to be edited using the Block editor.

The first stage is to determine the preferred editor for the post types that do already support the Block editor - posts and pages. We'll deal with pages first since these are more likely to have been lovingly constructed and will be edited in the future.

In the 10 sites that have been summarised, the total number of posts and pages is approximately 5% of the editable content. Media is 5.2%; non-editable content accounts for 1.0%.
The rest ( 88.9% ) represent custom post types which are not currently REST enabled.

Proposed solution

• Batch routine to work through each post by post type
• Restartable
• Rerunnable
• wp-cli support
• WPMS support
• Extendable logic for evaluating "opinions"
• summary report to produce figures to enter into a spreadsheet to determine the final "Gut feel"

Opinions

An opinion helps us decide which editor to use.
There are three types, two of which may be mandatory.

Type	Mandatory?	Meaning
A	n/a	Any / ambivalent - either editor can be used
B	n	Block editor preferred
B	Y	Block editor mandatory
C	n	Classic editor preferred
C	Y	Classic editor mandatory

Examples of each type are shown below.

Multiple opinions can be stated, but only one preferred editor value can be set at any time.
We’ll have to find a way to deal with differing mandatory opinions.

Opinions can be set at multiple levels: site (S), post type (T), post (P) and user (U) or combinations of levels.
The value stored in post meta data should not reflect the user’s opinion.

Type	Mandatory	Level	Test	Optional action
C	Y	T	post type not show_in_rest	Set post type to show_in_rest
B	n	P	post already contains blocks
B	Y	PU	post contains dynamic blocks and Visual editor disabled
C	n	T	post type supports author and > 100 authors
C	n	T	a taxonomy contains > 100 settings
C	n	T	page attributes > 100 pages
C	Y	T	Incompatible meta box
C	Y	S	Incompatible plugin / theme
B / C	n	S	Site preference
B / C	n	U	User preference

If a test does not produce B or C then the opinion is Ambivalent.
We may choose to hide ambivalent opinions.

A | n | T | post type is show_in_rest |

[bobbingwide]

The current status of the report for post 1 in my qw/wordpress environment is

Processing post ID: 1
Post: 1. Type: post
oik_block_site_opinions
oik_block_type_opinions
oik_block_post_opinions

Editor	Mandatory?	Level	Opinion	Notes
A	O	S	WordPress 4.9.4 is Block editor compatible.
A	O	S	Block editor available
A	O	T	REST API enabled
A	O	T	can_edit_post_type is enabled
A	O	T	Taxonomy is show_in_rest
A	O	P	Content does not contain blocks

Script required once: oik-block-opinions.php
Did: run_oik-block-opinions.php

So now I need to implement consider_opinions()!

[bobbingwide]

To analyse plugins, whether they're activated or not, we can consider checking the "Tested up to" setting in the readme.txt file for each plugin.

Tested up to	Opinion
lt 4.9	Incompatible - ie. CM
4.9.x	No opinion - see the Compatibility database
ge 5.0-alpha	Consider the plugin/theme compatible ie. AO

We can't do this for MU plugins so we'll assume it's OK. However, we could implement some filter processing to determine which plugins are compatible and this could be applied to MU plugins as well.

[bobbingwide]

Re plugin compatibility. I don’t yet know how to obtain results from the plugin compatibility database so will have to implement an interim solution for my local environments. The plugin evaluation, performed at Site level, will attempt to obtain the Gutenberg compatible: status for each plugin and accumulate the opinions into a single Mandatory opinion, which will then be used to influence the overall decision. Daniel Bachhuber’s compatibility database suggests multiple values for the Gutenberg compatible setting, which we’ll map to Opinions as below

Gutenberg compatible	Opinion
No	CO
Yes	AO
Likely-no	CO
Likely-yes	AO
Testing	AO
Unknown	AO

In the absence of this setting we’ll refer to the Tested up to: tag, to determine a Likely-no or Likely-yes or Unknown value. The previous table will need to be updated.

It would also be nice to know if any development work is being done for the plugin to resolve compatibility issues from the plugin’s end, rather than Gutenberg’s. We’ll use Testing for this.

[bobbingwide]

I don’t yet know how to obtain results from the plugin compatibility database

I've downloaded the latest CSV extract and stored it in opinions/plugincompatibility.csv This will be used to determine the first opinion for a plugin. I'll make the plugin's readme.txt value trump the extract. Some solutions will be needed for the plugins that aren't in the list.

[bobbingwide]

Here are some pie charts summarising the current status from the plugin compatibility database.

Multiple interpretations are possible:

1. Only 17% of the plugins have been analysed - so more work needed
2. Of those analysed 7% of the plugins are / may not work with Gutenberg
3. 8% of sites using one of the top 300 plugins ( > 100k installs ) will / may fail to operate correctly with Gutenberg.

What we don't know is the number of plugins where the status is currently No or Likely-no where the issues are being actively addressed and new versions are in the pipeline.

actively addressed means one or more of the following

• Issue(s) have been raised on Gutenberg
• Issue(s) have been raised on the plugin's repository
• Work is in progress to ensure peaceful coexistence either in Gutenberg or the plugin or both

This is the case with most of my plugins.
Note: 90% of my plugins are not in wordpress.org.

[bobbingwide]

My logic to analyse plugin compatibility based on "Tested up to:" and two ways of obtaining a value for "Gutenberg compatible:" doesn't cater for plugins where the main plugin file name is different from the plugin's folder.

Examples:

plugincompatibility name	plugin file
hello-dolly	hello.php
beaver-builder-lite-version	beaver-builder-lite-version/fl-builder.php
wordpress-seo	wordpress-seo/wp-seo.php

This is due to the way bw_get_active_plugins() ( an oik function ) works.
bw_get_active_plugins attempts to caters for multiple plugins within a plugin directory.
There are not many plugins that do this.

Workaround

• Update the plugin compatibility csv file

Proposed solution

• Use a different function than bw_get_active_plugins

[bobbingwide]

Here's the latest Site level analysis for qw/cwiccer showing the summary of reportable opinions for plugins

Editor	Mandatory?	Level	Opinion	Notes
A	O	S	WordPress 4.9.5 is Block editor compatible.
A	O	S	Block editor available
C	O	S	Likely incompatible plugins	Incompatible: 0, likely: 2, total: 10
C	O	S	Plugin: oik-user GC: , CO,
C	O	S	Plugin: fl-builder GC: , CO,

Explanation:

• No information could be found in the plugin compatibility database for oik-user or fl-builder.
• oik-user is not on wordpress.org
• oik-user was determined to be likely-no => Likely incompatible based on its "Tested up to" setting, which was 4.9-beta3
• fl-builder was not found due to plugin name issues explained above.

We can resolve the issue for oik-user by updating its readme.txt file with "Tested up to: 4.9".

[bobbingwide]

Another way of checking plugin compatibility is to look internally into the code.
The classic editor invokes hooks and filters in a certain way
The block editor changes that way.
There's an issue to document the changes.
It should be possible to build routines that determine if plugins attach functions to the hooks that are changing.
If the hook is no longer being invoked OR hooks are being invoked in a different sequence to expected there could be a problem.
As a test, let's see if we can detect an issue with hello-dolly, or any plugin that responds to the 'replace_editor' hook, or help hooks or screen option hooks.
I'll raise a separate issue for this.

It might be possible to detect this

[bobbingwide]

Gutenberg v4.0.0 makes WordPress 4.9.8 a pre-requisite.