Set $name on WP_Block_Editor_Context

[noisysocks]

What?

Compliments WordPress/wordpress-develop#2374 by configuring the Gutenberg plugin to set $name on WP_Block_Editor_Context wherever the plugin initialises an editor.

Why?

It's anticipated that WP_Block_Editor_Context::$name will land in WP 6.0. See WordPress/wordpress-develop#2374. It was added so that plugins can identify which editor they are customising when using filters such as allowed_block_types_all. See #28517.

How?

Passes 'name' to the constructor of WP_Block_Editor_Context. This is a safe no-op in versions of WordPress prior to 6.0
which won't have WP_Block_Editor_Context::$name.

Testing Instructions

Here's some code you can put into e.g. wp-content/mu-plugins/allowed-blocks.php:

<?php
add_filter(
	'allowed_block_types_all',
	function( $allowed_block_types, $block_editor_context ) {
		if ( 'core/edit-site' === $block_editor_context->name ) {
			return array( 'core/paragraph' );
		}
		if ( 'core/edit-widgets' === $block_editor_context->name ) {
			return array( 'core/heading' );
		}
		if ( 'core/customize-widgets' === $block_editor_context->name ) {
			return array( 'core/image' );
		}
		if ( 'core/edit-post' === $block_editor_context->name ) {
			return array( 'core/separator' );
		}
		return $allowed_block_types;
	},
	10,
	2
);

With the above plugin running, activate the plugin and navigate to Appearance → Editor. You should only be allowed to add a Paragraph block.

[noisysocks]

Updated the Navigation screen to use get_block_editor_settings which is the more canonical way to do this. Difficult to test though since the Navigation screen is mostly borked 😅

[noisysocks]

This one is tricky. Technically there's no screen at all since it's just a REST API endpoint. I did some digging and this endpoint is used by the mobile apps for Global Styles (#29063), so I think using core/edit-site makes sense.

[talldan]

Is this the same thing as the 'site' entity?

gutenberg/packages/core-data/src/entities.js

Lines 28 to 36 in 5f265e9

	{
	label: __( 'Site' ),
	name: 'site',
	kind: 'root',
	baseURL: '/wp/v2/settings',
	getTitle: ( record ) => {
	return get( record, [ 'title' ], __( 'Site Title' ) );
	},
	},

edit: Oh, no, different namespace.

[talldan]

Feels like it probably shouldn't have a name, or the name should be passed as a param to the REST request.

[noisysocks]

Is this the same thing as the 'site' entity?

It's not, no. I can't see anywhere where this endpoint is being used but I assume from the issue (#29063) that it's used by the mobile app somehow.

[noisysocks]

Feels like it probably shouldn't have a name

Yeah maybe name needs to be optional after all 😕

[gziolo]

@geriux worked on the mobile integration so he might be the best person to share recommendations here.

[geriux]

I can't see anywhere where this endpoint is being used but I assume from the issue (#29063) that it's used by the mobile app somehow.

That's correct, this is currently used on the WordPress mobile app to load the global styles data.

[geriux]

In regards to the name, the one that's currently set core/edit-site doesn't affect the response data we need so that works.

[noisysocks]

Thanks for confirming @geriux.

I looked at #29969 more closely and realised that this endpoint already has a 'context' param which we can use to set $context->name correctly! Done in e739e41.

[talldan]

This and the wordpress-develop PR (WordPress/wordpress-develop#2374) look good to me 👍

[noisysocks]

Thanks everyone. https://core.trac.wordpress.org/changeset/52942 committed the Core component of this. We may as well get these changes in Gutenberg, though they'll be a no-op if Gutenberg is not running against latest Core trunk.