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: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: fcoveram <fcoveram@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>

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

Flaky tests detected in 702b322.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17844419243
📝 Reported issues:

• [Flaky Test] correctly applies dynamic allowed blocks restrictions #51220 in /test/e2e/specs/editor/plugins/inner-blocks-allowed-blocks.spec.js

This seems good to me, and I agree this behaviour should be the default.

Agree that this looks good. My first reaction was that removing the image made no sense, as the grid layout prioritizes the visual content to compose the layout. However, I can envision use cases where other fields also compose to the layout.

That said, I think that adding a reset action at the end of the properties list could help to go back to the default state. I assume this idea involves defining which visible properties those are.

Thanks for confirming and for the feedback, folks!

That said, I think that adding a reset action at the end of the properties list could help to go back to the default state. I assume this idea involves defining which visible properties those are.

I think that'd be possible, as it'd be a matter of resetting the view back to its default state of visible fields. Let's leave that out of this PR as it's a little beyond the scope of ensuring folks don't get stuck when hiding all fields.

After chatting with @oandregal and with the feedback here that we'd like this to be default behaviour, I've removed the flag.

I've also updated the logic so that in cases where there are no visible locked fields, we then add smart locking to the last remaining visible field. This is a bit of an edge case as usually there is at least one title, media, or description field, but helps us ensure that no-one ever gets stuck in a state where no field is visible.

For testing that case, I've added a diff to the PR description that includes a separate story that doesn't include the title, media, or description fields. Since it is a bit of an edge case, I haven't included that story as part of this PR, but let me know if anyone thinks it should be included.

Thanks again for all the discussion here, everyone!

Thanks for the review!

Though, I still think most views are expected to lock special fields. Even if this mode, users can still run in weird situations like this one for the grid layout:

Good point. I think we're getting there in terms of providing a good / safe default. For these last cases, would it be worth revisiting / dusting off #71231 for handling the case when the media preview is hidden? And to be thorough about it, would we want a similar behaviour for when the description is hidden?