I had a client once—let’s call her Sarah—who ran a high-traffic WooCommerce shop. She was constantly running these flash sales, but she hated deleting her promotional content every time a promo ended. She just wanted to hide WordPress blocks until the next sale cycle. At the time, I spent more hours digging through database revisions to restore her “lost” content than I did actually developing new features. Total nightmare.
My first instinct back then was to just give her a custom CSS class. I told her to add “hidden-section” to the block settings and I wrote a quick display: none; in the stylesheet. It worked for her visually, but it was a lazy fix. Here is the kicker: the browser was still loading the assets, the images, and the scripts for those “hidden” blocks. On a site with 20k products, every extra byte counts. Trust me, it wasn’t pretty.
A Better Way to Hide WordPress Blocks
Thankfully, the WordPress 6.9 update finally introduced a native way to hide WordPress blocks without the performance overhead. This isn’t just some CSS trick. When you hide a block in the editor now, it is completely omitted from the rendered HTML on the frontend. This is huge for performance. It means no extra DOM elements, and more importantly, no unnecessary scripts or styles being enqueued for content that isn’t even there.
I was digging through the dev notes over at make.wordpress.org/core/2025/12/01/ability-to-hide-blocks/ and the implementation is solid. It leverages the standard Block API. To use it, you just select a block, hit the ellipsis menu, and choose “Hide.” If you prefer the keyboard, Ctrl + Shift + H (or Command on Mac) does the job. To find them again, you just look for the “Hidden” icon in the List View. Simple. Effective.
But here’s the thing: sometimes you don’t want your clients having that kind of power. If they accidentally hide a critical container block or a structural element, your support inbox is going to blow up on a Saturday morning. Because this is a standard support flag, we can actually opt blocks out of this feature using a simple filter.
function bbioon_disable_block_visibility_support( $metadata ) {
// Disable visibility support for the core/group block to prevent accidents.
if ( isset( $metadata['name'] ) && 'core/group' === $metadata['name'] ) {
$metadata['supports']['visibility'] = false;
}
return $metadata;
}
add_filter( 'block_type_metadata', 'bbioon_disable_block_visibility_support' );I tried this on a staging site yesterday for a client who kept “disappearing” their header rows. It works perfectly. The “Hide” option just vanishes from the menu for that specific block type. It’s about creating a “pit of success” for the client—making it hard for them to break things while giving them the tools they actually need.
The Performance Payoff
The real takeaway here is the performance benefit. In the past, “hiding” meant hiding from the eye but not the engine. Now, with the way 6.9 handles asset loading, you aren’t penalized for having dormant content in your pages. If a block is hidden, its associated assets are omitted from the page load. That’s how it should have been from day one.
Look, this stuff gets complicated fast, especially when you start mixing visibility with conditional logic or complex layouts. If you’re tired of debugging someone else’s mess and just want your site to work efficiently, drop my team a line. We’ve probably seen it before.
Are you going to let your clients manage their own block visibility, or are you locking it down for structural safety?
Leave a Reply