As of WordPress 6.9, you can hide any block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. entirely withย blockVisibility: falseย in block metadata. In WordPress 7.0, viewport-based visibility rules give your users the power to show or hide blocks per device type โ desktop, tablet, or mobile โ without affecting other viewports.
Controls are available in the block toolbar, block inspector sidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., and command palette to launch the block visibility options modal. In List View, blocks with active visibility rules show icons that indicate which viewports they are hidden on.
Note: Blocks hidden by viewport areย rendered in the DOM.ย The hiding happens in the CSS Cascading Style Sheets..
Thatโs different fromย blockVisibility: false. That keeps the block from rendering in the DOM, thus it canโt ever show on the front end.
Updatedย blockVisibilityย metadata structure
The existing hide-everywhere behavior has NOT changed:
{
"metadata": {
"blockVisibility": false
}
}
But in WordPress 7.0, a newย viewportย key gives you and your JSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.-literate users finer control, per breakpoint:
{
"metadata": {
"blockVisibility": {
"viewport": {
"mobile": false,
"tablet": true,
"desktop": true
}
}
}
}
Theย viewportย key is deliberately nested, leaving room for more sources (e.g., user role, time-based rules) to come in 7.1 and beyond.
The three supported viewport keys areย mobile,ย tablet, andย desktop. In 7.0 these map to fixed breakpoints, but you can expect configurable breakpoints andย theme.jsonย integration in WordPress 7.1 โ seeย #75707.
Hereโs how this all looks in serialized block markup:
<!-- wp:paragraph {"metadata":{"blockVisibility":{"viewport":{"mobile":false}}}} -->
<p>Hidden on mobile.</p>
<!-- /wp:paragraph -->
How to get your theme or plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. ready
Does your theme or plugin generate, transform, or parse block markup server-side? Then itsย blockVisibilityย metadata field might now contain a boolean (false) or an object ({ viewport: { ... } }). If your code assumes a scalar value, youโll want to update it to handle both forms.
Blocks and patterns that include hardcodedย blockVisibilityย metadata will work out of the box, and so will your reusable blocks that have visibility rules.
If your blocks donโt interact with markup on the server
Then you donโt have to do anything! Viewport visibility is part of theย blockVisibilityย block support and applies automatically. You donโt need a separate opt-in inย block.json.
Coming soon! To a future release near you
Current plans call for configurable breakpoints andย theme.jsonย integration for block visibility to land in WordPress 7.1. At that point, youโll be able to let your themes and other products define almost any viewport labels and breakpoints you need, far beyond the fixed mobile/tablet/desktop defaults. Followย #75707ย for progress.
Props to @andrewserong and @marybaum for helping to write this dev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..
References
#7-0, #dev-notes, #dev-notes-7-0