Add option to hide blocks

[richtabor]

To complement #33583, it would be interesting to have a way to hide a block within the editor, which results in the block not rendering on the front end.

If we could visually hide a block in the editor, and stop it from rendering on the front end, designers could lay out a couple iterations of an idea—turning on/off various groups—instead of various process hacks to exploring today.

Some ways I achieve this now are to leverage the undo button (or copy/hold in the clipboard)—but it only goes so far. Otherwise, I've ended up creating reusable blocks of ideas I don't want to loose, or random pages with groups of blocks on them. Not ideal.

Proposal

Consider having a hide/show control available within List View, that shows up with the same conditions as the block options control that's already in place. When toggled on, that block does not render within the editor or the frontend of the site.

Visual

[nekohayo]

In conjunction with configurability in the block properties sidebar, this would also be very useful for:

• The ability to create content that shows up only on some device formfactors or screen sizes (ex: only on mobile, only on desktop, etc.), i.e. FEATURE REQUEST: Display / Hide Blocks on Specific Devices #41518 ; in my experience, this is extremely useful for contents/elements that cannot fit on mobile, or that are too heavy (would consume too much data and slow down loading), or that mobile users may not have the patience to look at on the go.
  • The ability to hide blocks when the save-data network client hint / HTTP header is used / indicated by the web browser
• The ability for teams to prepare contents ahead of time within a published page, and turn it on only when appropriate (ex: during a registration period for a workshop, class, or any type of event or limited-time thing).
  • Bonus points if we could also have the ability to set a schedule (ex: certain times/days of the week, or a start/end date and time, etc.) that would automatically show/hide the blocks, like what the block visibility plugin (see also their website) allows
• The ability to show/hide based on various filtering criteria (ex: categories/tags taxonomies, etc.). For example, one could easily batch-tag a bunch of blog posts to show a standard block/group or not, for whatever reason, instead of needing to go toggle things on/off in every post/page...
• "Ponies on rainbows" idea: Ideally too, this could even open up some API possibilities in the future, for example for a particular block to be shown/hidden based on some criteria like whether the user is logged in or a visitor, whether a particular product is in stock or not in plugins like WooCommerce, but that part of the featureset is probably less trivial and less-frequently-used than the above ideas.

Of course there is the tricky part where when a condition changes internally (ex: date/time change) you may need to tell the caching plugins (such as the WP Super Cache plugin) to invalidate their cache for a particular page...

Yeah sure, there's the aforementioned "Block Visibility" plugin out there in the meantime, but it would be architecturally cleaner to have it as a built-in Gutenberg feature, and also it would be better for long-term viability instead of running into plugin problems…

[draganescu]

I explored this a bit and it seeme achiveable by adding a system attribute (hidden) which causes the block edit to not render and the block render callback to skip the block via a render callback hook.

Skipping the rendering of the block edit keeps the block in the list view.

For static blocks we can use [getSaveElement](https://developer.wordpress.org/block-editor/reference-guides/filters/block-filters/#blocks-getsaveelement) to skip saving these hidden blocks.

[krokodok]

Love this idea! I think I would need it every week somehow. Really miss it in comparison to other CMS.

[jarekmorawski]

Yes, please! This would be a fantastic improvement that would enable a more flexible pattern/block design. For instance, in the product gallery pattern in Woo, we'd bundle a few extra blocks that may not necessarily be part of the basic design, like product name, ratings, share buttons, etc. To achieve this right now, we'd have to build a separate block and add extra visibility settings in the inspector.

Hiding blocks would simplify the structure (we'd rely on templates and template parts, not individual blocks) and help us surface different block configurations using more interesting/opinionated pattern layout variations.

[richtabor]

It could potentially be an option you turn on within editor preferences; as it's more of a builder flow than an everyday user flow.

[Sirjazzfeetz]

WordCamp Presentation

All for hiding items on list "view", for granular view control.

[annezazu]

Coming back to this to bring in @ndiego Block Visibility plugin's approach. Try it here in this Playground Demo.

block.visibility.mov

Renaming this so it's not just about List View but about hiding blocks in general.

[westonruter]

Related: Core-63676. When a block is hidden from the frontend, it's CSS and JS should not get enqueued.

[Drivingralle]

Like the idea to have something like that in core.

Building it in a way so plugins can extent it for use cases like @nekohayo describes would be great

[patric-boehner]

I know it's just a mockup of the idea and that this may not be the proposed UI. But looking at the icons, I would suggest not going with the closed eye icon to represent hidden. It looks nice, but I think many users would find it confusing. It only makes sense in the context of the open eye icon. Something like the eye with a slash that core already uses for password visibility might be better. Anyway, just an initial thought.