WordPress 7.0 para developers: APIs y patrones nuevos para tu caja

En el post anterior repasamos los cambios que pueden romper código en producción al actualizar a WordPress 7.0 «Armstrong». Cubrirlos es trabajo de saneamiento. Esta segunda entrega va de lo contrario: APIs y patrones nuevos que reducen código existente, abren posibilidades que antes requerían parches, y merecen entrar en tu caja de herramientas desde la próxima estimación.

Registro de bloques solo en PHP con autoRegister

Antes de 7.0, registrar un bloque dinámico solo desde PHP era posible, pero los atributos, los supports y las variantes seguían dependiendo de un block.json paralelo o de register_block_type_from_metadata(). El resultado: incluso bloques sin un solo gramo de JavaScript tenían que arrastrar un archivo JSON, un directorio build/ o algún apaño de duplicación.

En 7.0 se cierra ese ciclo. Declarando 'autoRegister' => true dentro de la llamada a register_block_type() desde PHP, el bloque queda registrado completamente sin archivo JSON adicional:

register_block_type( 'myplugin/dynamic-cta', array(
    'autoRegister'    => true,
    'render_callback' => 'myplugin_render_cta',
    'attributes'      => array(
        'message' => array( 'type' => 'string', 'default' => '' ),
        'tone'    => array( 'type' => 'string', 'default' => 'info' ),
    ),
    'supports'        => array(
        'align'   => true,
        'spacing' => array( 'padding' => true ),
    ),
) );

¿Cuándo merece la pena? Tres casos típicos:

• Bloques dinámicos generados según contexto del sitio (multitenant, white-label).
• Plugins que no quieren mantener un build de JavaScript solo para registrar un bloque del lado del servidor.
• Variantes programáticas de un bloque ya existente sin tocar el editor.

No es una herramienta para todos los bloques —si tu bloque tiene UI compleja en el editor, sigues necesitando JavaScript—, pero para el catálogo creciente de bloques dinámicos puramente render-side es una limpieza importante.

Pattern Overrides para bloques custom

Hasta 7.0, los pattern overrides —la funcionalidad que permite editar puntualmente un atributo de un bloque dentro de un patrón sincronizado sin desincronizar el patrón completo— estaban limitados a una lista cerrada de bloques core. Para bloques custom no era posible.

En 7.0 se expone el filtro block_bindings_supported_attributes, que permite declarar qué atributos de qué bloques son sobreescribibles:

add_filter( 'block_bindings_supported_attributes', function( $supported, $block_name ) {
    if ( 'myplugin/feature-card' === $block_name ) {
        $supported[] = 'title';
        $supported[] = 'description';
        $supported[] = 'icon';
    }
    return $supported;
}, 10, 2 );

Esto abre la puerta a patrones reales para componentes de marca propios: una tarjeta de equipo, un bloque de testimonial, una ficha de servicio. Antes había que duplicar el patrón por cada variante; ahora basta con sobreescribir los atributos puntuales en cada instancia.

Para proyectos que construyen sobre patrones —agencias, sitios editoriales, sistemas de diseño internos— esto cambia el flujo. Una tarjeta con título, descripción e icono custom puede vivir como un único patrón sincronizado y aceptar overrides en cada uso. Menos patrones, menos mantenimiento, más reutilización.

Interactivity API: watch() y data-wp-watch

La Interactivity API gana dos primitivas que cubren un caso común que antes requería código manual de re-render: reaccionar a cambios de un signal sin escribir lógica de suscripción a mano.

En el cliente, watch() permite registrar callbacks que se ejecutan cuando un signal cambia:

import { store } from '@wordpress/interactivity';

const { state, callbacks } = store( 'myplugin', {
    state: {
        cartCount: 0,
    },
    callbacks: {
        onCartChange() {
            const count = state.cartCount;
            // reaccionar al cambio: actualizar UI, hacer fetch, lo que sea
        },
    },
} );

En HTML, el atributo data-wp-watch ata ese callback a un elemento:

<div
  data-wp-interactive="myplugin"
  data-wp-watch="callbacks.onCartChange"
></div>

¿Para qué sirve realmente? Para bloques interactivos con estado compartido entre componentes que viven en distintos puntos del DOM. Un filtro arriba de la página que afecta a tres listados separados. Un carrito de WooCommerce que actualiza un contador en el header y un panel lateral simultáneamente. Un selector de idioma que reorganiza varias secciones.

Antes esto exigía o bien tirar de directivas como data-wp-context con gimnasia para sincronizar, o bien escribir tu propia suscripción manual a los signals. Ahora es declarativo.

@wordpress/boot para páginas custom del site editor

Si has hecho una página de administración custom con @wordpress/element montada manualmente sobre admin_menu, sabes que algo falla en la integración: el command palette con ⌘K no la encuentra, las route validations no se aplican, los stores se montan a mano y todo se siente «aparte» del resto del editor.

@wordpress/boot es un paquete nuevo que arranca páginas custom del site editor con el mismo bootstrap que las nativas. La integración incluye validación de rutas, registro automático en stores core y compatibilidad con el command palette.

Casos donde lo elegiría sin pensar:

• Una pantalla de configuración avanzada de plugin que vive «dentro» del editor.
• Una vista de auditoría de patrones para una agencia.
• Un panel de gestión de licencias con flujo de usuario nativo.

Si tu objetivo es una pantalla puntual en wp-admin/admin.php?page=…, sigue siendo más simple un mount manual. Si vas a vivir dentro del site editor, este paquete reemplaza decenas de líneas de bootstrap.

Resumen accionable

Antes de empezar el próximo proyecto:

1. Revisa tu catálogo de bloques dinámicos. Cualquiera puramente PHP es candidato a autoRegister.
2. Identifica patrones que has duplicado para variar título o descripción. Migra a pattern overrides con el filtro block_bindings_supported_attributes.
3. Si has escrito código manual de suscripción a signals en la Interactivity API, evalúa migrar a watch() y data-wp-watch.
4. Si tienes pantallas custom integradas con el editor, mira @wordpress/boot antes del siguiente refactor.

En el próximo post entramos en la novedad más mediática del release pero analizada desde el ángulo developer: Connectors API y AI Client. Por qué consumir el AI Client del core va a sustituir tus envoltorios artesanales de OpenAI o Anthropic en proyectos de cliente.