Size Change: +1.84 kB (+0.09%)

Total Size: 1.95 MB

_{compressed-size-action}

Flaky tests detected in ff7a8d5.
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/18160190902
📝 Reported issues:

• [Flaky Test] should duplicate and activate #71988 in /test/e2e/specs/site-editor/template-activate.spec.js

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: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: sunyatasattva <sunyatasattva@git.wordpress.org>
Co-authored-by: mukeshpanchal27 <mukesh27@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: supernovia <supernovia@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

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

Nice work. I just shared some mockups in the main issue, which instead of dimming/overlaying the hidden block, actually hides it. In my comment I acknowledge the pros and cons to doing that, but since you already have a PR ready, I'm wondering if actually testing out the theory with something real isn't the best way to help decide. Beyond surfacing the potential need for focus handling, my hope is it'll make the behavior very obvious and intuitive in a way that opens up future opportunities. What do you think?

Working well thus far :) Thanks for all your efforts here. It's interesting to try this with inner blocks/container blocks. I think we can learn a lot from block locking here in terms of UX:

which instead of dimming/overlaying the hidden block, actually hides it.

I'd suggest that both would actually be useful (also commented something to that effect in the issue):

• Dimming/overlaying to make it obvious to the editor user which blocks are hidden and where. (or at least some non-annoying and unobtrusive way for a user to map out all hidden block locations in the block tree)
• A toggle for hiding all/individual blocks in the editor to show a preview of what the frontend would look like

Future compatibility with breakpoints or other variables can be left open if we keep the data structure flexible, though @t-hamano has already thought about this.

Oh, I don't know, something like:

<!-- wp:paragraph {
	"metadata":{
		"blockVisibility": [
            {
				"type": "breakpoint",
				"value": "var:preset|breakpoint|small",
			}
          ],
	}
} -->
...

Ok, let's stabilize the feature with this PR. I made the following changes:

• bb9ec37: Stabilize feature
• 4c7338c: Submit a core backport PR and add a backport changelog
• 861689c: Add missing block support checks on the server side
• 0929559: Use visibility:hidden to visually hide blocks. I believe this is a more fundamental approach and the block toolbar seems to work fine.

This is the current state:

I have to admit, I preferred the 0 height one quite a bit. Could we have made that also 0 width to address Dan's good note?

Not suggesting this as a blocker. I think the PR should land. But I'd like, if possible, to not entirely close the door on the collapsing, because for the moment, it's still collapsing when you deselect the block, so it's arguably more confusing now than when at least the block appeared to be removed from the flow (which is the case on the frontend).

One thing I notice when testing is that some transforms might not retain the block visibility, others do

Ah, I think this problem is related to this issue:

• Block Transforms: Need to explicitly include metadata when creating block #71922

This issue will likely occur with any blocks that extract only specific attributes and call createBlock within the transform property's callback function.

We may need to fix this in a follow-up so that all three metadata attributes (name. blockVisibility, and commentId) are not lost.

I have to admit, I preferred the 0 height one quite a bit.

I agree. Fixed in 96428fd

Could we have made that also 0 width to address Dan's good note?

I tried it, but since blocks in the editor are horizontally centered, the toolbar movement can be annoying:

I'll try to find a better approach to hiding selected blocks in a follow-up.

Potentially can default to height: 0, and look at is-layout-flex on whether it should instead be width: 0. I imagine it's more complex than that but wanted to share.

Potentially can default to height: 0, and look at is-layout-flex on whether it should instead be width: 0. I imagine it's more complex than that but wanted to share.

Another issue I spotted with both width: 0 and height: 0 is that the sibling block inserter tries to match the width of the hidden block in a vertical layout, and it looks noticeably strange. Maybe there are ways to solve that (e.g. by not trying to reference the hidden block's width, but the nearest visible block instead).

Another issue I spotted with both width: 0 and height: 0 is that the sibling block inserter tries to match the width of the hidden block in a vertical layout, and it looks noticeably strange. Maybe there are ways to solve that (e.g. by not trying to reference the hidden block's width, but the nearest visible block instead).

Yes, I'm investigating this...

I understand what the ideal behavior here would be, but I haven't yet figured out how to technically achieve all of the following:

• We can't apply display:none in order to render the block toolbar. We need to render some element.
• For vertical layout, the height should be set to 0 and the width should match the adjacent block.
• For horizontal layout, the width should be set to 0 and the height should match the adjacent block.
• Make sure the in-between inserter is displayed properly.

I want to briefly pause and thank you for your work. It's been inspiring, it's been great.

Then I want to echo that this is solid work, I think it should land. To me it even feels 6.9 ready. Now whether we implement the visibility or the opacity change as you had earlier and land this, then explore height/width/collapsing separately, I'll defer to you all. To be very clear, I think it's an important value add, worth pursuing. But I also don't think it is required for the first iteration to land, especially as the block really does truly disappear when you deselect the block. That feels the main constraint.

How about this?

(⊃｡•́‿•̀｡)⊃━☆.*･ magic

Thanks for the great work on this one @t-hamano 🫶

I am thinking that one can use this feature to add multi language features.
Creating the content in one language and duplicating the blocks and changing it to another language.
Using code to show language in use with a button or flag and hiding the other language.