Support for WordPress 5.0 and the new editor - Gutenberg

[bobbingwide]

Since early 2017 a new editor has been under development. Code named Gutenberg this new editor is being developed as a feature plugin. It is expected to be merged into core for WordPress 5.0.

We need to be aware of Gutenberg and to attempt to be compatible with it.
Actually, it's the other way round. Gutenberg needs to be backward compatible with us.

Area	Problem	Reference
Extended settings	Custom tags not being displayed	WordPress/gutenberg#4455

Expected output

The meta box for the Custom Taxonomy should be displayed correctly... somewhere

Actual output

The meta box for the Custom Taxonomy is displayed in the Extended section but there is no content, just the warning message.

Warning: call_user_func() expects parameter 1 to be a valid callback, 
function 'post_tags_meta_box' not found or invalid function name 
in gutenberg\lib\meta-box-partial-page.php on line 256

Problem explanation

• The warning message is produced because the Classic Editor logic has been bypassed
• Therefore wp-admin/includes/meta-boxes.php has not been loaded.

Proposed solution

My initial solution was a QAD fix, a change to the_gutenberg_metaboxes to load the missing file, adding the following code before the loop on $locations

	// All meta boxes should be defined and added before the first do_meta_boxes() call (or potentially during the do_meta_boxes action).
	require_once( ABSPATH . 'wp-admin/includes/meta-boxes.php' );

But this only stopped the Warning from appearing. The meta box did not operate correctly.

Better solution - the Gutenberg way

I then looked further and found WordPress/gutenberg#3369
I changed my custom taxonomy to have the show_in_rest property. My custom taxonomy was then listed under Tags. But it was still being shown in the Extended Settings.
I then looked further into gutenberg_filter_meta_boxes.
It appeared that the test coded as

// Filter out any taxonomies as Gutenberg already provides JS alternative.
if ( isset( $data['callback'] ) && in_array( $data['callback'], $taxonomy_callbacks_to_unset ) ) {
	unset( $meta_boxes[ $page ][ $context ][ $priority ][ $name ] );
}

failed to filter out the taxonomy because $data['callback'] has already been set to gutenberg_override_meta_box_callback.

I added the test that I believe it should be doing, looking at the $data['args']['__original_callback']

if ( isset( $data['args']['__original_callback'] )  
&& in_array( $data['args']['__original_callback'], $taxonomy_callbacks_to_unset ) ) {
  unset( $meta_boxes[ $page ][ $context ][ $priority ][ $name ] );
}

This change is an a PR against gutenberg issue 4455.

Still not fully working

With the fix for 4455, my custom taxonomy now displays, but my logic for automatically setting the taxonomy term based on the first letter of the post title or content either doesn't get invoked or the terms are not refreshed after the update.

[bobbingwide]

With the fix for 4455, my custom taxonomy now displays, but my logic for automatically setting the taxonomy term based on the first letter of the post title or content either doesn't get invoked or the terms are not refreshed after the update.

It's over a year since I noted that my logic wasn't working. Today I had another look. The basic problem is that the logic in oik_a2z_set_letter_taxonomies() checks for values in $_REQUEST which are not set when the post is being saved by the block editor. The taxonomy data is passed in HTTP_RAW_POST_DATA.
So rather than getting the terms for the taxonomy using

$tax_input = bw_array_get( $_REQUEST, 'tax_input', null );
$terms = bw_array_get( $tax_input, $data['taxonomy'], null );

we need to get them from the raw post data.

{"oik_letters":[],"status":"publish","content":"whatever","id":32157}

[bobbingwide]

The challenges are to:

1. Ensure the taxonomy terms are set automatically
2. Continue to support the classic editor
3. Continue to support the batch logic
4. Get the values back to the client

Proposed solution

1. Is easy - the test on $_REQUEST['tax_input'] or oik_a2z_is_cli() is no longer needed
2. Is easy - with a minor change to cater for deprecated messages; bw_posts.php replacing bw_posts.inc.
3. Is easy - the unchanged code will work as before
4. No idea how to do this yet.