BlockInspector: Conditionally render Inspector Control Tabs depending on Write Mode

[yogeshbhutkar]

Fixes: #67129

What?

This PR resolves a bug that causes block controls to be displayed when both "Show Template Mode" and "Write Mode" are enabled. In this scenario, the controls should not be visible, and the block should remain non-editable, as "Write Mode" is specifically intended for creating content.

How?

The Inspector Controls were conditionally rendered to stay hidden when viewing with Show Template Mode and Write Mode enabled, thereby preventing the user from updating the Block.

Testing Instructions

1. Create a post.
2. Inside the edit post screen, toggle the display type to the template and select the content block. Observe the absence of editing the block attribute options.

Screencast

Screen.Recording.2024-11-20.at.3.14.14.PM.mov

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: yogeshbhutkar <[email protected]>
Co-authored-by: dhruvang21 <[email protected]>
Co-authored-by: richtabor <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[dhruvang21]

I tested this PR in the Gutenberg PR reviewer, and it works perfectly for the write mode and when the "Show Template" option is active. However, with this condition, the inspector controls are not displayed in any mode. Ideally, these controls should be visible in design mode to allow layout editing.

That said, I noticed that even in the trunk, the inspector controls are not shown when design mode is activated. I’ve attached a video of the testing process below for reference.

67149.mp4

[yogeshbhutkar]

Hi, @dhruvang21, and thanks for testing the PR. I noticed this as well, but the code in this PR is not related to that bug and this PR was to address a slightly different issue. I feel a separate issue should be created regarding this bug as it's present in the Trunk and should be patched in that issue.

[richtabor]

Showing or hiding the tabs is a second-order effect of having the content block selectable. My issue is geared towards making the editor feel the same between post and site editing experiences. In my opinion the post content block should not be selectable when it's not editable. It should likely be the same experience as when you're editing in the post editor today.

[yogeshbhutkar]

Hi @richtabor,

Thank you for reviewing the PR.

To make the parent Post Content block unselectable, one approach is to remove it entirely from the block tree, similar to how it's handled in the generic post editor. However, this approach presents challenges.

The Post Content block serves as a container that holds all inner blocks together. Removing it from the root and displaying its inner blocks directly in its place might seem to work initially, but it complicates the application of styles. Specifically, applying styles solely to the inner container becomes problematic without a defined wrapper like the Post Content block.

In my opinion, retaining the Post Content block—or a similar container block—is essential to ensure proper structural integrity and styling of its inner blocks.

Also, the previous proposed solution of hiding the controls seems like the best bet for this at the moment.

Looking forward to hearing your thoughts!

[richtabor]

The Post Content block serves as a container that holds all inner blocks together. Removing it from the root and displaying its inner blocks directly in its place might seem to work initially, but it complicates the application of styles. Specifically, applying styles solely to the inner container becomes problematic without a defined wrapper like the Post Content block.

In my opinion, retaining the Post Content block—or a similar container block—is essential to ensure proper structural integrity and styling of its inner blocks.

I think it should work just like the post editor today, where it's not selectable.