Construyendo sistemas de diseño escalables en WordPress con Gutenberg 2026

Un sistema de diseño en WordPress es el conjunto de tokens, controles permitidos en el editor y layouts insertables que Gutenberg va a aplicar de verdad. Un archivo de Figma no obliga a nada en el sitio publicado. En 2026 ese contrato son theme.json versión 3, la carpeta /patterns y unos pocos bloques propios. Todo lo demás es un prototipo o un objeto en la base de datos, y conviene tratarlo como tal.

El fallo se repite en los sitios editoriales grandes: el manual de marca vive en Figma, el CSS vive en cinco hojas de estilo y el editor sigue ofreciendo un selector de color libre. Marketing publica entonces un hexadecimal de campaña que existe en una sola landing. La campaña siguiente lo copia. Seis meses después nadie sabe cuál es el verde de la marca. Gutenberg puede impedirlo, pero solo si apaga esos controles y pone la paleta en theme.json.

Esto no es un sermón sobre migrar desde un maquetador. Si está eligiendo entre Gutenberg, Elementor o Divi, lea la comparativa de maquetadores de 2026. Si duda entre un tema de bloques y un tema clásico en PHP, lea temas clásicos frente a temas de bloques. Este texto trata la capa posterior a esa decisión: cómo se mantiene coherente el sistema cuando los editores entran al insertador todos los días.

#Cómo configurar theme.json versión 3 para un sistema de diseño

La especificación viva es theme.json versión 3. La introdujo WordPress 6.6: la entrada del WordPress Developer Blog sobre estilos de sección indica que el esquema de la versión 3 solo está soportado en WordPress 6.6 y posteriores, o con el plugin Gutenberg sobre un núcleo más antiguo. Los archivos con version: 2 siguen cargando. Los ajustes nuevos aterrizan en la versión 3. En esa especificación no existe una versión 4, por mucho que lo repitieran tantos resúmenes de 2025.

Apunte el archivo al esquema que corresponde a la versión mínima de WordPress que soporta, no a trunk, salvo que el sitio corra siempre el plugin Gutenberg:

{
  "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
  "version": 3,
  "settings": {},
  "styles": {}
}

settings es lo que el editor tiene permitido hacer. styles es el aspecto por defecto cuando nadie sobrescribe un bloque. Mezclar ambos es la forma en que los equipos acaban publicando, sin querer, un valor por defecto bonito que el editor puede romper con un clic.

Para un sitio que tiene que mantenerse dentro de la marca, el primer bloque settings que escribimos tiene este aspecto. Cierra los selectores libres de color, tamaño de fuente y espaciado, y a cambio da al editor escalas fijas:

{
  "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "custom": false,
      "customDuotone": false,
      "customGradient": false,
      "defaultPalette": false,
      "defaultGradients": false,
      "defaultDuotone": false,
      "palette": [
        { "slug": "base", "name": "Base", "color": "#ffffff" },
        { "slug": "contrast", "name": "Contraste", "color": "#111111" },
        { "slug": "primary", "name": "Primario", "color": "#0b3d91" },
        { "slug": "accent", "name": "Acento", "color": "#c2410c" }
      ]
    },
    "typography": {
      "customFontSize": false,
      "dropCap": false,
      "fontSizes": [
        { "slug": "small", "name": "Pequeño", "size": "0.875rem" },
        { "slug": "medium", "name": "Medio", "size": "1rem" },
        { "slug": "large", "name": "Grande", "size": "1.5rem" },
        { "slug": "x-large", "name": "Extra grande", "size": "2.25rem" }
      ]
    },
    "spacing": {
      "customSpacingSize": false,
      "defaultSpacingSizes": false,
      "spacingSizes": [
        { "slug": "20", "name": "XS", "size": "0.5rem" },
        { "slug": "30", "name": "S", "size": "1rem" },
        { "slug": "40", "name": "M", "size": "1.5rem" },
        { "slug": "50", "name": "L", "size": "2.5rem" },
        { "slug": "60", "name": "XL", "size": "4rem" }
      ]
    }
  }
}

color.custom: false es el antiguo add_theme_support( 'disable-custom-colors' ). defaultPalette: false esconde las muestras grises y azules del núcleo, de modo que el selector enseñe solo sus slugs. La correspondencia está en el manual de Global Settings and Styles. Si esos dos flags se quedan en su valor por defecto (true), no tiene un sistema de diseño. Tiene una sugerencia.

customSpacingSize: false elimina el campo de espaciado libre, y defaultSpacingSizes: false impide que el núcleo añada su propia escala de espaciado junto a la suya. Ambas claves figuran en settings.spacing dentro de la referencia viva, al lado de spacingSizes y spacingScale.

appearanceTools: true no es un interruptor de bloqueo. La referencia viva enumera lo que activa: imagen y tamaño de fondo; color, radio, estilo y grosor de borde; colores de enlace, encabezado, botón y pie de imagen; relación de aspecto, altura, altura mínima, ancho mínimo y ancho; posición sticky; separación entre bloques, margen y padding; e interlineado. Actívelo cuando el trabajo de layout deba hacerse en el editor. Déjelo apagado, o fije las claves una a una, cuando quiera que el espaciado salga solo de los presets.

#Cómo convierte Gutenberg los presets de theme.json en variables CSS

Cada slug de la paleta se convierte en una propiedad personalizada --wp--preset--color--{slug} y en clases de utilidad como .has-{slug}-color y .has-{slug}-background-color. Los tamaños de fuente y de espaciado siguen --wp--preset--font-size--{slug} y --wp--preset--spacing--{slug}. Esa nomenclatura está en el mismo manual. El CSS propio del tema debería usar esas variables, y no un segundo juego de tokens --brand-primary que acabará divergiendo.

Los valores que no tienen un tipo de preset, como profundidades de sombra o radios de esquina a los que quiera dar nombre, van en settings.custom. El manual documenta que cada clave de ahí se convierte en una propiedad --wp--custom--{key}, con las claves anidadas unidas por un doble guion. Una hoja de tokens pequeña para el ejemplo anterior queda así en el CSS generado:

/* Presets de settings.color.palette y settings.typography.fontSizes */
--wp--preset--color--primary: #0b3d91;
--wp--preset--color--accent: #c2410c;
--wp--preset--font-size--large: 1.5rem;

/* Presets de settings.spacing.spacingSizes */
--wp--preset--spacing--30: 1rem;
--wp--preset--spacing--40: 1.5rem;

/* De settings.custom: { "radius": { "card": "8px" } } */
--wp--custom--radius--card: 8px;

Eso es todo lo que hay detrás de los design tokens en Gutenberg. WordPress no importa Tokens Studio: emite presets a partir de theme.json. Si el equipo de diseño ya tiene sus tokens en JSON, el pipeline honesto es un paso de build que escriba settings.color.palette (y las escalas de tipografía y espaciado) dentro de theme.json. El despliegue envía entonces un solo archivo. Un webhook desde Figma que “empuja a producción” sin esa escritura es una demo, no un sistema.

#Cómo dividir theme.json en un sitio grande

Los temas hijo fusionan su theme.json sobre el del padre. Las variaciones de estilo viven como archivos JSON adicionales en /styles. PHP todavía puede retocar el árbol con el filtro wp_theme_json_data_theme cuando un sitio de la red necesita otro primario sin bifurcar el tema. Esas tres divisiones son lo que ofrece el núcleo. Compilar doce parciales JSON en una tarea de Node está bien si su equipo ya mantiene esa tarea. No es obligatorio, y no está documentado como funcionalidad de WordPress.

Cuando un equipo elige la vía de la compilación, la estructura suele ser esta:

theme/
├── theme.json            (generado, en el repositorio)
├── config/
│   ├── color.json
│   ├── typography.json
│   ├── spacing.json
│   └── custom.json
└── build-theme-json.js   (fusiona config/ en theme.json)

Diseño, desarrollo y marketing pueden así editar cada uno sus archivos sin conflictos de merge sobre un único documento JSON enorme. El coste es que el script de fusión pasa a ser código que alguien tiene que mantener, probar y actualizar cuando cambia el esquema.

#Cómo cambiar de paleta con variaciones de estilo sin CSS nuevo

Una paleta alternativa no necesita una segunda hoja de estilos. La vía del núcleo es una variación de estilo: un archivo JSON en /styles que redefine los mismos slugs. El propietario del sitio la elige en el Editor del sitio, dentro de Estilos, y todos los bloques que ya consumen las variables de preset la siguen.

Variación de estilo en /styles/dark.json:

{
  "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
  "version": 3,
  "title": "Dark",
  "settings": {
    "color": {
      "palette": [
        { "slug": "base", "name": "Base", "color": "#111111" },
        { "slug": "contrast", "name": "Contraste", "color": "#f5f5f5" }
      ]
    }
  },
  "styles": {
    "color": {
      "background": "var(--wp--preset--color--base)",
      "text": "var(--wp--preset--color--contrast)"
    }
  }
}

La variación conserva los nombres de los slugs y solo cambia sus valores. Esa es la regla que lo hace funcionar: los bloques guardan el slug, no el hexadecimal. Un conmutador automático entre claro y oscuro basado en prefers-color-scheme no viene con el núcleo. Eso sigue siendo CSS que usted escribe.

Desde WordPress 6.6 la misma carpeta acepta también variaciones solo de color y solo de tipografía, según la entrada del Developer Blog sobre variaciones de estilo de bloque. Para un grupo de marcas sobre un mismo código, eso da una división limpia: espaciado y layout compartidos en el theme.json principal, y un archivo de variación por cada paleta de marca.

#Cómo funcionan los estilos de sección en theme.json desde WordPress 6.6

Antes de la 6.6, un estilo de bloque propio como “Boxed” en una cita destacada significaba una clase CSS más CSS escrito a mano. WordPress 6.3 solo había permitido que theme.json editara los estilos de bloque registrados por el núcleo. En la entrada del Developer Blog de junio de 2024, Justin Tadlock explica que WordPress 6.6 permite dar estilo en theme.json a cualquier variación de estilo de bloque registrada, en styles.blocks.{block}.variations.{name}, incluidos los elementos y bloques anidados dentro de ella. La misma entrada describe los “estilos de sección” como un concepto introducido en la 6.6: una variación de estilo de bloque aplicada a una sección, junto con los elementos y bloques anidados que vuelve a estilizar.

Un estilo de sección se puede registrar desde un archivo JSON en /styles (WordPress busca también en subcarpetas, así que /styles/section/ funciona). La clave blockTypes enumera los bloques a los que se aplica:

{
  "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
  "version": 3,
  "slug": "section-dark",
  "title": "Dark section",
  "blockTypes": [ "core/group", "core/columns" ],
  "styles": {
    "color": {
      "background": "var:preset|color|contrast",
      "text": "var:preset|color|base"
    },
    "elements": {
      "link": {
        "color": { "text": "var:preset|color|accent" }
      }
    }
  }
}

La misma variación se puede registrar en PHP. En la 6.6, register_block_style() acepta un array de nombres de bloque como primer argumento y una clave style_data con la misma estructura que el archivo JSON:

register_block_style(
	array( 'core/group', 'core/columns' ),
	array(
		'name'       => 'section-dark',
		'label'      => __( 'Dark section', 'themeslug' ),
		'style_data' => array(
			'color' => array(
				'background' => 'var:preset|color|contrast',
				'text'       => 'var:preset|color|base',
			),
		),
	)
);

En un sistema de diseño esto sustituye la fuente de deriva más habitual: editores que eligen a mano el fondo y el color de texto de cada Grupo. Con los estilos de sección eligen “Dark section” en el panel de Estilos, y la combinación de fondo, texto y color de enlace sale de una única definición. Después, una variación de estilo global puede reajustar esa sección mediante la propiedad de nivel superior styles.variations, de modo que una variación de marca cambia la sección oscura junto con todo lo demás. La misma entrada señala un límite a tener en cuenta: los estilos de sección funcionan mejor en bloques contenedores como Grupo, Columnas y Portada.

#Patrones del tema frente a patrones sincronizados en WordPress

Esta es la distinción que más proyectos quema.

La introducción a los patrones del Theme Handbook lo dice sin rodeos: los patrones que coloca en /patterns no están sincronizados. Son plantillas para la siguiente inserción. WordPress copia el marcado de bloques dentro de la entrada. Si edita el archivo PHP más tarde, las páginas existentes no cambian. El mismo manual añade que los patrones sincronizados solo se pueden crear y gestionar desde el administrador de WordPress.

Los patrones sincronizados (bloques reutilizables antes de WordPress 6.3) son entradas wp_block en la base de datos. Se crean en el editor. Todas las instancias se mantienen idénticas. Esos objetos no están en Git. Staging y producción necesitan cada uno la misma fila wp_block, o los recrea a mano.

Use esa división a propósito:

Los heros, los layouts de casos de estudio y los esqueletos de landing van en /patterns. Un aviso legal, una línea de cookies o un banner que el equipo legal puede reescribir esta misma tarde van en un patrón sincronizado, con una exportación documentada para que staging no dé sorpresas.

Registre los patrones del tema dejando un archivo PHP con su cabecera en /patterns, que es la ruta que recomienda el capítulo de registro de patrones, o llamando a register_block_pattern() en init. Un patrón, un método. No registre el mismo slug dos veces.

En la práctica una biblioteca de patrones tiene dos capas. Los patrones pequeños de sección son las piezas de construcción: un hero con encabezado, entradilla, botón e imagen; una tarjeta de servicio con icono, título, texto y enlace; un testimonio con foto, cita, nombre y cargo; un banner de llamada a la acción. Los patrones de página completa los combinan en los tipos de página que marketing repite: una landing de servicio, un caso de estudio, una página de equipo, una página de contacto. Los editores eligen un patrón de página completa y sustituyen el texto de ejemplo, así que una página nueva arranca dentro de las reglas de marca y no sobre un lienzo vacío.

Los patrones sincronizados se ganan su sitio con el contenido que debe cambiar en todas partes el mismo día: avisos legales, líneas de consentimiento, bloques con la dirección y el teléfono de la empresa, la llamada a la acción de la campaña en curso.

#Cómo conectan contenido las sobrescrituras de patrones y la Block Bindings API

Un patrón sincronizado era antes todo o nada: o todas las instancias eran idénticas, o lo separaba y perdía la sincronización. WordPress 6.6 añadió las sobrescrituras en patrones sincronizados. En el recorrido del Developer Blog firmado por Nick Diego, una tarjeta conserva su diseño compartido mientras cada instancia cambia su encabezado, su texto y su botón. En el editor se abre el patrón sincronizado con “Edit original”, se selecciona un bloque, se pulsa “Enable overrides” en el panel Avanzado del inspector de bloques y se le da un nombre único. El marcado del bloque lleva entonces un enlace (binding) a la fuente core/pattern-overrides.

Las sobrescrituras se apoyan en dos mecanismos anteriores. La edición solo de contenido, introducida en WordPress 6.1, es templateLock: "contentOnly" en un bloque contenedor: solo el texto y los medios anidados siguen siendo editables, y los controles del inspector para ajustes y estilos quedan desactivados. El segundo es la Block Bindings API, disponible desde WordPress 6.5, que conecta un atributo de bloque con una fuente de datos en lugar de con contenido estático.

El manual enumera qué bloques del núcleo y qué atributos aceptan bindings por defecto:

Las fuentes incluidas son core/post-meta (la clave meta debe estar registrada con show_in_rest y no puede empezar por guion bajo), core/pattern-overrides y, desde WordPress 6.9, core/post-data (fecha, fecha de modificación y enlace) y core/term-data. Un plugin puede añadir su propia fuente con register_block_bindings_source() en init, pasando un label, un array opcional uses_context y un get_value_callback. El binding en sí se guarda en los metadata del bloque:

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"product_sku"}}}}} -->
<p></p>
<!-- /wp:paragraph -->

En un sistema de diseño, así es como un patrón sigue siendo un patrón mientras sus datos vienen de campos estructurados. Un patrón de tarjeta de producto puede enlazar su párrafo de SKU a un campo meta de la entrada, de modo que los editores nunca lo escriban dentro del layout. Dos límites del manual importan aquí. El registro en el lado del editor con registerBlockBindingsSource() llegó en la 6.7, y un valor enlazado no es editable en el editor salvo que la fuente proporcione canUserEditValue. La entrada sobre sobrescrituras también señalaba, en junio de 2024, que los patrones sincronizados se guardan solo en la base de datos y no se pueden empaquetar como archivos de patrón en un tema, con las primeras exploraciones registradas en una issue de Gutenberg.

#Cómo versionar patrones del tema con Git

WordPress no versiona patrones: no hay estados, ni aprobaciones, ni migración automática de las instancias ya insertadas. Lo que existe es Git sobre la carpeta /patterns, y el ciclo lo fija el equipo:

1. Borrador: el patrón nuevo vive en una rama.
2. Revisión: marca o legal lo aprueban en la pull request.
3. Publicado: se despliega y aparece en el insertador.
4. Retirado: se quita del insertador borrando el archivo o la llamada a register_block_pattern(). Las páginas que ya lo insertaron conservan su marcado, y hay que tocarlas una a una.

El paso cuatro es la razón para mantener corto el juego de patrones. Cada patrón que publica deja copias en el contenido que el tema ya no puede alcanzar.

#Cómo bloquear plantillas de Gutenberg con templateLock

Una paleta con custom: false sigue fallando si la plantilla de página es un Grupo vacío y el insertador ofrece todos los bloques del núcleo. Para los tipos de página que deben mantener su molde (producto, sede, documentación), bloquee la plantilla: allowedBlocks en el grupo, templateLock: "insert" o "all" donde el layout no deba reordenarse, y un patrón como contenido por defecto para que el editor nunca parta de un lienzo vacío.

La referencia de plantillas de bloques define los valores. all impide insertar, mover y eliminar bloques. insert impide insertar o quitar bloques, pero permite mover los existentes. contentOnly impide todas las operaciones, oculta en la Vista de lista los bloques sin contenido y no puede ser anulado por los bloques hijos. El bloque Grupo declara templateLock como atributo en su block.json, así que el bloqueo puede vivir directamente en el marcado de una plantilla o de un patrón.

Hay dos niveles más. Un bloque concreto puede llevar un atributo lock con los flags move y remove, y la referencia indica que el bloqueo a nivel de bloque tiene prioridad sobre templateLock. Un tipo de contenido personalizado puede registrar su propio array template y un template_lock en register_post_type(), de modo que cada producto nuevo arranque desde la misma estructura de bloques.

Dentro de un bloque propio, el mismo bloqueo se aplica a sus bloques internos:

<InnerBlocks
	template={ TEMPLATE }
	templateLock="all"
	allowedBlocks={ [ 'core/heading', 'core/paragraph', 'core/button' ] }
/>

Los editores pueden seguir cambiando el texto y las imágenes, pero no pueden reordenar, eliminar ni añadir bloques fuera de la estructura definida.

#Cuándo crear un bloque personalizado de Gutenberg con block.json

Ahí es también donde un bloque propio se gana su sitio. Encabezado, párrafo e imagen del núcleo cubren la mayoría de los módulos de marketing. Una tabla comparativa que debe llevar un SKU, una moneda y una fecha de última verificación necesita atributos y validación en block.json. Esos bloques los construimos con @wordpress/scripts, mantenemos aburrido el marcado de save y nos negamos a recrear un maquetador dentro del inspector. Si el bloque es solo una piel alrededor de bloques internos, prefiera un patrón.

Una carpeta de bloque en el repositorio del sistema de diseño tiene este aspecto:

blocks/
└── product-comparison/
    ├── block.json
    ├── edit.js       (interfaz del editor)
    ├── save.js       (marcado del front)
    ├── style.scss    (estilos del front y del editor)
    └── editor.scss   (estilos solo del editor)

La referencia de metadatos de bloque usa "apiVersion": 3 en su ejemplo. Conviene saber dónde termina la validación de block.json. La referencia de atributos dice que cada definición de atributo contiene al menos un type o un enum, además de dónde se lee el valor. enum restringe el valor guardado. No hay maxLength, minimum ni maximum que Gutenberg haga cumplir por usted:

{
  "apiVersion": 3,
  "name": "wppoland/product-comparison",
  "attributes": {
    "heading": { "type": "string", "default": "" },
    "price": { "type": "number", "default": 0 },
    "variant": {
      "type": "string",
      "enum": [ "primary", "secondary", "accent" ],
      "default": "primary"
    }
  }
}

Los límites de rango y longitud se aplican en el componente de edición o en la validación REST al guardar:

<RichText
	tagName="h3"
	value={ attributes.heading }
	onChange={ ( heading ) => setAttributes( { heading: heading.slice( 0, 120 ) } ) }
/>

La referencia de @wordpress/scripts cubre el resto de la cadena de herramientas desde una sola dependencia. build genera un bundle de producción y start recompila con cada cambio. lint-js y lint-style aplican los estándares de código de WordPress a scripts y hojas de estilo. test-e2e ejecuta pruebas end-to-end con Playwright, y plugin-zip empaqueta el plugin. El mismo paquete detecta los archivos block.json del directorio de código fuente y los usa como puntos de entrada, así que una carpeta de bloque nueva no requiere tocar webpack.

#Cómo usar Storybook para los componentes de UI de Gutenberg

El propio proyecto Gutenberg documenta sus componentes de UI en Storybook. El README de la carpeta storybook del repositorio de Gutenberg afirma que el proyecto “usa Storybook para ver y trabajar con los componentes de UI desarrollados en los paquetes de WordPress” (traducción propia), publica el resultado en wordpress.github.io/gutenberg y lo arranca en local con npm run storybook:dev desde la raíz del repositorio.

Dos prácticas de ese README se trasladan bien al sistema de diseño de un cliente. Cada página de componente declara un estado (recommended, use-with-caution, not-recommended o unaudited) que aparece en la barra lateral, así los desarrolladores ven sobre qué componentes es seguro construir. Y el repositorio guarda una instantánea de manifiesto con cada componente y sus props: una pull request que elimina la descripción de una prop falla hasta que alguien reconoce el cambio.

Lo que Storybook no cubre es la capa de contenido. Los patrones, los presets de theme.json y los estilos de sección se renderizan dentro del editor de bloques, así que la vista previa fiable para ellos es una página en un sitio de staging que inserte todos los patrones, editada con una cuenta de editor. Storybook encaja con las partes React del sistema: los componentes edit de los bloques propios y cualquier control compartido de barra lateral construido con @wordpress/components, que es la librería que documenta el Storybook público.

#Cómo pasar tokens de Figma a theme.json

No existe una sincronización oficial entre Figma y WordPress. El núcleo no lee archivos de Figma, y ningún plugin de Figma escribe en un sitio de producción por sí mismo. Lo que sí se puede construir es un paso de build: los tokens salen de la herramienta de diseño como JSON y un script los escribe dentro de theme.json, que es lo que envía el despliegue.

Los nombres casi nunca coinciden de entrada, así que ese mapeo es código que alguien mantiene. Un flujo que se sostiene:

1. El diseñador cambia un color en Figma.
2. Un plugin de tokens exporta los tokens actualizados como JSON.
3. La CI ejecuta el script de build, que reescribe settings.color.palette en theme.json.
4. Las pruebas de regresión visual comparan capturas antes y después.
5. Una persona lee el diff de theme.json y aprueba la pull request.

Detenga la automatización en el paso cinco. Un webhook que despliega producción sin que nadie lea el diff es una demo, no un sistema. Un color de marca es justo el tipo de cambio que merece una revisión humana.

La documentación puede salir casi gratis de material que ya existe: una página del sitio que inserte cada patrón de la biblioteca, el historial de Git de /patterns y theme.json como changelog, y las capturas de las pruebas visuales como registro del antes y el después.

#Cómo comprobar la accesibilidad en un sistema de diseño WordPress

Nada de esto lo hace WordPress por usted. Son comprobaciones que se montan alrededor del tema.

La paleta es una lista corta de hexadecimales en un archivo JSON, así que el contraste se puede comprobar en el build. Un test recorre los pares de texto y fondo permitidos, calcula la ratio WCAG y hace fallar el build cuando un par baja de 4.5:1 en texto normal. Señala la combinación que falla por su slug, no por su hexadecimal, para que la corrección aterrice en theme.json. El editor de bloques ya avisa en el inspector cuando una combinación de colores elegida tiene poco contraste, pero ese aviso no impide publicar. Los estilos de sección ayudan aquí: cuando el par de fondo y texto se define una vez en un estilo de sección, se prueba una vez.

En la CI, ejecute axe-core contra las plantillas principales y contra cada variación de estilo publicada, y añada pruebas de navegación por teclado para los patrones que contienen elementos interactivos. Recuerde el límite: las herramientas automáticas detectan solo una parte de los criterios WCAG. El resto sigue siendo revisión manual con teclado y lector de pantalla.

#Cómo se cargan los assets de bloque bajo demanda en un tema de bloques

Un sistema de diseño mal montado puede ser más lento que un sitio programado a mano, porque cada patrón arrastra su CSS. El núcleo ayuda si se lo permite. En _add_default_theme_supports(), que se ejecuta para los temas de bloques, WordPress añade tanto should_load_separate_core_block_assets como should_load_block_assets_on_demand como filtros __return_true (véase wp-includes/theme.php en wordpress-develop). El docblock de script-loader.php describe el efecto: los assets de un bloque se cargan solo cuando el bloque se renderiza. Un tema clásico lo activa con:

add_filter( 'should_load_separate_core_block_assets', '__return_true' );

Una página sin galería deja entonces de cargar el CSS de la galería. Para los bloques propios, la regla práctica se deduce de aquí: declare style, editorStyle, viewScript o viewScriptModule en block.json en lugar de encolar archivos de forma global desde functions.php, para que WordPress pueda cargarlos solo donde aparece el bloque. Lo que WordPress no hace es generar CSS crítico ni eliminar reglas sin usar. Eso sigue siendo trabajo de su build o de una capa de caché.

Los presupuestos por componente son una decisión del equipo, no una medida del núcleo, y solo funcionan si alguien los revisa en cada pull request. Muchas veces la mejora más barata es no necesitar ningún script: un acordeón de FAQ hecho con el bloque Detalles genera <details> y <summary>, que se abren y se cierran sin JavaScript y funcionan con el teclado.

#Checklist de un sistema de diseño escalable en WordPress

En los proyectos de desarrollo WordPress la secuencia es siempre la misma:

1. Tokens en theme.json versión 3, selector bloqueado y paleta del núcleo oculta.
2. Estilos de sección para los pares de fondo y texto, para que los editores dejen de colorear Grupos a mano.
3. Un juego corto de patrones en /patterns para los layouts que marketing repite de verdad.
4. Uno o dos patrones sincronizados para los textos que gobierna legal, exportados junto con la sincronización de contenido y nunca dejados en “ya lo recrearemos en producción”.
5. Bloques propios solo después de que un patrón sobre bloques del núcleo haya fallado ante una restricción real de atributos.
6. Una revisión en el Editor del sitio con una cuenta de editor, no de administrador, porque el administrador sigue viendo herramientas que usted creía haber escondido.

Si el front ya usa CSS de utilidades, mantenga theme.json como origen de los tokens y mapee los slugs hacia ese CSS. Dejamos escrita esa división para Tailwind en Tailwind CSS en el desarrollo WordPress. A Gutenberg le da igual qué framework CSS consuma --wp--preset--color--primary. Lo que le importa es que el editor y el front nombren el mismo slug.

El sistema funciona cuando una landing nueva es una inserción de patrón, el selector de color tiene ocho muestras y la petición de “solo este naranja” llega como una pull request a theme.json, no como un hexadecimal dentro de un bloque Grupo.

¿Está planificando un sistema de diseño en WordPress? Escríbanos.