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 <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: ramonjd <[email protected]>
Co-authored-by: talldan <[email protected]>
Co-authored-by: sunyatasattva <[email protected]>
Co-authored-by: mukeshpanchal27 <[email protected]>
Co-authored-by: jasmussen <[email protected]>
Co-authored-by: annezazu <[email protected]>
Co-authored-by: supernovia <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: jameskoster <[email protected]>

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",
			}
          ],
	}
} -->
...

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.

Hide a block in the frontend is really useful and much loved by my trainees, when using Plugins like Greenshift (predefined CSS Class hide_onfrontend => display:none) or Block Visibility.
But the main effect oft this tools is to hide the block ONLY in the frontend and NOT in the editor too.
The regular use-case is: “Allows draft or placeholder content to stay visible in the editor but hidden from site visitors.”

But the actual Gutenberg & Beta 1 tool hides the block ALSO in the editor!
So, to work as described with a draft, you have to

1. unhide a hidden block
2. edit it
3. rehide it
4. save the post.
   (And never forget step 3 before each saving!) – That’s a workflow from hell, but nothing I would use by myself or recommend to my trainees.
   Additional, in the editor, you can’t never see what you have written in ALL invisible blocks and must make them visible one by one to see your own content. (And, by god, don’t forget to make them invisible again afterwards before next saving!)

Suggestions:
1.) Follow your own target declaration and make the block invisible ONLY in the frontend.
2.) If you want some extra, mark such a block in the editor, e.g. with a special wireframe or an icon, which declares its invisible frontend status at a glance.
3.) If there is no quick solution to make this feature useful, remove it from the upcoming WordPress release.

Block visibility manager of some sort should be in Gutenberg, yes. However, current implementation looks questionable, imo.

• as per Why? - "Sometimes users may want to edit blocks in the backend without affecting the frontend, for example, a section that is not yet ready to be published." - how users are supposed to do that, if block gets hidden in the Editor? Unhide it, edit it, then if it's still not final, hide it again and save the post? Basically, keep hiding and unhiding it while doing the edits?
• How useful is hide/show option with no conditional settings? Basically, it only allows users to "draft" blocks without affecting the frontend and not much else. I've been using Gutenberg in production since 2019 and I could count on my fingers the times I needed plain hide/show block functionality with no conditional settings. Usually, when I need to manage block visibility, I need to tie it to some sort of conditional state like user role, query string, screen size, or so.
• Now it's saved into attributes.metadata.blockVisibility, are there any other visibilities planned to be saved in metadata except block visibility? Isn't block in attribute name a bit redundant? I mean, block label is saved into attributes.metadata.name not attributes.metadata.blockName, so why not just use attributes.metadata.visibility for visibility? :)

I'm extensively using https://github.com/ndiego/block-visibility plugin for managing block visibility state. Plugin seems to be really solid, open-source, somewhat easy to extend. It also allows not only basic show/hide but also a lot of other different options to manage the visibility (by query strings, screen sizes, user roles, etc.). I wished core Gutenberg implementation could borrow some ideas from a plugin like this :)

@burnuser @enodekciw Thanks for the feedback.

Follow your own target declaration and make the block invisible ONLY in the frontend.
If you want some extra, mark such a block in the editor, e.g. with a special wireframe or an icon, which declares its invisible frontend status at a glance.

how users are supposed to do that, if block gets hidden in the Editor? Unhide it, edit it, then if it's still not final, hide it again and save the post? Basically, keep hiding and unhiding it while doing the edits?

There is a discussion about this here: #71203 (comment)

In many design tools, hiding a layer actually makes that layer disappear. If you want to edit a layer, you need to explicitly show that layer. Also, in order to see how it will ultimately be displayed on the front end, the block needs to be hidden in the editor as well. That's my understanding, but I agree that there are certainly many steps involved in editing the content of a hidden block.

How useful is hide/show option with no conditional settings? Basically, it only allows users to "draft" blocks without affecting the frontend and not much else. I've been using Gutenberg in production since 2019 and I could count on my fingers the times I needed plain hide/show block functionality with no conditional settings. Usually, when I need to manage block visibility, I need to tie it to some sort of conditional state like user role, query string, screen size, or so..

I think this needs to be carefully considered based on various user feedback. This is because it is difficult to remove a feature once it has been added. We have a responsibility to ensure full backward compatibility.

Now it's saved into attributes.metadata.blockVisibility, are there any other visibilities planned to be saved in metadata except block visibility? Isn't block in attribute name a bit redundant? I mean, block label is saved into attributes.metadata.name not attributes.metadata.blockName, so why not just use attributes.metadata.visibility for visibility? :)

One reason is to avoid confusion with the CSS property "visibility". See #50756 (comment)

I'm extensively using https://github.com/ndiego/block-visibility plugin for managing block visibility state. Plugin seems to be really solid, open-source, somewhat easy to extend. It also allows not only basic show/hide but also a lot of other different options to manage the visibility (by query strings, screen sizes, user roles, etc.). I wished core Gutenberg implementation could borrow some ideas from a plugin like this :)

I'm also aware of that plugin. We can consider which ideas to incorporate as part of future enhancements.

If you have any specific ideas about what kind of feature enhancements are needed, we would welcome you to submit a new issue.