-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create batch routine to set the preferred editor ( _oik_block_editor ) #20
Comments
The current status of the report for post 1 in my qw/wordpress environment is
Script required once: oik-block-opinions.php So now I need to implement |
…add_opinions. Mandatory now shows as M (true), O (false)
…o suport multiple output formats. Add site level reset for decisions
… level: site, type, post and user (future )
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.
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. |
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
In the absence of this setting we’ll refer to the 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 |
I've downloaded the latest CSV extract and stored it in |
Here are some pie charts summarising the current status from the plugin compatibility database. Multiple interpretations are possible:
What we don't know is the number of plugins where the status is currently actively addressed means one or more of the following
This is the case with most of my plugins. |
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:
This is due to the way Workaround
Proposed solution
|
Here's the latest Site level analysis for
Explanation:
We can resolve the issue for oik-user by updating its readme.txt file with "Tested up to: 4.9". |
Another way of checking plugin compatibility is to look internally into the code. It might be possible to detect this |
Gutenberg v4.0.0 makes WordPress 4.9.8 a pre-requisite. |
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
Opinions
An opinion helps us decide which editor to use.
There are three types, two of which may be 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.
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 |
The text was updated successfully, but these errors were encountered: