Post context is not available to the `block_editor_settings_all` filter in the Site Editor

[ndiego]

Description

The block_editor_settings_all filter is a fantastic way to curate the Editor experience in WordPress. One of its parameters is $block_editor_context, which allows you to conditionally set various Editor settings based on the context, such as post type. However, in the Site Editor, the $block_editor_context just returns:

WP_Block_Editor_Context Object
(
    [name] => core/edit-site
    [post] =>
)

As more post types become editable in the Site Editor, we need a way to enable/disable Editor settings based on context within the Site Editor.

My hunch is that this will not be possible in PHP, and we will need a JavaScript method, which I think is possible, but I have not explored this fully. Therefore, I have labeled this issue as a Question rather than a Bug.

If anyone knows a rock-solid way to accomplish the code below in the Site Editor using JavaScript, please add the code in the comments, and I will update the Curating the Editor documentation.

Step-by-step reproduction instructions

Copy the following code into your theme's functions.php file.

function ece_restrict_locking_ui_with_context( $settings, $context ) {
    $is_page = $context->post && 'page' === $context->post->post_type;

    if ( $is_page ) {
        $settings[ 'canLockBlocks' ]         = false;
        $settings[ 'codeEditingEnabled' ] = false;
    }

    return $settings;
}
add_filter( 'block_editor_settings_all', 'ece_restrict_locking_ui_with_context', 10, 2 );

• Navigate to a page in the Post Editor and see that the locking UI and Code Editor is disabled.
• Navigate to a post in the Post Editor and see that the locking UI and Code Editor is enabled.
• Navigate to a page in the Site Editor and see that the locking UI and Code Editor is enabled. (Not what we want)

Screenshots, screen recording, code snippet

In the screenshots below, look closely and notice that the "lock" icon is disabled correctly in the Post Editor, but it's not disabled in the Site Editor.

Post Editor	Site Editor

Environment info

• WordPress 6.6
• Gutenberg trunk

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Mamaduka]

When bootstrapped, the site editor has no concept like the current post. Unlike the post editor, it can load or handle multiple entities at the same time.

[ndiego]

When bootstrapped, the site editor has no concept like the current post. Unlike the post editor, it can load or handle multiple entities at the same time.

Yeah, that's what I assumed. However, as more and more editing starts to take place in the Site Editor, we will need some sort of curation mechanism that mimics block_editor_settings_all, but in JavaScript that allows folks to easily modify the Editor settings based on the entity being edited. To my knowledge, we don't have this, but I would love to be proven wrong.

[ndiego]

@youknowriad @ntsekouras looping you both in since the new Posts dashboard is now available via a Gutenberg experiment and the following filter does not work there.

function example_restrict_locking_ui_with_context( $settings, $context ) {
    $is_post = $context->post && 'post' === $context->post->post_type;

    if ( $is_post ) {
        $settings[ 'codeEditingEnabled' ] = false;
    }

    return $settings;
}
add_filter( 'block_editor_settings_all', 'example_restrict_locking_ui_with_context', 10, 2 );

The Code Editor will be disabled in the normal Post Editor, but it's not disabled in the new Posts dashboard editor.

[youknowriad]

I think the $context property doesn't really make sense anymore and we need to find a way to move away from it. And PHP/JS is not the real dichotomy here but we need a clearer way to define these settings .

I think block_editor_settings_all should probably continue to exist as a way to define settings of the block editor regardless of the context and we need to look at the use-cases one by one for the rest.

For instance in the latest example if we want codeEditingEnabled to be a post type specific setting, we need to move it to the post type endpoint / registration (like we do for templateLock and template).

[ndiego]

I think the $context property doesn't really make sense anymore and we need to find a way to move away from it.

The $context property is a very powerful way to create curated editing experiences for different post types, and I've seen it used pretty regularly in the wild for all sorts of Editor settings.

It would be great if we could define Editor settings via post type endpoint / registration. That makes a lot of sense. Your curating functionality at the post type.

[youknowriad]

The $context property is a very powerful way to create curated editing experiences for different post types, and I've seen it used pretty regularly in the wild for all sorts of Editor settings.

I agree but what I'm saying is that it doesn't scale to where we want to take WP-Admin and the site editor. kind of like an SPA so we need to figure a more semantic/declarative approach and adding these properties to the post type registration seems like the way to go for me.

[ndiego]

kind of like an SPA so we need to figure a more semantic/declarative approach and adding these properties to the post type registration seems like the way to go for me.

Completely agree. It would be amazing if something like this could be implemented for 6.7 😉 This would be a huge win for folks working on adopting these new interfaces but have specific requirements for their clients/institutions.