Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List View: Explore hiding blocks #50756

Open
richtabor opened this issue May 18, 2023 · 6 comments
Open

List View: Explore hiding blocks #50756

richtabor opened this issue May 18, 2023 · 6 comments
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. Needs Design Feedback Needs general design feedback. [Type] Enhancement A suggestion for improvement.

Comments

@richtabor
Copy link
Member

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

hiding-blocks
@richtabor richtabor added [Type] Enhancement A suggestion for improvement. [Feature] List View Menu item in the top toolbar to select blocks from a list of links. Needs Design Feedback Needs general design feedback. labels May 18, 2023
@nekohayo
Copy link

nekohayo commented Aug 1, 2023

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 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
Copy link
Contributor

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
Copy link
Contributor

krokodok commented Sep 11, 2023

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

@jarekmorawski
Copy link

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
Copy link
Member Author

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
Copy link

WordCamp Presentation

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. Needs Design Feedback Needs general design feedback. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants