Gutenberg: Sidebar doesn't appear when selecting a block inside a Reusable Block

[OksanaRomaniv]

Describe the bug
Before the update, when you select a block inside the reusable block, it's settings would show in the sidebar under the "Block" tab. Now the tab is empty. This issue isn't there is a block isn't reusable, but a regular block.

To reproduce
Steps to reproduce the behavior:

1. Create 2 group blocks with paragraphs in them
2. Make one block reusable.
3. Select block inside regular group and see the settings of the block in the sidebar.
4. Click "edit" on the reusable group.
5. Select the paragraph block
6. See empty sidebar on the right or reusable group settings (don't know on what this depends, but it's either way and isn't consistent).

Expected behavior
The inner block of the reusable block have settings on the right sidebar when selected

Screenshots
block settings in a simple group
block settings in a reusable group
block settings in a reusable group v2

Desktop (please complete the following information):

• OS: Ubuntu 18.04
• Browser: Chrome 78
• Version : WP 5.3

[draganescu]

I can confirm this as a bug, or at least unexpected behavior:

In the screenshot above there is a list block selected inside a reusable block and the inspector does not show the properties of the list as it would be expected.

[draganescu]

I don't know if this has gotten worse or it was like that from the beginning when this bug was signaled. Searching how to debug, I found that you can actually see the controls for a block in a reusable block by:

1. Clicking edit on the reusable
2. Click the desired block
3. Clicking on the reusable again

However the problem is that after 3 selecting another block in the reusable crashes the editor.

[themightymo]

I'm also experiencing this issue.

• WP 5.4
• Google Chrome Version 80.0.3987.163
• Pressable (nginx)

[chrisvanpatten]

Looks potentially related to #19436.

[noisysocks]

My guess is that the sidebar can't tell that the block is selected because that selection state is in the reusable block's registry, not the main post's registry.

[noisysocks]

I'm adding [Priority] High here since there were quite a few duplicate issues which suggests that many users are running into this problem.

Note though that there is a workaround: you can view the sidebar when you edit the reusable block via _Manage all reusable blocks_.

[OksanaRomaniv]

I also stumbled upon the same behavior when using BlockEditorProvider, WritingFlow and BlockList in a custom block. The content blocks of the custom editor don't render the settings in the sidebar.

[elliotcondon]

Hi all. Confirming that the issue still exists using WordPress 5.4.2 (with and without the latest Gutenberg plugin).

The screen-recording posted by https://github.com/WordPress/gutenberg/issues/18560#issuecomment-604920204 sums up the problem quite well. Something is going wrong when selecting a block within a Reusable block.

Has any progress been made since April?

[youknowriad]

The path forward here is to use the controlled inner blocks approach for reusable blocks (like template parts).

[elliotcondon]

@youknowriad Thanks for the reply, but I'm a little confused.

Can you please take a moment to watch in full the screen recordings on this page. They both describe the issue well - which is that when editing the content within a reusable block, it is not possible to edit any properties via the sidebar.

[youknowriad]

@elliotcondon The fact that the reusable blocks as written today are basically an editor inside an editor makes it "impossible" to show the properties on the sidebar because at any moment in time, we have "two selected" blocks, one in the outer editor (the reusable block core/block) and the one inside the reusable block editor. In the sidebar we should the properties of the outer selected block.

With a Controlled InnerBlocks (like the template part block), you only end up with a single selected block as all blocks are now part of the same editor.

[johnstonphilip]

I think I may have found an approach that works as a workaround that does not require using innerBlocks here. If you add a "focusoutside" handler to detect any clicks outside BlockEditorProvider, you can run clearSelectedBlock, which then deselects that block. That gets around the toolbar showing in places it shouldn't. However, you would also need to add another <BlockInspector /> for the block-editor inside reusable blocks to see your sidebar controls.

Note that in order to target the right data store (since both share the core/block-editor name), you need to place a handling component inside BlockEditorProvider. That component might look something like this:

function ThisEditorActions(props) {

    // This gives us access to the "right" core/block-editor store, because this component lives inside the BlockEditorProvider.
    const { clearSelectedBlock } = useDispatch( 'core/block-editor' );

    function handleOutsideFocus() {
        if ( props.focusedOutside ) {
            clearSelectedBlock();
        }
    }

    return (
        <>
            { handleOutsideFocus() }
        </>
    );

}

[chrisvanpatten]

I think what we have in #23601 is still our best solution to this, but we're stuck until #22639 is resolved. It looks like #24180 had some discussion from @youknowriad and @noahtallen last week that seems to be moving toward consensus on a solution, so hopefully we can be in a good position to merge #23601 in the near future!

[noahtallen]

seems to be moving toward consensus on a solution

It would be very helpful to get more feedback on that PR! The code itself is not ready for review, but hopefully there is enough commentary to understand the exact issue at hand. It's fairly complex, so there are tradeoffs to many of the possible solutions. We need to come to a technical consensus before moving forward with code, I think.