¿Se pueden ocultar bloques WordPress según el tamaño de pantalla o dispositivo? Pero sin plugins, por favor

Ocultar un bloque en móvil y que se siga viendo en escritorio era una de esas cosas que WordPress debería haber tenido desde hace años. Hasta ahora necesitabas un plugin como Block Options, o andarte con clases CSS a mano, para conseguir algo tan básico, pero WordPress incorpora la visibilidad por tipo de dispositivo desde la versión 7.0.

La nueva funcionalidad se llama Block Visibility y permite ocultar cualquier bloque por tipo de dispositivo (escritorio, tablet o móvil) directamente desde el editor, sin instalar nada. También mantiene la opción de ocultar un bloque por completo, que ya existía desde WordPress 6.9, eso no cambia, pero ahora todo se gestiona desde el mismo sitio.

Te cuento cómo funciona, y también la parte técnica qué necesitas saber si desarrollas temas o plugins.

Índice de contenidos

Cómo ocultar un bloque por dispositivo

Selecciona el bloque que quieras ocultar y abre el menú de opciones (los tres puntos de la barra de herramientas o clic derecho). Verás una opción nueva, Ocultar (Hide en inglés), con el atajo de teclado ⇧⌘H en Mac.

Al pulsar en ese enlace del menú se abre una pequeña ventana emergente con las opciones de visibilidad:

Omitir del contenido publicado: oculta el bloque por completo. No se procesa en el HTML de la página, así que nadie lo ve en ningún dispositivo. Es lo mismo que hacía blockVisibility: false en WordPress 6.9.
Ocultar en escritorio: oculta el bloque en pantallas de escritorio.
Ocultar en tableta: oculta el bloque en tabletas.
Ocultar en móvil: oculta el bloque en móviles.

Puedes marcar las combinaciones que necesites. Por ejemplo, si quieres que un bloque solo se vea en móvil, marcas «Ocultar en escritorio» y «Ocultar en tableta».

Indicadores en la vista de lista

Cuando un bloque tiene reglas de visibilidad activas la vista de lista del editor muestra iconos junto al nombre del bloque indicando en qué dispositivos está oculto. Viene bien para no perder la pista de qué has ocultado y dónde.

Vista previa en el editor de bloques

Por ir terminando, la comprobación de esta funcionalidad es sencilla, solo tienes que cambiar a la vista previa integrada en el editor de WordPress de un dispositivo que hayas ocultado para comprobar que no se ve, y a más, por supuesto, puedes comprobar en la web que no se verá si cambias el tamaño de pantalla.

Las tripas: CSS en vez de no renderizar

Aquí hay una diferencia importante que conviene tener clara y es que cuando marcas «Omit from published content» el bloque directamente no se incluye en el HTML de la página. No existe en el DOM, no se carga, no aparece en ningún sitio. Esto es lo que ya hacía WordPress 6.9 con blockVisibility: false y sigue funcionando exactamente igual.

Cuando ocultas por dispositivo (desktop, tablet, mobile), la cosa cambia: el bloque sí se renderiza en el DOM. Lo que hace WordPress es aplicar reglas CSS con media queries para ponerle un display: none en los viewports que hayas seleccionado. El contenido está ahí, simplemente no se ve.

Esto tiene implicaciones prácticas. Si ocultas una imagen pesada en móvil con esta funcionalidad, el navegador del móvil sigue descargando la imagen aunque no la muestre. Para casos donde el rendimiento es lo que te preocupa, la opción de «Omitir del contenido publicado» o el enfoque clásico con render_block y wp_is_mobile() siguen siendo mejor opción.

La estructura técnica: metadatos del bloque

La visibilidad se guarda en los metadatos del bloque, dentro de la clave blockVisibility. La estructura ha cambiado respecto a WordPress 6.9, que solo admitía un booleano.

Ocultar un bloque por completo sigue siendo igual:

{
  "metadata": {
    "blockVisibility": false
  }
}

La novedad es que ahora blockVisibility también puede ser un objeto con una clave viewport:

{
  "metadata": {
    "blockVisibility": {
      "viewport": {
        "mobile": false,
        "tablet": true,
        "desktop": true
      }
    }
  }
}

En este ejemplo, mobile: false significa que el bloque no se muestra en móvil. Los valores true o la ausencia de la clave significan que sí se muestra.

La clave viewport está anidada a propósito dentro de blockVisibility. La idea es que en futuras versiones se puedan añadir más criterios de visibilidad al mismo nivel (por ejemplo, por rol de usuario o por franjas horarias), sin romper la estructura actual.

En el markup serializado del bloque, queda así:

<!-- wp:paragraph {"metadata":{"blockVisibility":{"viewport":{"mobile":false}}}} -->
<p>Este párrafo no se ve en móvil.</p>
<!-- /wp:paragraph -->

Los breakpoints actuales

WordPress 7.0 usa tres breakpoints fijos:

Móvil: pantallas de hasta 480px de ancho.
Tableta: de 480px a 782px.
Escritorio: más de 782px.

Estos valores están definidos tanto en PHP (lib/block-supports/block-visibility.php) como en JavaScript (packages/block-editor/src/components/block-visibility/constants.js) y, al menos de momento, no se pueden cambiar ni desde theme.json ni desde ningún filtro.

El punto de corte de 782px te sonará si has trabajado con el admin de WordPress, que usa ese mismo valor para su diseño responsive. El de 480px coincide con los breakpoints de los estilos base de Gutenberg. No son valores especialmente estándar fuera de WordPress (muchos frameworks usan 768px para tablet), pero son coherentes con el resto del ecosistema.

Qué necesitas saber si desarrollas temas o plugins

Si tu tema o plugin genera, transforma o analiza markup de bloques en el servidor, ojo: el campo blockVisibility en los metadatos del bloque ahora puede ser dos cosas distintas. Hasta WordPress 6.9 era siempre un booleano (false). Desde WordPress 7.0 puede ser un booleano o un objeto con la estructura de viewport que acabamos de ver.

Si tu código asume que blockVisibility siempre es un valor escalar, va a petarte cuando se encuentre con un objeto. Revisa y adapta.

Si tus bloques no tocan el markup en el servidor, no tienes que hacer nada. La visibilidad por viewport es un block support que se aplica automáticamente. No hace falta declarar nada en el block.json de tus bloques.

Lo mismo se aplica a patrones y bloques reutilizables, de manera que si ya tienen reglas de visibilidad guardadas funcionan sin tocar nada.

Adiós a los plugins de visibilidad por dispositivo

Plugins como Block Visibility, EditorsKit o Conditional Blocks han hecho un trabajo estupendo cubriendo esta carencia durante años, pero si lo único que necesitabas era ocultar bloques por tipo de pantalla, a partir de WordPress 7.0 ya no necesitas ninguno de ellos para esta funcionalidad.

Ahora bien, si usas características más avanzadas de esos plugins (visibilidad por perfil de usuario, por fechas, por geolocalización, por parámetros de URL), esas cosas siguen sin estar por defecto en WordPress y vas a seguir necesitándolos. WordPress 7.0 solo cubre el caso de visibilidad por viewport, que es el más común y el que más gente pedía.

Y un detalle para quienes vengan de EditorsKit es que si lo desactivas las clases CSS que el plugin añadía a los bloques ocultos siguen estando en tu contenido. Los bloques volverán a mostrarse porque el CSS que los ocultaba ya no se carga.

La funcionalidad nativa de WordPress 7.0 usa un sistema diferente (metadatos del bloque, no clases CSS), así que no hay migración automática. Si tienes bloques ocultos con EditorsKit y quieres pasar al sistema nativo tendrás que reconfigurar la visibilidad bloque a bloque.

Lo que falta y lo que viene en WordPress 7.1

La funcionalidad de WordPress 7.0 es intencionalmente limitada. Se lanzó con lo mínimo para que funcione bien, y el plan es ampliarla en la próxima versión mayor.

Para WordPress 7.1 está previsto:

Breakpoints configurables desde theme.json: que cada tema pueda definir sus propios puntos de corte y etiquetas de viewport, en lugar de estar limitado a los tres valores fijos actuales.
Control por tipo de bloque: que los temas puedan activar o desactivar la visibilidad por viewport para bloques concretos, igual que ya se hace con otros block supports como color o tipografía.
Integración con el style engine: ahora mismo la propiedad CSS display necesita un workaround con el filtro KSES para funcionar. En 7.1 debería gestionarse de forma nativa.

También hay debate abierto sobre si usar media queries de viewport es el enfoque correcto o si container queries serían más apropiadas para bloques individuales. Y sobre el formato de las media queries, que ahora usan la sintaxis moderna de rangos (width <= 480px) en lugar del clásico max-width.

Si te interesa seguir el desarrollo, el issue #75707 en GitHub es donde se está coordinando todo lo de WordPress 7.1. Y la nota oficial de desarrollo de WordPress 7.0 tiene los detalles técnicos de lo que ya está funcionando.