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
You must be logged in to post a comment.