Los dos maquetadores más usados del ecosistema WordPress han renovado su arquitectura casi a la vez, y eso no pasa todos los días.

No estamos hablando de actualizaciones al uso, con un puñado de funciones nuevas y un par de correcciones, tanto Elementor como Divi han reescrito buena parte de su base de código.

Elementor ha apostado por lo que llaman el «editor atómico«, con un enfoque CSS-first. Divi, por su parte, ha tirado la casa por la ventana con una reescritura completa de Divi Builder desde cero, tras más de tres años de desarrollo (llevo siguiendo todo el proceso, desde la primera demo de Divi 5 hasta la alpha pública).

Así que si llevas tiempo preguntándote cuál elegir, o si te estás planteando cambiar de uno a otro, este es el mejor momento para comparar, vamos a ello.

Migración y retrocompatibilidad

Los dos se han tomado la retrocompatibilidad en serio, pero con estrategias diferentes.

Migrar de Elementor 3 a Elementor 4

Permite usar elementos de v3 y v4 en la misma página. No necesitas migrar nada, los widgets antiguos siguen funcionando tal cual, puedes ir adoptando los elementos atómicos gradualmente. Es lo más seguro y menos agresivo.

Migrar de Divi 4 a Divi 5

Divi 5 incluye un migrador que convierte todos los módulos de Divi 4 al nuevo formato. El proceso es rápido, pero conviene probarlo primero en staging (tengo una guía detallada del proceso de migración a Divi 5 con lo que me he encontrado).

También hay un modo de compatibilidad hacia atrás para módulos de terceros que todavía no se han adaptado.

Elegant Themes mantiene compatibilidad con Divi 4 durante al menos seis meses después del lanzamiento, con actualizaciones de seguridad. Pasado ese periodo las rutas de actualización convergerán y todos los sitios recibirán el aviso de actualización a Divi 5.

Si tienes un sitio complejo con muchos plugins de terceros la migración a Divi 5 requiere más precaución. Con Elementor 4 la transición es más progresiva y con menos riesgo, pero en contrapartida mantiene demasiada compatibilidad con código antiguo.

Arquitectura y rendimiento

Este es el punto donde los dos han metido más trabajo, y donde el cambio respecto a las versiones anteriores es más evidente.

Elementor 4

Elementor ha introducido lo que llaman el «Atomic Editor» para pasar de un sistema basado en widgets con estilos inline a un enfoque basado en CSS donde los estilos se gestionan a través de clases y variables reutilizables.

Esto genera un DOM más limpio y menos código repetido. Según datos de Elementor la reducción de código CSS puede llegar al 70 % en páginas que usan íntegramente los elementos atómicos frente al sistema antiguo de la v3.

Elementor 4 y la versión 3 coexisten en la misma página, no tienes que migrar todo de golpe, puedes ir adoptando los nuevos elementos atómicos poco a poco mientras mantienes los widgets de v3 funcionando.

Lo malo es que la mejora en estas situaciones sería limitada, arrastrando problemas de las versiones 3.x.

Divi 5

La gente de Elegant Themes ha ido más lejos en cuanto a reescritura, pues es un maquetador completamente nuevo, desarrollado con React y una arquitectura moderna desde la misma base.

Y aquí viene lo gordo, porque Divi 5 ha eliminado los shortcodes que lastraban el rendimiento de Divi 4 y ahora usa un formato de almacenamiento basado en HTML5, alineado con el sistema de bloques de WordPress.

Este cambio es enorme, pues ya no hay procesamiento de shortcodes en cada carga de página, el CSS se genera de forma limpia, los scripts no esenciales se cargan en diferido y el peso base de cada página se ha reducido de forma considerable.

Si desactivas Divi 5 ya no te quedas con un montón de shortcodes ilegibles en el contenido como pasaba antes.

Hice mis propias pruebas de rendimiento comparando Divi 5 con Divi 4 cuando todavía estaba en fase alpha, con dos sitios idénticos en el mismo servidor, y ya entonces la mejora apuntaba maneras.

Ahora, con la versión final, los datos son todavía mejores. Según pruebas recientes (WP All Import, Oxygen), Divi 5 iguala o supera a Elementor en varias métricas clave:

• Mejor FCP (First Contentful Paint)
• Mejor Speed Index
• Menos peticiones HTTP
• Puntuaciones de Lighthouse superiores tanto en móvil como en escritorio.

Elementor puede tener un tamaño de página ligeramente menor en algunas situaciones, pero Divi 5 genera menos peticiones al servidor y un CSS más limpio que Elementor.

El salto de rendimiento de Divi 5 frente a Divi 4 ha sido tremendo. Si probaste Divi 4 y te pareció lento, Divi 5 es otro producto.

Frente a Elementor 4, la diferencia ya no es que Divi vaya por detrás, van bastante igualados, con Divi llevando ventaja en varias métricas.

Sistema de diseño

Aquí es donde estos cambios marcan un antes y un después para los dos maquetadores porque ambos han adoptado conceptos que vienen del mundo del diseño de interfaces (Figma, Sketch) y que hasta ahora eran territorio exclusivo de herramientas de desarrollo.

Elementor 4

Trae tres novedades gordas en este apartado:

• Variables: puedes definir valores globales para colores, tipografías y espaciados. Cambias un valor y se actualiza en todo el sitio. Funcionan como design tokens.
• Clases CSS: puedes crear clases reutilizables y asignarlas a cualquier elemento. Nada de ir widget por widget cambiando estilos, que era una pesadilla.
• Sincronización con estilos globales: las nuevas variables y clases se sincronizan automáticamente con los colores y fuentes globales de v3, lo que facilita la transición.

Divi 5

En esto ha ido un paso más allá con un sistema de presets bastante completo:

• Variables de diseño: similares a las de Elementor, permiten definir valores globales para colores, tipografías, tamaños y espaciados.
• Preajustes anidados y apilables: puedes crear presets a nivel de módulo y a nivel de grupo de opciones (por ejemplo, un preset solo para bordes) y anidarlos. Aplicas un preset de módulo y los presets de opciones se aplican automáticamente.
• Inspector: inspirado directamente en Figma. Clic derecho en cualquier sección y ves un panel con todos los estilos aplicados (colores, fuentes, medios, presets). Puedes editar todo desde ahí, incluso hacer cambios en lote. Esto es una pasada para cuando importas layouts y necesitas adaptar la paleta de colores de golpe.

En este apartado Divi 5 lleva ventaja porque el sistema de preajustes anidados y el inspector son herramientas que ahorran mucho tiempo, sobre todo cuando trabajas con plantillas importadas o gestionas varios sitios con la misma identidad visual.

Editor y experiencia de uso

El día a día con un maquetador se juega aquí, no en la lista de funcionalidades.

Elementor 4

Mantiene la estructura de editor que ya conocemos: panel lateral izquierdo con los ajustes del elemento seleccionado y edición visual en el lienzo. Las novedades más visibles son:

• Edición inline mucho más fluida (puedes editar textos directamente en el lienzo).
• La pestaña de estilo se ha unificado para los elementos atómicos, lo que simplifica la navegación.
• Pro Interactions: animaciones al hacer scroll, efectos al pasar el cursor y transformaciones personalizadas sin necesidad de plugins de terceros.
• Selección múltiple de elementos: seleccionas varios a la vez y les aplicas cambios en bloque.

Divi 5

Aquí también ha renovado la experiencia de edición de arriba abajo:

• El maquetador visual es mucho más rápido que en Divi 4. El editor de backend, que era muuuy lento con páginas complejas, ha mejorado de forma impresionante.
• Paneles acoplables: puedes anclar los paneles de ajustes a la barra lateral o dejarlos flotantes, y gestionar varios paneles abiertos a la vez.
• Menú contextual con clic derecho para todo (añadir, copiar, pegar, inspeccionar), que agiliza mucho el flujo de trabajo.
• El Command Center (similar a la paleta de comandos de VS Code) para acceder a cualquier función del maquetador escribiendo su nombre.
• La vista de capas para gestionar la estructura sin tocar el lienzo.
• Siete puntos de ruptura adaptables (responsive) personalizables (Divi 4 tenía tres fijos).

Si quieres ver los cambios de Divi 5 con más detalle tengo una guía visual completa de los cambios de Divi 5 que te puede servir de referencia.

En el caso de que vengas de Divi 4 la mejora de rendimiento del editor es lo primero que vas a notar, si vienes de Elementor, el inspector y los paneles acoplables te van a llamar la atención.

Los dos editores son buenos actualmente pero Divi ha dado un salto más grande porque partía de más atrás.

Componentes y modularidad

Los dos maquetadores han apostado fuerte por los componentes reutilizables, aunque con enfoques distintos.

Elementor 4 Components

Sustituyen a los antiguos widgets globales. La diferencia es que los componentes sincronizan estructura y estilos (los widgets globales solo sincronizaban estilos), y además permiten personalización controlada en cada necesidad.

Es decir, puedes tener un componente de tarjeta de producto que se sincroniza en todo el sitio, pero cambiar el texto o la imagen en cada lugar donde lo uses sin romper la sincronización global.

También los formularios se han modularizado, ahora los Atomic Forms descomponen los formularios en elementos individuales (etiqueta, campo, botón de envío) que puedes organizar libremente en el lienzo.

Divi 5 Nested Modules

Permiten meter módulos dentro de otros módulos sin límites, lo que abre muchas posibilidades, como poder poner un botón dentro de un menú, un formulario dentro de una tarjeta, o construir estructuras de menú complejas sin necesidad de plugins adicionales.

Los controles de Flexbox y CSS Grid se aplican a cualquier contenedor, lo que da una flexibilidad de maquetación que antes no existía en Divi.

Ambas ideas resuelven los problemas de manera muy eficiente.

Elementor con sus Components apuesta por la consistencia a escala (perfecto para agencias que gestionan muchos sitios), mientras que Divi con los Nested Modules apuesta por la flexibilidad creativa (perfecto para diseñadores que quieren control total sobre la estructura).

Integración con IA

Aquí es donde las diferencias se ponen interesantes porque los dos han ido por caminos bastante distintos.

Elementor AI

Tiene como dos capas, o dos modos de usar IA. Por un lado está la IA base, que está integrada directamente en el editor. Genera textos, imágenes, código CSS personalizado y diseños de secciones completas.

Funciona con un sistema de créditos. Un prompt de texto o código cuesta 1 crédito, una imagen 33 créditos, un contenedor con layout 40 créditos.

Los planes específicos de IA van desde unos 44 €/año (24.000 créditos) hasta 176 €/año (100.000 créditos). Con el plan Elementor One (desde 168 €/año en precio de lanzamiento) los créditos se comparten entre IA, optimización de imágenes y otras funciones.

La segunda capa es Angie, un agente de IA que va más allá de generar texto o imágenes, pues entiende la estructura de tu sitio WordPress (tema, plugins, campos personalizados) y puede crear widgets personalizados, snippets de código y extensiones funcionales a partir de instrucciones en lenguaje natural.

Todo se prueba en un entorno de pruebas antes de tocar tu sitio en producción. Usa el Model Context Protocol (MCP) para heredar automáticamente el contexto de tu instalación.

Ahora bien, la realidad de Angie a día de hoy es que según pruebas de empresas como Crocoblock, que basan su negocio en gran medida en Elementor, es que al agente todavía falla bastante.

Tiende a generar HTML en crudo en lugar de usar los widgets de Elementor, y hay muchos prompts complejos que simplemente no funcionan.

Es un concepto prometedor pero todavía está muy verde. Lo que sí funciona bien de Elementor AI es la generación de imágenes y el CSS personalizado, que conoce la estructura de los módulos de Elementor.

Divi AI

El maquetador Divi toma un enfoque diferente pues todo está integrado directamente en el maquetador, sin plugins separados. Desde cualquier campo de texto, imagen o código puedes invocar la IA.

Sus capacidades son estas:

• Generación y reescritura de textos (títulos, párrafos, posts enteros).
• Generación de imágenes.
• Código CSS personalizado, entrenado específicamente con la base de código de los módulos de Divi.
• Generación de layouts completos: le describes tu negocio y una cadena de agentes crea el esqueleto de la página, construye la estructura, rellena con texto e imágenes y personaliza los estilos.

Divi acaba de empezar a desarrollar su propio AI Agent (aparece en los registros de cambio de las versiones 5.1 y 5.2), pero está en fases muy tempranas, todavía no es funcional del todo.

La diferencia grande en precios:, sobre todo porque Divi AI es ilimitado si tienes Divi Pro (unos 255 €/año) o el bundle Lifetime + Pro Services (unos 273 € de pago único + 195 €/año de servicios). Con Divi AI hay créditos, no hay topes, mientras que en Elementor AI pagas por uso.

¿Qué sale mejor?, pues depende:

• Si usas mucho la IA diseñando el modelo de Divi es más predecible en costes.
• Si utilizas la IA para maquetar de forma puntual el sistema de créditos de Elementor puede salir más económico.

WooCommerce

Los dos maquetadores ofrecen compatibilidad completa con WooCommerce, pero con diferencias.

Elementor Pro

La versión 4 ya incluye módulos específicos para WooCommerce:

• Páginas de producto
• Listados de tienda
• Carrito y pago personalizables visualmente.

Pero ojo, el WooCommerce Builder de Elementor completo requiere adicionalmente el plan Advanced Solo (unos 77 €/año) o superior. Con Elementor 4 estos módulos se benefician del nuevo sistema atómico y del rendimiento mejorado.

Divi 5

En esto ha completado la migración de todos los módulos de WooCommerce a la nueva arquitectura:

• Galería de producto
• Módulos de checkout y carrito
• Módulos de pago

Funciona con cualquier plan de Divi, sin restricciones por nivel de suscripción.

El Loop Builder de Divi permite crear listados de productos con consultas personalizadas, filtros avanzados y diseños de cuadrícula flexibles.

En funcionalidad pura de WooCommerce están bastante igualados.

La diferencia es que en Elementor necesitas un plan medio-alto para acceder al builder completo de WooCommerce, mientras que en Divi viene incluido en todos los planes.

Ecosistema y escalabilidad

Elementor tiene una ventaja obvia, porque con más de 12 millones de instalaciones activas, gracias a la acertada estrategia de ofrecer una version (capada) en WordPress.org, su ecosistema de plugins y extensiones de terceros es enorme.

Hay cientos de addons disponibles (JetElements, Essential Addons, Premium Addons…) que amplían las funcionalidades del maquetador. La versión 4 mantiene retrocompatibilidad con los addons de v3 así que el ecosistema existente sigue funcionando.

Además, Elementor se está convirtiendo en una plataforma más que en un simple plugin, porque ofrece hosting propio (Elementor Cloud), integración con herramientas de accesibilidad (Ally), optimización de imágenes, envío de emails transaccionales y gestión centralizada de sitios, todo dentro de su plan One.

Divi tiene su propio marketplace con plugins y módulos de terceros, aunque más reducido que el de Elementor, pues cometieron el error, a mi modo de ver, de no ofrecer versión limitada en WordPress.org.

La transición a Divi 5 ha sido un reto para los desarrolladores de terceros, ya que la reescritura completa del maquetador requiere adaptar los plugins. Muchos ya tienen versiones compatibles, pero otros siguen en desarrollo.

Si dependes mucho de plugins de terceros para Divi, conviene comprobar la compatibilidad antes de migrar.

Divi incluye en su paquete base Divi Cloud (almacenamiento de assets en la nube), Divi Dash (gestión de múltiples sitios) y las extensiones DonDivi (que Elegant Themes ha adquirido recientemente, incluyendo DiviMenus). También tienes Bloom (formularios de suscripción) y Monarch (botones sociales) sin coste adicional.

Modelo de precios

Aquí las diferencias son grandes y merece la pena verlas con calma. Los precios de Elementor están en euros directamente, los de Divi están en dólares (los paso a euros aproximados al cambio actual).

Un par de cosas a tener en cuenta:

Elementor no ofrece licencia ilimitada. Eso significa que si dejas de pagar dejas de recibir actualizaciones y soporte. Divi sí la ofrece, y a 229 € con sitios ilimitados es difícil de batir para quién trabaja con muchos sitios.

En cuanto a Elementor Free, que existe y que a veces se presenta como una ventaja, la realidad es que cada vez se queda más corto. Le faltan el Theme Builder, los formularios, los popups, el WooCommerce Builder y la mayoría de widgets Pro. Es más un gancho comercial para vender la versión de pago que un producto usable en producción.

Divi no tiene versión gratuita, pero ofrece una demo para probar y 30 días de garantía de devolución.

La comparación directa depende mucho del tipo de uso que le vayas a dar:

• Para un solo sitio con WooCommerce, Elementor Advanced Solo (77 €) sale más barato que Divi anual (82 €), pero Divi incluye sitios ilimitados.
• Para agencias, el lifetime de Divi a 229 € con sitios ilimitados es muy difícil de superar frente a los 367 €/año de Elementor Agency.
• Si la IA ilimitada te interesa, los 255 €/año de Divi Pro son más predecibles que el sistema de créditos de Elementor.

Entonces, ¿cuál es mejor actualmente, Divi o Elementor?

No hay un ganador absoluto pero sí perfiles claros para cada uno dependiendo de tus prioridades. Siento no mojarme más, pero es la realidad.

Elementor te viene mejor si:

• Necesitas un ecosistema de plugins de terceros grande y maduro.
• Valoras una transición gradual sin migraciones bruscas.
• Buscas una plataforma todo-en-uno (maquetador + hosting + IA + accesibilidad + email).
• Tu flujo de trabajo se basa en componentes reutilizables sincronizados a escala.
• Gestionas pocos sitios y no necesitas licencias ilimitadas.

Divi te viene mejor si:

• Gestionas muchos sitios y necesitas una licencia que cubra todos sin límite.
• Quieres un pago único (lifetime) y olvidarte de renovaciones anuales del maquetador.
• Usas mucho la IA y prefieres un modelo de uso ilimitado sin créditos.
• Valoras el inspector y el sistema de preajustes anidados para gestionar sistemas de diseño.
• Necesitas flexibilidad máxima de maquetación con módulos anidados y CSS Grid nativo.

Los dos están en un momento de transición, y es algo que también debes valorar.

Elementor 4 es más maduro en su nueva arquitectura (lleva más de un año con las funciones atómicas en alpha y beta). Divi 5 acaba de salir de beta y todavía está puliendo detalles, pero el ritmo de actualizaciones es alto (cada dos semanas).

Si estás empezando un proyecto nuevo hoy, cualquiera de los dos es una buena elección.

Si ya tienes sitios en uno de ellos, la migración al otro rara vez compensa el esfuerzo. Lo que sí conviene es actualizar a las nuevas versiones y aprovechar las mejoras de rendimiento y las nuevas herramientas de diseño que ambos traen.

Si quieres más información, demos o capturas aquí tienes las webs oficiales de ambos:

• Elementor Pro 4
• Divi 5

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.

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.

Si gestionas webs para clientes es todavía peor, porque les estás mostrando información que no les aporta nada y ocupa un espacio que podría ser útil.

La buena noticia es que puedes cambiarlo por tus propias fuentes de noticias, ya sea con un poco de código o con un plugin que te lo deja todo listo. Aquí tienes las dos opciones.

Pero antes…

¿Y para qué quiero noticias personalizadas en el escritorio de WordPress?

Si haces webs para clientes, un widget con tus noticias o las de su sector es un detalle de branding que se agradece mucho. El cliente entra al escritorio y ve información relevante en vez del blog de WordPress.org, que probablemente no le dice nada.

También viene bien si tienes un equipo de redactores o editores y quieres que vean novedades del proyecto, fuentes de referencia del sector o avisos internos nada más acceder. Y si simplemente quieres tener a mano tus blogs favoritos sin salir de WordPress, pues también.

Casos típicos donde encaja bien:

• Agencias y freelances que entregan proyectos a clientes y quieren dejar el escritorio personalizado.
• Medios y blogs con varios redactores, para compartir fuentes de información comunes.
• Intranets o sitios corporativos donde el escritorio es la primera pantalla que ven los usuarios.
• Tu propio WordPress, para tener las noticias que te interesan a un clic.

Si aún tienes interés, vamos a las opciones…

Opción rápida: código de funciones

Si solo necesitas mostrar un par de feeds RSS en el escritorio y quieres algo ligero, con un snippet te sobra. Puedes añadirlo a tu plugin de personalizaciones, al functions.php de tu tema hijo o donde tú prefieras.

<?php
/**
 * Widget de escritorio con noticias RSS personalizadas.
 *
 * Sustituye el widget por defecto de WordPress por uno con tus feeds.
 * Quita la primera línea si vas a añadir el código al functions.php o
 * a un plugin de fragmentos de código. Déjala si lo subes como mu-plugin
 *
 * Personaliza los feeds en el array $feeds (url y título).
 * Ajusta $items_per_feed y $max_items a tu gusto.
 */

// Registra el widget personalizado y quita el de WordPress
add_action( 'wp_dashboard_setup', 'ayudawp_custom_news_widget_setup' );

function ayudawp_custom_news_widget_setup() {
    // Quita el widget por defecto de noticias y eventos de WordPress
    remove_meta_box( 'dashboard_primary', 'dashboard', 'side' );

    // Añade el widget personalizado
    wp_add_dashboard_widget(
        'ayudawp_custom_news',
        'Últimas noticias',  // Cambia el título a lo que quieras
        'ayudawp_custom_news_widget_output'
    );
}

function ayudawp_custom_news_widget_output() {
    // === PERSONALIZA AQUÍ ===
    // Añade o quita feeds a tu gusto
    $feeds = array(
        array(
            'url'   => 'https://ayudawp.com/feed/',
            'title' => 'Ayuda WordPress',
        ),
        array(
            'url'   => 'https://es.wordpress.org/news/feed/',
            'title' => 'WordPress España',
        ),
    );

    $items_per_feed = 3;  // Elementos por feed
    $max_items      = 8;  // Máximo total de elementos
    // === FIN DE PERSONALIZACIÓN ===

    include_once ABSPATH . WPINC . '/feed.php';

    $all_items = array();

    foreach ( $feeds as $feed_data ) {
        $rss = fetch_feed( $feed_data['url'] );

        if ( is_wp_error( $rss ) ) {
            continue;
        }

        $feed_items = $rss->get_items( 0, $items_per_feed );

        foreach ( $feed_items as $item ) {
            $all_items[] = array(
                'title'  => esc_html( $item->get_title() ),
                'link'   => esc_url( $item->get_permalink() ),
                'date'   => $item->get_date( 'U' ),
                'source' => esc_html( $feed_data['title'] ),
            );
        }
    }

    if ( empty( $all_items ) ) {
        echo '<p>' . esc_html__( 'No hay noticias disponibles.', 'ayudawp' ) . '</p>';
        return;
    }

    // Ordena por fecha (más recientes primero)
    usort( $all_items, function ( $a, $b ) {
        return $b['date'] - $a['date'];
    } );

    // Limita al máximo configurado
    $all_items = array_slice( $all_items, 0, $max_items );

    echo '<div class="rss-widget"><ul>';

    foreach ( $all_items as $item ) {
        printf(
            '<li><a href="%s" target="_blank" rel="noopener">%s</a> <span class="rss-date">%s</span> <cite>%s</cite></li>',
            esc_url( $item['link'] ),
            esc_html( $item['title'] ),
            esc_html( date_i18n( get_option( 'date_format' ), $item['date'] ) ),
            esc_html( $item['source'] )
        );
    }

    echo '</ul></div>';
}

[imagen del widget de noticias personalizado en el escritorio de WordPress]

Este código hace tres cosas:

1. Quita el widget de noticias de WordPress por defecto
2. Añade uno nuevo con los feeds RSS que tú elijas
3. Los muestra ordenados por fecha.

Lo que tienes que tocar está al principio de la función ayudawp_custom_news_widget_output(), el array $feeds con las URLs y nombres de tus feeds, $items_per_feed para cuántos elementos quieres de cada feed, y $max_items para el total que se muestra en el widget. También puedes cambiar el título del widget en la línea de wp_add_dashboard_widget().

A diferencia del wp_widget_rss_output() que trae WordPress de serie, este código añade varios feeds y los mezcla ordenados por fecha, así ves las noticias más recientes de todas tus fuentes juntas.

Si quieres volver a mostrar el widget original de WordPress, solo tienes que quitar la línea del remove_meta_box().

Opción completa: plugin

Si necesitas más control, o si gestionas sitios para clientes y quieres que el escritorio muestre información útil sin tocar código, el plugin Periscopio te lo pone fácil.

Es un plugin gratuito que sustituye el widget de noticias por defecto por uno totalmente configurable desde una página de ajustes. Lo que te ofrece resumido, es esto:

• Feeds RSS ilimitados, con validación de URL antes de añadirlos y ordenados por fecha.
• Sección de eventos de la comunidad WordPress con localidad personalizable (los saca de la API de WordPress.org).
• Enlaces configurables en el pie del widget, tanto en la sección de eventos como en la de noticias.
• Título del widget editable.
• Caché configurable (de 1 a 72 horas) con opción de vaciarla manualmente.
• Posibilidad de ocultar el widget original de WordPress o dejarlo junto al tuyo.

Instalación y configuración

Lo instalas como cualquier otro plugin desde el directorio de WordPress.org. Una vez activado, ve a Ajustes > Periscopio y ahí tienes todo.

La página de ajustes está dividida en secciones al estilo clásico de WordPress. En la parte de feeds puedes añadir las URLs que quieras, y el plugin las valida antes de guardarlas para evitar errores.

También puedes configurar cuántos elementos quieres por feed y el máximo total.

Periscopio viene con cinco feeds preconfigurados (WordPress.org, el blog de Matt Mullenweg, Make WordPress, WordPress España y Ayuda WordPress), pero puedes cambiarlos todos desde el minuto cero.

¿Qué tal queda?

El widget queda integrado con el estilo nativo de WordPress, así que no desentona, pero con algún detalle que, aunque está mal que lo diga yo, mejora al widget que trae WordPress por defecto.

Los eventos aparecen arriba con información de WordCamps y quedadas cercanas a tu localidad, que puedes modificar, y debajo las noticias de tus feeds mezcladas y ordenadas por fecha.

¿Cuándo usar cada opción?

Si es para ti, para un proyecto concreto o simplemente quieres un par de feeds sin complicarte, el código te vale de sobra.

Si gestionas varios sitios, trabajas con clientes o necesitas la parte de eventos y una gestión de feeds más cómoda (con validación, caché y ajustes visuales), Periscopio te ahorra tiempo y te ofrece mucha más personalización a golpe de clic.

Para seguir enredando con códigos de este tipo relacionados con el mismo asunto, con los widgets de escritorio, también puedes probar como crear widgets de escritorio con contenido propio (no RSS) o añadir un formulario de soporte para tus clientes, tienes más ideas en el blog.

Y si lo que quieres es directamente limpiar el escritorio de cajas que no uses, también puedes hacerlo con un par de líneas de código.

Llevo unos días viendo circular tu manifiesto contra WordPress, eso que empezó como un tuit largo, luego ampliaste en tu blog y que hasta Matt Mullenweg te ofreció quedar por Zoom, como dijo, «aunque no sea para responder, solo para entender de dónde sacas estas conclusiones». Un exitazo.

Esta respuesta seguro que no llega tan lejos, está escrita por un bloguero hispano, y no solemos captar la atención del mundo anglo, por lo que sea, pero alguien la leerá.

Así que voy a tomarte aparte un momento, como un colega que lleva solo unos pocos más años que tú en esto, porque tu manifiesto tiene cosas con parte de razón, otras que son medias verdades y unas cuantas que son directamente falsas. Mezclarlas todas con el mismo volumen no es una llamada de atención, es ruido, o eso me ha parecido.

En lo que sí tienes razón

Vamos a empezar por lo que suscribo del todo, ¿te parece?

• La interfaz para desactivar comentarios en todo el sitio es un lío absurdo repartido por media docena de pantallas, tienes razón.  Yo mismo he compartido como quitar estas mierdas, pero sí, es un jaleo.
• El /wp-admin/options.php existe desde siempre, es súper útil, y no hay un solo enlace visible en el escritorio. Ahora, también te digo que esa pantalla de opciones al completo una burrada, y el 90% de los usuarios no deberían tocar ahí.
• El modo de recuperación mandando el aviso solo al email del admin principal cuando un sitio tiene varios administradores es un fallo de diseño de libro. Como todo en WordPress se puede personalizar con un sencillo filtro, pero razón tienes.
• Y sí, también, contribuir al core puede ser frustrante y lento.

Todo eso lo firmo contigo, son críticas lógicas, más que lógicas, tienes más razón que un santo.

Las medias verdades

Aquí empezamos a tener un problema tú y yo (dialéctico, por supuesto).

Dices que en una instalación limpia «XML-RPC está abierto de par en par» y «en cuanto publicas, los bots empiezan a hacer fuerza bruta contra wp-login», y estás mezclando dos cosas que no son lo mismo.

XML-RPC es un puerta abierta a posibles ataques, correcto, pero los ataques a wp-login.php son otro, y cualquier hosting decente (SiteGround, Kinsta, Cloudways) los frena de serie, y si tu hosting no lo hace tampoco necesitas un plugin de seguridad de 80 euros al año con mil opciones que no vas a tocar. Con uno pequeño y enfocado basta, y para eso tienes este gratuito, Vigilante, que hace eso y mucho más.

Luego dices que «necesitas un plugin para meta titles, descriptions, meta tags básicas, en 2026, no hay excusa, el SEO debería ser nativo».

Marcin, querido amigo, WordPress tiene mapas del sitio nativos desde la versión 5.5, tiene wp_robots, tiene canonical automático, las title tags los gestiona el tema con title-tag desde hace una década. Lo que no tiene es un panel tipo Yoast, y eso es otra cosa muy distinta a «no tiene SEO».

Los huecos que deja el core se tapan con plugins pequeños y enfocados, no con un stack de diez suscripciones anuales como pintas tú. Yo mismo tengo compartidos gratis tres que ejemplifican justo lo contrario de lo que denuncias:

• Automatic Open Graph Tags, un sencillo código (o plugin si lo prefieres) que añade Open Graph y Twitter Cards sin configuración. Cero ajustes, cero suscripciones, gratis del todo.
• Native Sitemap Customizer, que te deja personalizar el mapa del sitio que ya trae WordPress, sin instalar otro plugin que reinvente la rueda.
• NoIndexer, para marcar noindex selectivo en contenidos concretos.

Los tres son gratis, los tres hacen una sola cosa y la hacen bien, los tres son gratis y disponibles para quien quiera utilizarlos, ninguno tiene versión pro, ni suscripción, ni muro de pago. Así que lo de «WordPress te obliga a un stack de plugins de pago para tener SEO» es falso. Hay ecosistema de sobra, y encima gratis, pero hay que buscarlo.

Otra que (casi) me ha dolido leer: «…el hosting es barato porque WordPress funciona en PHP antiguo y en servidores compartidos cutres». Esto es falso de principio a fin.

El core admite PHP 8.3, el mínimo recomendado lo suben con cada versión, y si tu hosting te deja tirado en PHP 7.2 el problema es tu hosting no WordPress. Echarle la culpa al CMS de que el hosting barato sea malo es como culpar al coche de que la gasolina sea de garrafa.

Y, aunque ya te he dicho antes que te suscribo la mayor en esto de contribuir al core, la anécdota del «cogí un bug de la lista de good first bugs, mandé mi PR y nadie me contestó» es ¿cómo decirte?.

Vale, contribuir al core es lento, a veces una putada, eso lo he suscrito, lo firmo si quieres, pero tu anécdota no demuestra que sea imposible, lo que demuestra es que con una experiencia, la tuya, te desanimaste y escribiste un manifiesto. Que es perfectamente legítimo, no digo que no lo sea, solo faltaría, pero no es lo mismo.

Yo mismo he mandado reportes en varias ocasiones y el baile de cambio de sitios donde informar llega a ser hasta molesto, pero bueno, luego me acuerdo de que todos somos voluntarios (por si se te había olvidado) y se me pasa y a otra cosa.

Así se critica WordPress

Aquí viene la parte que más me gusta de todo esto, porque mientras tras escribir tu manifiesto, Nick Hamze leyó lo mismo que hemos leído todos y pensó otra cosa…

De todos los puntos de tu manifiesto lo del modo de recuperación era el único con un fallo concreto y en el que se podía aportar algo funcional. Así que en vez de escribir otra réplica, Nick hizo algo distinto, cogió el bug, escribió el parche, lo acompañó de cuatro tests unitarios, investigó los tickets de Trac relacionados (el #51267, el #47192, el #47352, el #47939) y lo publicó en un gist listo para que alguien lo lleve al core.

Incluye hasta el razonamiento de por qué el parche es defendible pese al ticket que se cerró como «invalid» en 2020, y sugiere cómo plantearlo en Trac si hay reticencias.

Eso es contribuir. Eso, en un rato de sábado por la mañana, vale más que todo tu manifiesto junto, y que este post mío. Desmonta tu queja principal, la de «no se puede aportar a core, el pipeline está cerrado», mejor que cualquier argumento que yo te pueda dar. Nick no ha pedido permiso, no ha esperado a que alguien le conteste en Slack, no ha escrito sobre lo roto que está el sistema, ha escrito el código, ha hecho WordPress.

Lo que no se puede rebatir, solo discutir

Queda la parte grande de tu manifiesto, la de Automattic, WP Engine, la GPL como «estafa», la «comunidad» como ficción. Aquí no hay hechos que rebatir, hay una visión, una opinión. Y las opiniones se debaten, no se discuten ni desmontan.

Mi visión rápida es que sí, hay tensiones, y sí, Automattic es una empresa que extrae valor. Otro sí es que el caso WP Engine es feo y ha dejado mal sabor a mucha gente, yo mismo llevo un año criticando estas posturas.

Ahora bien, llamar a todo esto «un estanque con un solo pez grande» ignora que hay miles de desarrolladores ganándose la vida con WordPress sin que Automattic se les haya comido nada, cientos de plugins pequeños honestos, comunidades locales que sí funcionan, yo mismo he ayudado a organizar unas cuantas y te aseguro que la gente no va a WordCamp Logroño o la Meetup de Sevilla porque Automattic les obligue.

Tu retrato es cinematográfico, queda muy bien, pero no cuadra con lo que yo veo cada día.

Y la teoría de que «nadie en el poder quiere que core sea bueno porque se cargaría a los desarrolladores de plugins» es, con todo el cariño, una tontería que mejora las de Automattic, que las tiene, convirtiéndola en villana cuando la realidad es mucho más aburrida, y es que el core va lento porque tiene 20 años de deuda técnica, millones de sitios que no pueden romper, y un equipo humano limitado.

Ni conspiración ni colapso, solo software viejo.

Querido Marcin, para cerrar

Entiendo tu frustración después de 15 años, yo llevo algunos más y también me frustro con WordPress a menudo.

Pero también te digo que escribir un manifiesto con más pasión que datos, mezclar bugs reales con teorías sobre el pez grande que se come a los pequeños y llamar «colapso hasta en el calendario» a un CMS que mueve el 43% de la web no es una llamada a las armas, más parece un hilo de X buscando ruido. Algo ya lo sabes tú, porque cuando Mullenweg te respondió ofreciéndote sentaros a hablarlo, tu primera reacción fue dudar de si iba en serio.

WordPress tiene problemas, varios, y algunos de los que señalas son reales, pero se arreglan como hizo Nick Hamze, con un .diff y cuatro tests unitarios, o compartiendo plugins gratis y tutoriales a diario desde hace 20 años, como este humilde bloguero español, no con un manifiesto en Twitter.

Un abrazo desde España, de un veterano a otro. Ya me perdonarás los puntillos de ironía, pero seguro que si coincidimos en persona entenderás que soy un poco capullo, es mi particular sentido del (cuestionable) humor.

Al abrir una entrada que otro usuario ya está editando, en lugar de entrar en modo colaborativo, WordPress te muestra el aviso «Esta entrada ya está siendo editada» de siempre, pero con un cambio, este mensaje añadido:

«Debido a que esta entrada usa plugins que no son compatibles con la colaboración en tiempo real solo una persona puede editarla al mismo tiempo.»

Te da dos opciones, o «Tomar posesión» o «Salir del editor«, o sea, el bloqueo de siempre. Y lo más frustrante es que no te dice qué plugin es el incompatible, ni un nombre, ni una pista, te toca adivinarlo.

En este artículo te explico por qué sale este aviso, cómo encontrar el plugin que lo provoca, qué hacer si no eres desarrollador, y cómo corregir la incompatibilidad si mantienes plugins propios, con ejemplo real incluido.

Pero no adelantemos acontecimientos, que igual no sabes qué leches es esto de la colaboración en tiempo real. Te lo cuento.

Qué es la colaboración en tiempo real de WordPress

Hasta ahora, cuando alguien estaba editando una entrada en WordPress, el resto de usuarios quedaban bloqueados. Podías tomar posesión del post o irte, pero editar a la vez no era posible. Desde WordPress 7.0 esto cambia.

La colaboración en tiempo real (RTC) permite que dos o más personas editen el mismo contenido a la vez. Ves el cursor del otro usuario, sus cambios aparecen en tu pantalla al momento y el sistema se encarga de que no haya conflictos. Por debajo usa Yjs, una librería del tipo CRDT (Conflict-free Replicated Data Type) que resuelve los conflictos de edición sin perder datos.

Por defecto, WordPress usa HTTP polling como transporte, lo que significa que los clientes envían y reciben cambios a través de peticiones HTTP normales. No es lo más rápido del mundo, pero funciona en cualquier hosting sin necesidad de WebSockets ni configuración especial. Los proveedores de hosting que quieran ofrecer una experiencia mejor pueden sustituir el transporte por WebSockets usando el filtro sync.providers.

Desde las primeras betas de WordPress 7.0, la funcionalidad se ha podido activar manualmente desde Ajustes > Escritura, marcando la casilla ahí incluida, que por defecto se decidió que estuviese inactiva por defecto, ya que en realidad es muy poca gente quien va a usar esta herramienta y consume recursos.

También hay una constante, WP_ALLOW_COLLABORATION que puedes añadir en wp-config.php y permite activar o desactivar la funcionalidad si pasar por los ajustes, así:

define( 'WP_ALLOW_COLLABORATION', true );

Cómo funcionan las tripas de la sincronización en la RTC

La sincronización, como te acabo de comentar, se basa en Yjs, una librería de CRDT que permite que varios clientes editen el mismo documento sin coordinación central. Cada cambio se codifica como una operación CRDT que se puede aplicar en cualquier orden y siempre lleva al mismo resultado.

El proveedor de transporte mediante HTTP polling hace que los clientes envíen y reciban actualizaciones a través de la REST API de WordPress. Los datos CRDT se almacenan en post_meta en un tipo de contenido interno llamado wp_sync_storage (uno por documento). Las actualizaciones se agrupan en lotes y se compactan periódicamente.

WordPress 7.0 limita inicialmente la colaboración a dos usuarios simultáneos para proteger a los hosting. El equipo de desarrollo ha mencionado varias veces que será configurable desde el wp-config, pero a fecha de hoy todavía no se ha documentado el nombre concreto de esa constante. Los proveedores de hosting también pueden sustituir el transporte HTTP por WebSockets usando el filtro sync.providers para una latencia menor y mejor rendimiento con más usuarios.

Todo lo que pasa por los data stores de WordPress (core/editor, core/block-editor) se sincroniza automáticamente. Eso incluye los atributos de los bloques, el título, el extracto y el post meta registrado con show_in_rest. Lo que no pasa por esos data stores (meta boxes clásicas, handlers de save_post, scripts que modifican el DOM directamente) no se sincroniza.

Lo sé, es un poco técnico, pero es que este artículo es tanto para usuarios como para desarrolladores. No voy a hacer preguntas ni cuenta como nota para examen alguno. Seguimos…

Por qué sale el aviso de plugins no compatibles

La colaboración en tiempo real sincroniza el estado del editor a través de los almacenamientos de datos de WordPress y Yjs. Todo lo que pasa por ahí (atributos de bloques, post meta registrado con show_in_rest) se sincroniza automáticamente entre los usuarios conectados.

Pero las cajas meta clásicas no pasan por ahí. Una caja meta clásica (registrada con add_meta_box()) procesa HTML directamente y guarda sus datos a través de un gancho de save_post. Ese flujo no tiene nada que ver con el almacenamiento de datos de Gutenberg, así que los cambios que hagas en una caja meta clásica no se sincronizan con el otro usuario. Si los dos editáis a la vez, uno puede machacar los cambios del otro sin darse cuenta.

Para evitar eso, WordPress toma una decisión radical, y es que si detecta que hay cajas meta clásicas registradas en el editor desactiva la colaboración entera y te muestra el aviso. No intenta sincronizar unas cosas sí y otras no, simplemente la apaga.

Cómo encontrar el plugin culpable

Esta es la parte que a todo el mundo le interesa, seas usuario o desarrollador. WordPress no te dice qué plugin es, así que te toca investigar. Hay varias formas de hacerlo, de más fácil a más técnica.

Descarte por desactivación (el más fiable)

La forma más rápida y segura de identificar el plugin que bloquea la colaboración es esta:

1. Asegúrate de que la colaboración en tiempo real está activada en Ajustes > Escritura.
2. Desactiva todos los plugins.
3. Abre una entrada con dos usuarios a la vez y comprueba que la colaboración funciona (deberías ver el cursor del otro usuario).
4. Ve activando los plugins uno a uno.
5. Después de activar cada plugin, vuelve a abrir la entrada con los dos usuarios.
6. Cuando la colaboración deje de funcionar y te vuelva a salir el aviso, ese es el plugin problemático.

Es el método clásico de descarte. Lleva un rato, pero no falla, es gratis y tiene cero curva de aprendizaje, es para todos los públicos.

Mirar la parte inferior del editor

Fíjate en la captura del aviso, en la parte inferior de la pantalla del editor se ve el texto «Cajas meta» con un desplegable.

Si algún plugin ha registrado cajas meta en ese contenido las verás listadas ahí. Eso ya te da una pista de cuáles son los candidatos, pero no es definitivo, porque a veces tampoco el editor las coloca ahí abajo.

Buscar en el código (para desarrolladores)

Si tienes acceso por SSH o FTP a tu servidor, un grep rápido te da la lista de todos los plugins que registran meta boxes:

grep -r "add_meta_box" wp-content/plugins/ --include="*.php" -l

Nota importante: No todos los plugins que registran cajas meta causan el problema. Solo los que las registran en tipos de contenido donde quieras usar la colaboración. Un plugin que solo registra cajas meta en una pantalla de ajustes o en un tipo de contenido personalizado que no uses para colaborar no va a interferir.

Query Monitor

Esa joya de plugin por el que nunca estaremos suficientemente agradecidos, Query Monitor, te muestra las cajas meta registradas y qué componente las ha registrado. Con eso puedes identificar rápidamente qué plugin está añadiendo cajas meta al editor.

Qué hacer si no eres desarrollador

Si has identificado el plugin que causa el problema y no tienes ni idea de programación tienes dos opciones, ambas igual de válidas, pero mejor siempre la primera.

Contactar con el desarrollador del plugin

Esta es la mejor opción. Ve al repositorio del plugin en WordPress.org, busca el foro de soporte y abre un hilo explicando el problema. Algo así:

«He activado la colaboración en tiempo real de WordPress 7.0 y el editor me muestra el aviso ‘Debido a que esta entrada usa plugins que no son compatibles con la colaboración en tiempo real solo una persona puede editarla al mismo tiempo’. He comprobado por descarte que el plugin que lo provoca es el vuestro. ¿Tenéis previsto hacerlo compatible?»

Si el desarrollador del plugin lee español, puedes enlazarle este artículo directamente, que más abajo tiene la explicación técnica y el código necesario para hacer la corrección. Si solo lee inglés, la nota oficial de desarrollo y el documento de problemas comunes de VIP tienen toda la información que necesita.

Decidir qué prefieres: el plugin o la colaboración

Mientras el desarrollador actualiza el plugin (si lo hace) tienes que elegir. Si la funcionalidad que aporta el plugin no es imprescindible para ti, desactívalo y disfruta de la colaboración en tiempo real. Si el plugin te hace más falta que la colaboración déjalo activo y sigue editando como siempre, con el bloqueo de edición compartida de siempre.

No es la situación ideal, pero es la realidad de una versión mayor que cambia algo tan de base como el modelo de edición de WordPress. Con el tiempo, la mayoría de plugins se irán adaptando.

Los cuatro problemas de compatibilidad más comunes (para desarrolladores)

A partir de aquí el artículo se pone más técnico. Si desarrollas o mantienes plugins de WordPress, esto te interesa. La dev note oficial y la documentación de WordPress VIP identifican cuatro patrones que causan problemas con la colaboración en tiempo real.

Cajas meta clásicas (el caso más frecuente)

Si tu plugin registra una meta box con add_meta_box() y guarda datos con un gancho de save_post, WordPress desactiva la colaboración para ese tipo de post. Da igual que la meta box sea pequeña o que solo tenga un checkbox. Si está ahí, la colaboración se apaga.

La solución es migrar la funcionalidad a un panel en el sidebar del editor de bloques (usando PluginDocumentSettingPanel) y asegurarte de que el post meta esté registrado con show_in_rest => true. La meta box clásica puedes mantenerla como fallback para el editor clásico.

Inputs no controlados que no reflejan cambios externos

Esto afecta a plugins que ya tienen interfaz en el editor de bloques, pero la han construido usando defaultValue en lugar de value en los inputs. Un input con defaultValue solo responde a lo que escribe el usuario local, no a los cambios que llegan de otros clientes.

La solución: usa siempre inputs controlados con value, derivando ese valor del data store de WordPress con useSelect.

Estado local con useState que desconecta del data store

Otro error habitual: copiar el valor del data store a un useState local. En el momento que haces eso, tu componente se desconecta del estado compartido. Las actualizaciones de otros usuarios llegan al data store, pero tu componente sigue mostrando la copia local que hizo al montarse.

La regla: no copies datos compartidos a useState. Lee siempre directamente del data store.

Bloques con efectos secundarios al insertarse

Si tienes un bloque personalizado que abre un modal automáticamente cuando se inserta, ese modal se abrirá para todos los usuarios conectados, porque el contenido del bloque se sincroniza de inmediato.

La solución: en lugar de abrir el modal automáticamente, muestra un placeholder con un botón que abra el modal al hacer clic. Así el efecto es local y voluntario.

Ejemplo práctico: Adaptando el plugin AI Share & Summarize

Vamos a verlo con un caso real, mi plugin AI Share & Summarize, que tiene una caja meta en la barra lateral del editor que permite ocultar los botones de compartir en entradas o páginas individuales. Es una casilla sencilla, pero esa caja meta clásica es suficiente para que WordPress desactive la colaboración en tiempo real en todos los tipos de contenido donde esté registrada. Pequeñita pero potente ¿no?

Vamos a ver el código actual, entender por qué falla y hacer las modificaciones necesarias paso a paso.

El código actual y por qué causa el problema

El archivo includes/class-meta-box.php del plugin hace tres cosas: registra el post meta con register_post_meta() y show_in_rest => true (esto está bien hecho), registra una caja meta clásica con add_meta_box() (esto causa el problema) y guarda los datos desde un gancho de save_post (necesario para el editor clásico, pero innecesario en el de bloques).

La buena noticia es que la parte más complicada ya está resuelta, porque el meta está correctamente registrado para la REST API. Solo necesitamos cuatro cambios.

Paso 1: Añadir revisions_enabled al registro del meta

La nota para desarrolladores de WordPress 7.0 recomienda que el post meta registrado para la colaboración tenga revisions_enabled => true. Esto hace que los cambios en el meta se registren en el historial de revisiones, algo que viene muy bien cuando hay varios editores trabajando a la vez.

En el método ayudawp_register_meta(), añade el parámetro:

public function ayudawp_register_meta() {
    $post_types = get_post_types( array( 'public' => true ), 'names' );

    foreach ( $post_types as $post_type ) {
        register_post_meta( $post_type, self::META_KEY, array(
            'show_in_rest'      => true,
            'single'            => true,
            'type'              => 'boolean',
            'default'           => false,
            'revisions_enabled' => true, // Track changes in revision history.
            'auth_callback'     => function() {
                return current_user_can( 'edit_posts' );
            },
        ) );
    }
}

Paso 2: Registrar la meta box solo en el editor clásico

Este es el cambio clave. Necesitamos que add_meta_box() solo se ejecute cuando estemos en el editor clásico. Cuando el editor de bloques esté activo, no registramos la meta box, y eso permite que la colaboración funcione.

Modifica el método ayudawp_add_meta_box():

public function ayudawp_add_meta_box() {
    $post_types = get_post_types( array( 'public' => true ), 'names' );

    foreach ( $post_types as $post_type ) {
        // Skip if the block editor is active for this post type.
        if ( function_exists( 'use_block_editor_for_post_type' )
            && use_block_editor_for_post_type( $post_type )
        ) {
            continue;
        }

        add_meta_box(
            'ayudawp_aiss_exclude_metabox',
            __( 'AI Share & Summarize', 'ai-share-summarize' ),
            array( $this, 'ayudawp_render_meta_box' ),
            $post_type,
            'side',
            'default'
        );
    }
}

Con este cambio, los usuarios del editor clásico siguen teniendo la meta box de siempre. Los que usen el editor de bloques no la verán, y la colaboración no se desactivará.

Paso 3: Crear un panel en la barra lateral del editor de bloques

Ahora necesitamos que los usuarios del editor de bloques puedan seguir ocultando los botones en entradas individuales. Para eso toca crear un panel en la barra lateral del editor usando PluginDocumentSettingPanel.

Creamos (bueno, yo en este ejemplo, que el plugin es mío) un nuevo archivo assets/js/editor-sidebar.js:

/**
 * AI Share & Summarize - Block Editor Sidebar Panel
 *
 * Replaces the classic meta box in the block editor with a sidebar panel
 * compatible with WordPress 7.0 real-time collaboration.
 */
( function () {
    var el              = wp.element.createElement;
    var registerPlugin  = wp.plugins.registerPlugin;
    var PluginDocPanel  = wp.editor.PluginDocumentSettingPanel
                          || wp.editPost.PluginDocumentSettingPanel;
    var CheckboxControl = wp.components.CheckboxControl;
    var useSelect       = wp.data.useSelect;
    var useDispatch     = wp.data.useDispatch;
    var __              = wp.i18n.__;

    /**
     * Sidebar panel component
     *
     * Reads the exclusion meta value directly from the data store
     * using a controlled input. This keeps the panel in sync across
     * all connected editors during real-time collaboration.
     */
    function AissExcludePanel() {
        // Always read from the data store, never from local state.
        var isExcluded = useSelect( function ( select ) {
            var meta = select( 'core/editor' ).getEditedPostAttribute( 'meta' );
            return meta && meta._ayudawp_aiss_exclude ? true : false;
        }, [] );

        var editPost = useDispatch( 'core/editor' ).editPost;

        return el(
            PluginDocPanel,
            {
                name: 'aiss-exclude-panel',
                title: 'AI Share & Summarize',
                icon: 'share',
            },
            el( CheckboxControl, {
                label: __( 'Hide share buttons on this content', 'ai-share-summarize' ),
                checked: isExcluded,
                onChange: function ( value ) {
                    editPost( { meta: { _ayudawp_aiss_exclude: value } } );
                },
                help: __(
                    'Check this box to prevent the share and AI buttons from appearing on this specific content.',
                    'ai-share-summarize'
                ),
            } )
        );
    }

    registerPlugin( 'aiss-exclude-panel', {
        render: AissExcludePanel,
        icon: 'share',
    } );
} )();

Hay varios detalles importantes en este código. El valor del checkbox se lee siempre del data store con useSelect, nunca se copia a un useState local. El input usa checked (controlado), no defaultChecked. Y los cambios se escriben directamente al data store con editPost. Esos tres puntos son los que garantizan que el panel funcione correctamente cuando varios usuarios editan a la vez.

El archivo no necesita JSX ni siquiera proceso de build. Usa wp.element.createElement directamente, así que funciona tal cual.

Paso 4: Encolar el script en el editor de bloques

Ahora hay que decirle a WordPress que cargue ese script cuando se abra el editor de bloques. Añade el gancho en el constructor de la clase y el nuevo método:

En el constructor:

public function __construct() {
    add_action( 'add_meta_boxes', array( $this, 'ayudawp_add_meta_box' ) );
    add_action( 'save_post', array( $this, 'ayudawp_save_meta_box' ), 10, 2 );
    add_action( 'init', array( $this, 'ayudawp_register_meta' ) );
    add_action( 'enqueue_block_editor_assets', array( $this, 'ayudawp_enqueue_editor_sidebar' ) );
}

Y el nuevo método:

public function ayudawp_enqueue_editor_sidebar() {
    wp_enqueue_script(
        'ayudawp-aiss-editor-sidebar',
        AYUDAWP_AISS_PLUGIN_URL . 'assets/js/editor-sidebar.js',
        array( 'wp-plugins', 'wp-editor', 'wp-components', 'wp-data', 'wp-element', 'wp-i18n' ),
        AYUDAWP_AISS_VERSION,
        true
    );
}

El gancho enqueue_block_editor_assets se dispara solo cuando se carga el editor de bloques, así que el script no se carga en ningún otro sitio.

El archivo completo modificado

Para que no tengas que ir juntando piezas, abajo tienes el archivo includes/class-meta-box.php completo con todos los cambios aplicados, para que veas el resultado final por si te sirve para tu plugin. Puedes descargarlo directamente desde el enlace que he puesto al final del artículo.

Qué pasa con los datos existentes

Las entradas que ya tenían la casilla marcado con la caja meta clásica siguen funcionando con el panel nuevo sin tocar nada. Ambos sistemas leen y escriben en la misma clave de meta (_ayudawp_aiss_exclude). El editor clásico guarda el valor como string '1' y el editor de bloques lo guarda como booleano true, pero la función ayudawp_is_post_excluded() hace un cast a booleano con (bool), así que las dos representaciones funcionan bien. No hay que migrar datos.

Probar la colaboración

Con los cambios hechos, los pasos para comprobar que todo funciona:

1. Asegúrate de tener WordPress 7.0 instalado y la colaboración activada en los ajustes de escritura
2. Abre una entrada en el editor de bloques con dos usuarios distintos. Si todo va bien verás el cursor del otro usuario en el editor y podréis editar a la vez sin que salte el aviso
3. Revisa que el panel «AI Share & Summarize» (o el tuyo, claro) aparece en la barra lateral de la pestaña «Entrada» (no confundir con la pestaña «Bloque»)
4. Marca y desmarca la casilla desde ambas sesiones y comprueba que el cambio se refleja en la otra

Resumen de los cambios para desarrolladores

Para que quede claro qué archivos se tocan y qué cambia en cada uno:

En includes/class-meta-box.php se hacen cuatro modificaciones: se añade revisions_enabled => true al register_post_meta(), se condiciona add_meta_box() para que solo se registre en el editor clásico, se añade el gancho enqueue_block_editor_assets en el constructor, y se añade el método ayudawp_enqueue_editor_sidebar() para encolar el script.

Se crea un archivo nuevo, assets/js/editor-sidebar.js, con el panel del sidebar para el editor de bloques.

No se toca nada más. El handler de save_post se mantiene porque sigue siendo necesario para el editor clásico. La función ayudawp_is_post_excluded() también se mantiene porque lee de la misma clave de meta sea cual sea el editor que la haya guardado.

Resumen de comprobación de compatibilidad de RTC para plugins

Si mantienes plugins de WordPress y quieres que sean compatibles con la colaboración en tiempo real de WordPress 7.0, repasa estos puntos.

Cajas meta

Comprueba si tu plugin registra meta boxes con add_meta_box(). Si lo hace, tienes dos opciones: eliminar la meta box y sustituirla por un panel en el sidebar del editor de bloques, o mantener la meta box solo para el editor clásico y crear el panel en paralelo (como en el ejemplo de arriba). Para cualquiera de las dos opciones, el post meta tiene que estar registrado con register_post_meta() y show_in_rest => true.

Componentes JavaScript

Revisa que todos tus componentes que leen datos compartidos (meta, atributos de bloques) los lean directamente del data store con useSelect. No copies esos valores a useState. Usa inputs controlados (value y checked), no inputs no controlados (defaultValue y defaultChecked).

Efectos secundarios

Si alguno de tus bloques ejecuta código automáticamente al insertarse (abrir un modal, hacer una petición HTTP, disparar un evento), ten en cuenta que ese efecto se ejecutará en todas las sesiones conectadas. Convierte esos disparadores automáticos en acciones manuales para que solo afecten al usuario que los inicia.

Revisiones

Añade revisions_enabled => true a los post meta que modifiques desde el editor. Así el historial de revisiones recoge los cambios en el meta y no solo en el contenido de la entrada.

Cómo desactivar la colaboración desde un plugin

Puede que tengas un plugin donde la colaboración cause problemas que no puedes resolver de momento, o que quieras desactivarla durante un despliegue gradual. Hay una forma limpia de hacerlo sin tocar nada de WordPress.

El filtro sync.providers controla qué proveedores de sincronización están activos. Si devuelves un array vacío la colaboración se desactiva:

import { addFilter } from '@wordpress/hooks';

addFilter( 'sync.providers', 'my-plugin/disable-collab', () => [] );

Esto es temporal y limpio. No afecta a ninguna otra funcionalidad del editor.

Documentación y recursos

Los enlaces a la documentación oficial para profundizar en todo lo que hemos visto:

• Nota oficial de desarrollo de la colaboración en tiempo real – La referencia principal. Cubre las meta boxes, el filtro sync.providers y los problemas comunes para plugins.
• Guía para probar la colaboración en tiempo real – Escenarios de prueba detallados y cómo configurar tu entorno.
• Feedback temprano de usuarios de VIP – Lecciones aprendidas de los primeros usuarios en producción.
• COMMON_ISSUES.md del repositorio de VIP – Ejemplos detallados de código con los anti-patrones más frecuentes y sus correcciones.
• Guía de migración de meta boxes en el Block Editor Handbook.
• Issue de seguimiento #52593 en el repositorio de Gutenberg.
• Clase meta box de Ai Share & Summarize usada en el ejemplo.

Si te ha saltado el aviso de plugins no compatibles y has conseguido identificar cuál era el culpable (o si eres desarrollador y has adaptado tu plugin), cuéntamelo en los comentarios.

Saber qué plugins dan problemas con la colaboración en tiempo real nos viene bien a todos, y si tienes dudas con la migración de cajas meta también te puedo echar una mano por ahí.

La funcionalidad se llama PHP-only block registration y llega gracias al flag autoRegister en la función register_block_type(). Registras tu bloque con PHP, defines los atributos, escribes el callback de renderizado y WordPress se encarga del resto: el bloque aparece en el insertador del editor y genera automáticamente los controles en el panel lateral para que el usuario pueda configurarlo.

¿Es un sustituto de los bloques JavaScript completos? Pues no, y tampoco pretende serlo.

Está pensado para bloques que solo necesitan renderizado del lado del servidor, los típicos que muestran datos dinámicos (últimas entradas, cajas de autor, alertas, widgets de datos) y que no requieren edición en tiempo real dentro del editor.

Para estos casos, que son la mayoría de los que necesita un desarrollador PHP en su día a día, es una solución limpia y sin complicaciones.

En esta guía tienes todo lo necesario para empezar a crear tus propios bloques PHP-only, desde la referencia técnica completa, explicada como yo la he entendido, hasta tres ejemplos prácticos que van de menos a más:

1. Un bloque creado desde cero
2. Migración de un shortcode clásico a bloque
3. Integración real de un bloque en un plugin ya publicado en WordPress.org.

Requisitos para seguir este tutorial: Todos los códigos de esta guía necesitan que tengas instalado ya WordPress 7.0 o superior, disponible desde el 9 de abril de 2026. Si quieres probarlo antes de esa fecha puedes instalar la última beta de WordPress 7.0 con el plugin WordPress Beta Tester o el plugin Gutenberg en un sitio de pruebas. En versiones anteriores de WordPress el flag autoRegister (a continuación lo explico) se ignora y los bloques no aparecerán en el editor.

Cómo funciona autoRegister

Lo que tienes a continuación es la referencia técnica que necesitas como desarrollador PHP para trabajar con esta API. Lo he preparado para que no tengas que ir a buscar en la documentación en inglés cada vez que quieras consultar algo, y por si te sirve mi manera de explicar las cosas.

La estructura básica

Un bloque PHP-only se registra con register_block_type() en el hook init, como cualquier otro bloque, pero con dos requisitos obligatorios:

• El flag autoRegister a true dentro de supports
• Un render_callback que devuelva el HTML del bloque

Demostración, como diría el Malaguita…

add_action( 'init', 'ayudawp_register_my_block' );

function ayudawp_register_my_block() {
    register_block_type(
        'mi-plugin/mi-bloque',
        array(
            'title'           => 'Mi bloque',
            'icon'            => 'admin-generic',
            'category'        => 'widgets',
            'description'     => 'Descripción del bloque.',
            'keywords'        => array( 'ejemplo', 'php' ),
            'attributes'      => array(
                // Aquí van los atributos
            ),
            'render_callback' => 'ayudawp_render_my_block',
            'supports'        => array(
                'autoRegister' => true,
            ),
        )
    );
}

function ayudawp_render_my_block( $attributes ) {
    $wrapper = get_block_wrapper_attributes();
    return sprintf( '<div %s>Contenido del bloque</div>', $wrapper );
}

Cuando WordPress detecta el flag autoRegister registra automáticamente el bloque en el editor del lado del cliente a través de un global JavaScript (autoRegisterBlocks) y utiliza ServerSideRender para la previsualización.

O sea, cada vez que el usuario cambia un atributo en el panel lateral el editor hace una llamada a la API REST de WordPress, ejecuta tu render_callback en PHP y muestra el resultado. Sencillo, limpio, eficaz, como es PHP.

Tipos de atributos y controles automáticos

La gracia de autoRegister es que WordPress genera automáticamente los controles del Inspector (panel lateral del editor) a partir de los atributos que definas. Pero no todos los tipos generan controles, solo los que WordPress sabe representar como campo de formulario.

Estos son los tipos admitidos y el control que genera cada uno:

Los atributos que no encajen en estos tipos (arrays, objetos) o los que tengan el rol local no generan ningún control en el panel.

Un detalle importante es que definas siempre un valor default para cada atributo. Si no lo haces el bloque puede no renderizar nada la primera vez que lo insertes, porque los atributos llegarán vacíos al callback.

Así se definen los atributos en la práctica, cubriendo los cuatro tipos:

'attributes' => array(
    // String → TextControl
    'titulo' => array(
        'type'    => 'string',
        'default' => 'Título por defecto',
    ),
    // String con enum → SelectControl
    'tamano' => array(
        'type'    => 'string',
        'enum'    => array( 'pequeno', 'mediano', 'grande' ),
        'default' => 'mediano',
    ),
    // Integer → NumberControl
    'cantidad' => array(
        'type'    => 'integer',
        'default' => 5,
    ),
    // Boolean → ToggleControl
    'mostrar_fecha' => array(
        'type'    => 'boolean',
        'default' => true,
    ),
),

Los supports nativos funcionan igual

Además de autoRegister, puedes activar los mismos supports que en cualquier bloque (color, espaciado, tipografía, bordes). WordPress aplicará los estilos heredados del tema activo sin que tengas que escribir CSS propio.

'supports' => array(
    'autoRegister' => true,
    'color'        => array(
        'background' => true,
        'text'       => true,
    ),
    'spacing'      => array(
        'margin'  => true,
        'padding' => true,
    ),
    'typography'   => array(
        'fontSize' => true,
    ),
),

Cuando activas estos supports WordPress añade los controles correspondientes en el panel lateral (selector de color, controles de márgenes, etc.) y aplica las clases y estilos inline automáticamente. Para que funcionen correctamente en el HTML de salida, usa siempre get_block_wrapper_attributes() en tu callback de renderizado.

Cargar CSS y JavaScript

Si tu bloque necesita estilos propios o algún script, lo habitual es registrarlos en el hook init y con enqueue desde el callback. De esta forma solo se cargan en las páginas donde esté disponible el bloque.

add_action( 'init', 'ayudawp_register_block_assets' );

function ayudawp_register_block_assets() {
    wp_register_style(
        'ayudawp-mi-bloque-style',
        plugins_url( 'assets/css/mi-bloque.css', __FILE__ ),
        array(),
        '1.0.0'
    );
}

function ayudawp_render_my_block( $attributes ) {
    // Solo se encola cuando se renderiza el bloque
    wp_enqueue_style( 'ayudawp-mi-bloque-style' );

    $wrapper = get_block_wrapper_attributes();
    return sprintf( '<div %s>...</div>', $wrapper );
}

Ejemplo 1: Bloque de caja de información autor (desde cero)

Vamos con el primer ejemplo práctico, que es un bloque muy práctico que muestra la información de un autor de WordPress (avatar, nombre, biografía y enlace a su web). Lo vamos a crear como mu-plugin para que sea fácil de probar.

Este bloque tiene un detalle interesante, y es que el selector de autor se genera dinámicamente a partir de los usuarios de WordPress mediante un enum construido con get_users(). Es un buen ejemplo de cómo aprovechar toda la potencia de PHP dentro de la definición del bloque.

Crea el archivo dentro de /wp-content/mu-plugins/ayudawp-author-box-block.php con el siguiente contenido:

<?php
/**
* Plugin Name: Bloque de caja de autor (PHP)
* Plugin URI: https://servicios.ayudawp.com
* Description: Bloque de caja de autor registrado solo con PHP. Requiere WordPress 7.0 o superior o la última versión del plugin Gutenberg.
* Version: 1.0.0
* Author: Fernando Tellado
* Author URI: https://ayudawp.com
* License: GPL-2.0-or-later
* Requires PHP: 7.4
*/

// Prevent direct file access
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', 'ayudawp_register_author_box_block' );

/**
 * Register the author box PHP-only block.
 *
 * Generates the user list dynamically for the author selector.
 */
function ayudawp_register_author_box_block() {

    // Build the list of users for the selector
    $users    = get_users( array( 'fields' => array( 'ID', 'display_name' ) ) );
    $user_ids = array();

    foreach ( $users as $user ) {
        $user_ids[] = (string) $user->ID;
    }

    // If no users, fallback to avoid empty enum
    if ( empty( $user_ids ) ) {
        $user_ids = array( '1' );
    }

    register_block_type(
        'ayudawp/author-box',
        array(
            'title'           => __( 'Caja de autor', 'ayudawp' ),
            'icon'            => 'admin-users',
            'category'        => 'theme',
            'description'     => __( 'Muestra información del autor: avatar, nombre, biografía y sitio web.', 'ayudawp' ),
            'keywords'        => array( 'author', 'bio', 'avatar' ),
            'attributes'      => array(
                'user_id'      => array(
                    'type'    => 'string',
                    'enum'    => $user_ids,
                    'default' => $user_ids[0],
                ),
                'avatar_size'  => array(
                    'type'    => 'integer',
                    'default' => 96,
                ),
                'show_bio'     => array(
                    'type'    => 'boolean',
                    'default' => true,
                ),
                'show_website' => array(
                    'type'    => 'boolean',
                    'default' => true,
                ),
            ),
            'render_callback' => 'ayudawp_render_author_box_block',
            'supports'        => array(
                'autoRegister' => true,
                'color'        => array(
                    'background' => true,
                    'text'       => true,
                ),
                'spacing'      => array(
                    'padding' => true,
                    'margin'  => true,
                ),
            ),
        )
    );
}

/**
 * Render callback for the author box block.
 *
 * @param array $attributes Block attributes.
 * @return string Block HTML output.
 */
function ayudawp_render_author_box_block( $attributes ) {

    $user_id      = absint( $attributes['user_id'] ?? 1 );
    $avatar_size  = absint( $attributes['avatar_size'] ?? 96 );
    $show_bio     = (bool) ( $attributes['show_bio'] ?? true );
    $show_website = (bool) ( $attributes['show_website'] ?? true );

    $user = get_userdata( $user_id );

    if ( ! $user ) {
        return '';
    }

    $wrapper = get_block_wrapper_attributes(
        array(
            'style' => 'display:flex;gap:1.5em;align-items:flex-start;',
        )
    );

    $output  = sprintf( '<div %s>', $wrapper );
    $output .= get_avatar( $user_id, $avatar_size );
    $output .= '<div>';
    $output .= sprintf(
        '<strong style="font-size:1.2em;">%s</strong>',
        esc_html( $user->display_name )
    );

    if ( $show_bio && $user->description ) {
        $output .= sprintf(
            '<p style="margin-top:0.5em;">%s</p>',
            esc_html( $user->description )
        );
    }

    if ( $show_website && $user->user_url ) {
        $output .= sprintf(
            '<p><a href="%s" target="_blank" rel="noopener noreferrer">%s</a></p>',
            esc_url( $user->user_url ),
            esc_html( $user->user_url )
        );
    }

    $output .= '</div></div>';

    return $output;
}

Una vez guardado el archivo ve al editor de WordPress, busca «Caja de autor» en el insertador de bloques y deberías tenerlo disponible para insertarlo, hazlo.

Con el bloque ya insertado y seleccionado, en el panel lateral verás un desplegable con los IDs de los usuarios, un campo numérico para el tamaño del avatar y dos interruptores para mostrar u ocultar la biografía y el enlace web.

Además, si activas los supports de color y espaciado, podrás personalizar los colores de fondo y texto, y los márgenes y relleno directamente desde el editor.

Un apunte importante sobre el selector de usuarios es que el control SelectControl que genera WordPress muestra los valores del enum tal cual, en este caso los IDs numéricos de los usuarios. No es lo más elegante visualmente (lo ideal sería mostrar el nombre), pero es la limitación actual de la generación automática de controles.

Para un bloque de producción con un selector más refinado ya necesitarías JavaScript, pero para un uso interno o un tema personalizado funciona de sobra, y se ve perfecto.

Si quieres profundizar en otras formas de mostrar una caja de información del autor en WordPress, por si no te termina de convencer el uso del bloque, y te ha entrado la curiosidad y ganas de usar algo así, echa un vistazo a esta guía sobre cómo mostrar la información del autor sin plugins.

Ejemplo 2: Migrar el shortcode de entradas recientes a bloque

Ahora empieza la parte más interesante del tutorial, pues para empezar a darle caña a esto vamos a tomar un shortcode que ya funciona y convertirlo en un bloque PHP-only.

Usaremos como base el shortcode de entradas recientes que publiqué hace un tiempo, y lo vamos a mejorar de paso con un par de atributos nuevos.

Pero la mejora real no son los atributos extra, sino dónde puedes usar este bloque.

Como shortcode estabas limitado a pegarlo dentro del contenido de una entrada o página, como bloque PHP-only puedes insertarlo en cualquier plantilla del editor de sitio (la página de inicio, el pie de página, la plantilla de entradas individuales, la 404, etc.) sin depender de plugins ni tocar los archivos del tema.

El bloque nativo de últimas entradas de WordPress hace algo parecido, pero no te deja ordenar por número de comentarios, ni mostrar entradas aleatorias, ni activar el extracto con un interruptor, este sí.

El shortcode original

El shortcode [entradas_recientes] usa get_posts() para mostrar una lista de entradas filtrable por categoría, con parámetros de orden y cantidad. Así era el código:

function ayudawp_recent_posts_shortcode( $atts, $content = null ) {
    global $post;
    extract( shortcode_atts( array(
        'cat'     => '',
        'num'     => '5',
        'order'   => 'DESC',
        'orderby' => 'post_date',
    ), $atts ) );
    $args = array(
        'cat'            => $cat,
        'posts_per_page' => $num,
        'order'          => $order,
        'orderby'        => $orderby,
    );
    $output = '';
    $posts  = get_posts( $args );
    foreach ( $posts as $post ) {
        setup_postdata( $post );
        $output .= '<li><a href="' . get_the_permalink() . '">' . get_the_title() . '</a></li>';
    }
    wp_reset_postdata();
    return '<ul>' . $output . '</ul>';
}
add_shortcode( 'entradas_recientes', 'ayudawp_recent_posts_shortcode' );

Qué cambia al convertirlo en bloque

Los parámetros del shortcode se convierten en atributos del bloque, y cada uno se mapea al tipo que mejor encaje para generar un control automático en el editor:

Los dos atributos nuevos (show_date y show_excerpt) son de tipo boolean, así que generarán un interruptor cada uno en el panel lateral. De esta forma, en un solo ejemplo ves los cuatro tipos de control que genera autoRegister.

El bloque completo

Crea el archivo wp-content/mu-plugins/ayudawp-recent-posts-block.php:

<?php
/**
* Plugin Name: Bloque de entradas recientes
* Description: Bloque PHP-only de entradas recientes. Migración del shortcode [entradas_recientes]. Requiere WordPress 7.0 o superior, o el plugin Gutenberg 14.0+ en versiones anteriores.
* Plugin URI: https://servicios.ayudawp.com
* Version: 1.0.0
* Author: Fernando Tellado
* Author URI: https://ayudawp.com
* License: GPL-2.0-or-later
* Requires PHP: 7.4
*/

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', 'ayudawp_register_recent_posts_block' );

/**
 * Register the recent posts PHP-only block.
 */
function ayudawp_register_recent_posts_block() {
    register_block_type(
        'ayudawp/recent-posts',
        array(
            'title'           => __( 'Entradas recientes (PHP)', 'ayudawp' ),
            'icon'            => 'list-view',
            'category'        => 'theme',
            'description'     => __( 'Muestra una lista personalizable de entradas recientes.', 'ayudawp' ),
            'keywords'        => array( 'posts', 'recent', 'latest', 'entries' ),
            'attributes'      => array(
                'num'          => array(
                    'type'    => 'integer',
                    'default' => 5,
                ),
                'cat'          => array(
                    'type'    => 'string',
                    'default' => '',
                ),
                'order'        => array(
                    'type'    => 'string',
                    'enum'    => array( 'DESC', 'ASC' ),
                    'default' => 'DESC',
                ),
                'orderby'      => array(
                    'type'    => 'string',
                    'enum'    => array( 'post_date', 'title', 'modified', 'rand', 'comment_count' ),
                    'default' => 'post_date',
                ),
                'show_date'    => array(
                    'type'    => 'boolean',
                    'default' => false,
                ),
                'show_excerpt' => array(
                    'type'    => 'boolean',
                    'default' => false,
                ),
            ),
            'render_callback' => 'ayudawp_render_recent_posts_block',
            'supports'        => array(
                'autoRegister' => true,
                'color'        => array(
                    'text' => true,
                    'link' => true,
                ),
                'spacing'      => array(
                    'margin'  => true,
                    'padding' => true,
                ),
                'typography'   => array(
                    'fontSize' => true,
                ),
            ),
        )
    );
}

/**
 * Render callback for the recent posts block.
 *
 * @param array $attributes Block attributes.
 * @return string Block HTML output.
 */
function ayudawp_render_recent_posts_block( $attributes ) {

    $num          = absint( $attributes['num'] ?? 5 );
    $cat          = sanitize_text_field( $attributes['cat'] ?? '' );
    $order        = in_array( $attributes['order'] ?? 'DESC', array( 'ASC', 'DESC' ), true )
                    ? $attributes['order']
                    : 'DESC';
    $orderby      = sanitize_key( $attributes['orderby'] ?? 'post_date' );
    $show_date    = (bool) ( $attributes['show_date'] ?? false );
    $show_excerpt = (bool) ( $attributes['show_excerpt'] ?? false );

    $args = array(
        'posts_per_page' => $num,
        'order'          => $order,
        'orderby'        => $orderby,
        'post_status'    => 'publish',
    );

    if ( ! empty( $cat ) ) {
        $args['cat'] = absint( $cat );
    }

    $posts = get_posts( $args );

    if ( empty( $posts ) ) {
        return '';
    }

    $wrapper = get_block_wrapper_attributes();
    $output  = sprintf( '<div %s><ul style="list-style:none;padding:0;">', $wrapper );

    foreach ( $posts as $post ) {
        $output .= '<li style="margin-bottom:0.75em;">';
        $output .= sprintf(
            '<a href="%s">%s</a>',
            esc_url( get_permalink( $post ) ),
            esc_html( get_the_title( $post ) )
        );

        if ( $show_date ) {
            $output .= sprintf(
                ' <span style="color:#666;font-size:0.85em;">— %s</span>',
                esc_html( get_the_date( '', $post ) )
            );
        }

        if ( $show_excerpt && $post->post_excerpt ) {
            $output .= sprintf(
                '<br><span style="font-size:0.9em;color:#555;">%s</span>',
                esc_html( wp_trim_words( $post->post_excerpt, 20 ) )
            );
        }

        $output .= '</li>';
    }

    $output .= '</ul></div>';

    return $output;
}

/*
 * Opcional: mantiene funcional el shortcode por retro-compatibilidad.
 * Los usuarios que ya tengan [entradas_recientes] en su contenido
 * pueden seguir usándolo mientras migran al bloque.
 */
add_shortcode( 'entradas_recientes', 'ayudawp_recent_posts_shortcode_compat' );

/**
 * Shortcode compatibility wrapper.
 *
 * @param array  $atts    Shortcode attributes.
 * @param string $content Shortcode content (unused).
 * @return string HTML output.
 */
function ayudawp_recent_posts_shortcode_compat( $atts, $content = null ) {
    $atts = shortcode_atts(
        array(
            'cat'     => '',
            'num'     => '5',
            'order'   => 'DESC',
            'orderby' => 'post_date',
        ),
        $atts,
        'entradas_recientes'
    );

    return ayudawp_render_recent_posts_block(
        array(
            'num'          => (int) $atts['num'],
            'cat'          => $atts['cat'],
            'order'        => $atts['order'],
            'orderby'      => $atts['orderby'],
            'show_date'    => false,
            'show_excerpt' => false,
        )
    );
}

Qué hemos ganado con la migración

Fíjate en lo que ha cambiado, que es mucho:

• El usuario ya no necesita recordar la sintaxis [entradas_recientes num="5" cat="12"]. Inserta el bloque desde el insertador, configura todo desde el panel lateral con controles visuales y ve una previsualización en tiempo real de las entradas seleccionadas.
• El callback de renderizado es prácticamente el mismo que el del shortcode, con las mejoras de seguridad (validación de los parámetros, esc_url(), esc_html()) y los dos atributos nuevos.

Al final del archivo hemos incluido además una función de compatibilidad que mantiene el shortcode [entradas_recientes] funcionando, reutilizando el mismo callback del bloque. Así, las entradas o páginas que ya tengan el shortcode insertado seguirán mostrando las entradas recientes sin tener que tocar nada. Puedes ir migrando a tu ritmo.

Este patrón de migración (bloque nuevo + shortcode de compatibilidad que llama al mismo renderizado) es exactamente lo que deberías aplicar siempre que conviertas un shortcode a bloque. Nunca elimines el shortcode de golpe, mantenlo como alternativa.

Para saber más sobre shortcodes y cómo crearlos, tienes la guía completa de shortcodes de WordPress. Y si te has encontrado con el problema de los shortcodes que dejan de funcionar al desactivar un plugin, echa un vistazo a la guía de shortcodes huérfanos.

Ejemplo 3: Migrar el shortcode de botones de AI Share & Summarize a bloque

Para cerrar los ejemplos prácticos vamos con un caso real sobre un plugin publicado en WordPress.org, y no es ni más ni menos que la migración del shortcode [ayudawp_share_buttons] del plugin AI Share & Summarize a un bloque PHP-only.

Este plugin combina botones de compartir en redes sociales con botones para generar resúmenes en IA (Claude, ChatGPT, Perplexity, DeepSeek y muchas más). Tiene inserción automática, pero también un shortcode muy completo con parámetros para el estilo, tamaño, iconos, alineación y selección de botones concretos.

El shortcode que vamos a migrar

El shortcode admite estos parámetros principales:

[ayudawp_share_buttons style="brand" size="normal" show_icons="true" alignment="left" icon_style="circular"]

Cada uno de estos parámetros se traduce directamente en un atributo del bloque:

Cómo se integra en el plugin

A diferencia de los ejemplos anteriores (que son mu-plugins independientes) aquí el bloque se registra dentro del propio plugin, en un archivo nuevo de la carpeta /includes.

La clave está en el render_callback: en vez de pasar por do_shortcode(), llama directamente al método estático AyudaWP_AISS_Buttons::ayudawp_generate_buttons_html(), que es la misma función que ya usa internamente el shortcode para generar el HTML de los botones. Es mucho más eficiente y sin duplicar código.

Si miras la clase AyudaWP_AISS_Shortcode del plugin, verás que el shortcode pilla las opciones guardadas con get_option( 'ayudawp_aiss_options' ), sobrescribe las que vengan como parámetro del shortcode y pasa todo a AyudaWP_AISS_Buttons::ayudawp_generate_buttons_html().

El render callback del bloque hace exactamente lo mismo, pero recibiendo los valores desde los atributos del bloque en vez de desde los parámetros del shortcode.

<?php
/**
 * PHP-only block registration for AI Share & Summarize
 *
 * @package AiShareSummarize
 * @since   2.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', 'ayudawp_aiss_register_share_block' );

/**
 * Register the share buttons as a PHP-only block.
 */
function ayudawp_aiss_register_share_block() {
    register_block_type(
        'ayudawp/share-buttons',
        array(
            'title'           => __( 'AI Share & Summarize', 'ai-share-summarize' ),
            'icon'            => 'share',
            'category'        => 'widgets',
            'description'     => __( 'Share buttons and AI summary buttons.', 'ai-share-summarize' ),
            'keywords'        => array( 'share', 'social', 'ai', 'summarize' ),
            'attributes'      => array(
                'style'      => array(
                    'type'    => 'string',
                    'enum'    => array( 'minimal', 'brand', 'outline', 'dark', 'custom', 'icons-only' ),
                    'default' => 'minimal',
                ),
                'size'       => array(
                    'type'    => 'string',
                    'enum'    => array( 'compact', 'normal', 'large', 'fluid' ),
                    'default' => 'normal',
                ),
                'show_icons' => array(
                    'type'    => 'boolean',
                    'default' => true,
                ),
                'alignment'  => array(
                    'type'    => 'string',
                    'enum'    => array( 'left', 'center' ),
                    'default' => 'left',
                ),
                'icon_style' => array(
                    'type'    => 'string',
                    'enum'    => array( 'circular', 'square' ),
                    'default' => 'circular',
                ),
                'show_title' => array(
                    'type'    => 'boolean',
                    'default' => true,
                ),
            ),
            'render_callback' => 'ayudawp_aiss_render_share_block',
            'supports'        => array(
                'autoRegister' => true,
                'spacing'      => array(
                    'margin'  => true,
                    'padding' => true,
                ),
            ),
        )
    );
}

/**
 * Render callback for the share buttons block.
 *
 * Replicates the shortcode logic: loads plugin options,
 * overrides with block attributes, and calls the existing
 * AyudaWP_AISS_Buttons renderer directly.
 *
 * @param array $attributes Block attributes.
 * @return string Block HTML output.
 */
function ayudawp_aiss_render_share_block( $attributes ) {

    // Check the rendering class exists (plugin active)
    if ( ! class_exists( 'AyudaWP_AISS_Buttons' ) ) {
        return '';
    }

    // Load the saved plugin options as base
    $options = get_option( 'ayudawp_aiss_options' );

    if ( ! is_array( $options ) ) {
        return '';
    }

    $block_options = $options;

    // Override options with block attributes (same as shortcode does)
    if ( ! empty( $attributes['style'] ) ) {
        $block_options['button_colors'] = sanitize_text_field( $attributes['style'] );
    }

    if ( ! empty( $attributes['size'] ) ) {
        $block_options['button_size'] = sanitize_text_field( $attributes['size'] );
    }

    if ( isset( $attributes['show_icons'] ) ) {
        $block_options['show_icons'] = (bool) $attributes['show_icons'];
    }

    if ( ! empty( $attributes['icon_style'] ) ) {
        $block_options['icon_style'] = sanitize_text_field( $attributes['icon_style'] );
    }

    if ( isset( $attributes['show_title'] ) && ! $attributes['show_title'] ) {
        $block_options['title_text'] = '';
    }

    // Get the enabled buttons from plugin settings
    $enabled_buttons = isset( $options['enabled_buttons'] ) ? $options['enabled_buttons'] : array();

    if ( empty( $enabled_buttons ) || ! is_array( $enabled_buttons ) ) {
        return '';
    }

    $current_url   = get_permalink();
    $current_title = get_the_title();

    // Call the same renderer the shortcode uses
    $html = AyudaWP_AISS_Buttons::ayudawp_generate_buttons_html(
        $enabled_buttons,
        $block_options,
        $current_url,
        $current_title
    );

    if ( empty( $html ) ) {
        return '';
    }

    $wrapper = get_block_wrapper_attributes();

    return sprintf( '<div %s>%s</div>', $wrapper, $html );
}

Fíjate en el render callback, hace exactamente lo mismo que el método ayudawp_shortcode_share_buttons() de la clase AyudaWP_AISS_Shortcode, carga las opciones del plugin, sobrescribe con los valores que vienen del bloque (en vez de los del shortcode), y pasa todo a AyudaWP_AISS_Buttons::ayudawp_generate_buttons_html() junto con la URL y título de la entrada actual.

El resultado es que bloque y shortcode comparten el mismo motor de renderizado, sin duplicar nada de código.

El usuario podrá insertar los botones de compartir y resumir como un bloque nativo del editor, configurando el estilo, tamaño, iconos y alineación desde el panel lateral, con una previsualización que se actualiza con cada cambio.

El shortcode [ayudawp_share_buttons] seguirá funcionando exactamente igual para todos los que ya lo tengan insertado en su contenido, que la compatibilidad no se toca.

Esta integración estará disponible en una próxima versión del plugin. Aún no está perfecta pero lo estará.

Cuándo usar bloques PHP-only y cuándo no

Después de ver los tres ejemplos, conviene tener claro para qué sirve esta herramienta y para qué no. No todo debería ser un bloque PHP-only, igual que no todo debería ser un shortcode.

Es buena elección cuando…

Los bloques PHP-only son la opción adecuada para contenido dinámico que se genera en el servidor, sin necesidad de interacción en el editor más allá de configurar unos parámetros.

Hay muchos ejemplos de esto, como listados de entradas, cajas de autor, alertas o avisos personalizables, CTAs, widgets de datos, embeds de herramientas propias, botones de compartir, bloques informativos que tiran de la base de datos o de APIs externas, suma y sigue.

Todo lo que antes resolvías con un shortcode o con una función en el functions.php pero con la ventaja de una interfaz visual en el editor.

También son ideales para temas de bloques y FSE, donde puedes crear componentes específicos para tu tema sin depender de plugins de terceros.

No es la mejor opción cuando…

Si necesitas edición en tiempo real dentro del editor, como por ejemplo, escribir texto directamente en el bloque, arrastrar elementos o manipular contenido inline. En estos casos necesitas un bloque JavaScript completo. Pasa lo mismo si tu bloque debe contener otros bloques dentro (InnerBlocks), que es algo que los bloques PHP-only no admiten de momento.

Ten en cuenta que la previsualización de un bloque PHP-only usa ServerSideRender, por lo que cada vez que cambias un atributo, el editor hace una petición REST al servidor para obtener el HTML actualizado. Para bloques sencillos esto es imperceptible pero si tu callback hace consultas pesadas o llamadas a APIs externas, cada cambio de atributo puede generar un retardo visible en el editor.

¿Y los shortcodes?

Los shortcodes siguen siendo perfectamente válidos para retro-compatibilidad y para situaciones o webs donde no puedes usar el editor de bloques (campos personalizados, widgets clásicos, plantillas PHP). Pero si estás creando algo nuevo los bloques PHP-only son su sucesor natural porque ofrecen la misma facilidad de desarrollo con una experiencia de usuario mucho mejor en el editor.

Consejos prácticos y errores comunes

Para terminar unas cuantas cosas que no están en la documentación oficial y que te pueden ahorrar algún dolor de cabeza:

• Define siempre valores default en los atributos. Si un atributo llega vacío o sin definir al callback, tu bloque puede renderizar en blanco o dar un error. Un default te garantiza que siempre hay un valor válido con el que trabajar.
• Usa siempre get_block_wrapper_attributes(). Esta función genera los atributos HTML del contenedor del bloque (clases, estilos inline de los supports como color o espaciado). Si no la usas, los supports que actives no tendrán efecto.
• El namespace del bloque es obligatorio. El primer argumento de register_block_type() debe llevar el formato namespace/nombre-bloque (por ejemplo, ayudawp/author-box). Sin el namespace, el registro fallará.
• Los enum solo muestran el valor, no una etiqueta legible. Si tu enum tiene valores como array( 'small', 'medium', 'large' ), el desplegable en el editor mostrará exactamente esos textos. No hay forma (de momento) de mostrar una etiqueta más descriptiva al lado de cada valor sin recurrir a JavaScript.
• Las etiquetas de los controles son el nombre del atributo. Los controles que genera autoRegister en el panel lateral usan directamente el nombre del atributo como etiqueta, en mayúsculas y sin formato. No hay ninguna propiedad para personalizar esa etiqueta desde PHP. Por eso conviene nombrar los atributos de forma legible desde el principio (por ejemplo, autor en vez de user_id, o biografia en vez de show_bio). No es lo ideal pero es lo que hay de momento. Si necesitas etiquetas descriptivas y una interfaz más cuidada en el panel lateral, ya te toca escribir JavaScript con InspectorControls.
• Cuidado con las plantillas en el editor de sitio. Se ha detectado un problema en las betas de WordPress 7.0 donde los bloques PHP-only se renderizan correctamente en las previsualizaciones de plantillas, pero el CSS aplicado globalmente o por bloque no siempre se muestra. Es un tema que el equipo de desarrollo está resolviendo.
• InnerBlocks no están soportados. No puedes crear un bloque PHP-only que acepte otros bloques dentro. Si necesitas esta funcionalidad, toca usar bloques JavaScript.
• El rendimiento del editor depende de tu callback. Como cada cambio de atributo genera una petición REST que ejecuta tu render_callback, intenta que sea lo más ligero posible. Si haces consultas a la base de datos, plantéate usar transients para cachear los resultados.
• No necesitas block.json. Para bloques PHP-only, toda la definición del bloque (título, icono, categoría, atributos, supports) va directamente en el array que pasas a register_block_type(). No necesitas crear un archivo block.json separado.

Próximos pasos

WordPress 7.0 está disponible desde el 9 de abril de 2026. Si quieres probar todo esto antes puedes instalarte una versión beta o el plugin Gutenberg en un sitio de pruebas.

De cara a WordPress 7.1, el equipo de desarrollo ya está trabajando en Block Fields, una evolución de esta misma idea que promete ampliar los tipos de controles automáticos disponibles, y en mejorar la compatibilidad con Block Bindings, el sistema que conecta los atributos de los bloques con fuentes de datos externas.

Todo apunta a que la creación de bloques solo con PHP seguirá mejorando en las próximas versiones.

Si quieres aprender a crear estos bloques usando inteligencia artificial como copiloto, en la guía de vibe coding y agentic coding para WordPress tienes técnicas y prompts concretos para generar código de plugins y bloques con Claude o ChatGPT.

Y si necesitas repasar los fundamentos de PHP antes de meterte con los bloques, la guía de PHP básico para WordPress es un buen punto de partida, y cuando descubras que esta magia del código es lo tuyo, aquí tienes el único curso de programación para WordPress que existe, preparado por mi y muchos de los mejores profesionales que hay.

Para todo lo demás aquí me tienes.

Por si no lo has probado, lo que hace es lanzar la paleta de comandos de WordPress, que te permite hacer búsquedas dentro de tu sitio desde cualquier parte del escritorio con la combinación de teclas Control+K o Comando+K, según tu sistema operativo.

La utilidad, pues que tienes un icono para recordarte que existe la paleta de comandos, lo cual en sí no está mal, salvo que es una funcionalidad ya incluida en WordPress desde la versión 7.0.

No niego la utilidad, pero como te decía, me ha parecido extraño que Astra lo incluya por algunos motivos.

El primer motivo es puramente lógico, porque ¿a qué viene que un tema añada una funcionalidad que no tiene nada que ver con el tema? Vale que hasta la versión 7.0 WordPress no ayudaba a saber cómo usar la paleta de comandos pero ¿un tema?

Otra cosa que me ha resultado extraña es lo silenciosa que ha sido su incorporación, pues no es algo que hayan anunciado de ningún modo.

También, es raro, y más siendo algo no lógico en un tema, que:

1. Se active por defecto.
2. No tenga ningún ajuste para desativarlo.

Para terminar, comentar que esta incorporación es especialmente molesta desde WordPress 7.0, porque resulta que añade su propia lupa para lanzar la paleta de comandos, de manera nativa, aunque en vez de en la parte derecha en la izquierda, pero el resultado es que tienes dos iconos, dos lupas, ocupando espacio en tu barra de admin, para la misma utilidad.

En fin, que es una cosa bastante ilógica, pero que, afortunadamente, tiene una solución sencilla, que pasa por añadir este código al archivo functions.php del tema hijo de Astra, si lo tienes, o a un plugin personalizado o MU plugin:

// Desactivar el icono de búsqueda en la barra de administración de Astra
add_filter( 'astra_show_admin_bar_search_icon', '__return_false' );

El resultado es inmediato, ya solo tienes una lupa, la nativa de WordPress (desde la versión 7.0), o ninguna si utilizas alguna versión de WordPress anterior a esta.

¡De nada!

Pero medir la accesibilidad no es tan sencillo como pasar una herramienta y obtener un aprobado o un suspenso. Tiene matices, limitaciones y trampas que conviene conocer antes de lanzarse. En este artículo te cuento qué se mide exactamente, cómo se mide, con qué herramientas puedes hacerlo, y dónde está el límite de lo que una herramienta automática puede detectar.

Por qué medir la accesibilidad de tu web

Hay dos razones, y las dos de peso. La primera es legal, pues la Ley 11/2023, que transpone la Directiva europea de accesibilidad (2019/882), está en vigor desde el 28 de junio de 2025 y afecta a empresas privadas que ofrezcan servicios digitales (ecommerce, banca online, transporte, plataformas de contenido, etc.).

Las sanciones por incumplimiento van desde 301 euros para infracciones leves hasta 1.000.000 de euros para las muy graves, no es broma, es un arruina-negocios.

Las microempresas, o sea, las de menos de 10 empleados y menos de 2 millones de euros de facturación anual, la tuya, la mía y la de la mayoría de emprendedores, tienen exenciones parciales, pero ojo, parciales. Por su parte, el sector público ya estaba obligado por el RD 1112/2018 desde hace años.

La segunda razón es práctica, pues un sitio accesible es un sitio que funciona mejor para todo el mundo. Mejor estructura, mejor navegación, mejor rendimiento en buscadores. No es casualidad que muchas de las buenas prácticas de accesibilidad coincidan con las de SEO y usabilidad.

Un h1 bien puesto, un formulario con elementos label correctos, un contraste de texto legible. Todo eso beneficia a todos tus visitantes, no solo a los que usan tecnologías de asistencia.

Si quieres profundizar a nivel general en la accesibilidad web en WordPress tengo una guía completa sobre accesibilidad web en WordPress que te vendrá bien como referencia, es sencilla de leer y complemento previo a este artículo si me apuras.

Qué se mide exactamente

La referencia técnica son las WCAG 2.1 (Web Content Accessibility Guidelines), un estándar del W3C que organiza los criterios de accesibilidad en cuatro principios. No hace falta que te los aprendas de memoria pero sí que entiendas la lógica:

1. Perceptible: El contenido debe poder verse y oírse. Imágenes con texto alternativo, vídeos con subtítulos, contraste de color suficiente.
2. Operable: El sitio debe poder navegarse con teclado, sin trampas de foco, con enlaces descriptivos, sin redirecciones automáticas que desorienten.
3. Comprensible: El idioma de la página debe estar declarado, los formularios deben tener elementos label claros, los errores deben explicarse de forma accesible.
4. Robusto: El código debe funcionar con distintas tecnologías de asistencia. IDs únicos, ARIA bien usado, regiones live para mensajes dinámicos.

La normativa española (tanto la Ley 11/2023 como el RD 1112/2018) exige el nivel AA de las WCAG 2.1, que son 50 criterios de éxito. No todos pesan igual, claro, pero todos cuentan.

Además de lo puramente técnico, en España hay requisitos legales adicionales que una auditoría debería revisar:

• Declaración de accesibilidad enlazada desde el pie de página
• Aviso legal con identificación del titular (LSSICE)
• Política de privacidad (RGPD)
• Banner de cookies conforme a la AEPD
• Canal de reporte de problemas de accesibilidad

Lo que las herramientas automáticas pueden y no pueden hacer

Esto es lo más importante del artículo y no quiero que te lo saltes. Las herramientas automáticas de análisis de accesibilidad detectan, en el mejor de los casos, entre el 30% y el 40% de los problemas reales. Es un dato que repiten tanto Deque (los creadores de axe) como el W3C y cualquier auditor profesional serio.

¿Por qué tan poco? Pues porque muchos criterios WCAG requieren juicio humano.

Una herramienta puede detectar que una imagen no tiene atributo alt, pero no puede evaluar si el texto alternativo que has puesto es realmente descriptivo o es un «imagen1.jpg«. Puede comprobar que existe un contraste mínimo en estilos inline, pero no puede procesar todo el CSS para verificar el contraste real del texto que ve el usuario. Puede encontrar un div con onclick, pero no puede saber si ese div tiene un comportamiento interactivo legítimo o es un error.

Lo que sí hacen bien las herramientas automáticas:

• Detectar imágenes sin alt
• Encontrar IDs duplicados
• Verificar que existe el atributo lang en el HTML
• Comprobar si el viewport bloquea el zoom
• Detectar enlaces con texto ambiguo («haz clic aquí»)
• Encontrar campos de formulario sin label asociado
• Localizar outline:none sin alternativa de foco

Lo que no pueden hacer (o hacen mal):

• Calcular el contraste real de colores (necesitan procesar todo el CSS)
• Evaluar la calidad del texto alternativo
• Comprobar que la navegación con teclado funciona de verdad
• Verificar que los lectores de pantalla anuncian correctamente el contenido
• Determinar si la estructura semántica tiene sentido para un usuario real
• Detectar si un banner de cookies usa patrones oscuros

Dicho esto, que no detecten todo no significa que no sean útiles, son el mejor punto de partida, la primera línea de defensa. Te dan un mapa de los errores más evidentes y te ahorran horas de revisión manual en cosas que una máquina sí puede verificar con fiabilidad.

Cómo medir la accesibilidad paso a paso

Si quieres hacer una evaluación razonable (no profesional, pero sí útil), sigue estos pasos:

Pasa una herramienta automática

Empieza por ahí. Analiza al menos la portada, una página interior tipo y una ficha de producto o formulario de contacto. Anota los fallos y clasifícalos por gravedad.

Navega con el teclado

Cierra el ratón y navega tu web solo con Tab, May+Tab y luego Intro. ¿Puedes llegar a todos los menús? ¿Ves dónde está el foco en cada momento? ¿Algún elemento te atrapa y no te deja salir? Esta prueba de cinco minutos te dirá más sobre la accesibilidad real de tu web que muchas herramientas.

Prueba con un lector de pantalla

NVDA (gratuito, Windows) o VoiceOver (integrado en Mac e iOS). No hace falta ser experto, basta con activarlo y escuchar cómo se lee tu página. Si algo suena raro, confuso o directamente no se anuncia, ahí tienes un problema.

Revisa los requisitos legales

Comprueba manualmente si tu web tiene enlazados desde el pie de página: aviso legal, política de privacidad, política de cookies y, si procede, la declaración de accesibilidad. Verifica que el banner de cookies permita rechazar con la misma facilidad que aceptar (exigencia de la AEPD).

Documenta y prioriza

Haz una lista de todo lo encontrado, ordena por gravedad (los problemas que impiden el uso van primero), y planifica la corrección. No intentes arreglar todo de golpe, prioriza lo que bloquea el acceso.

Herramientas para medir la accesibilidad

Aquí va un repaso sincero de las opciones disponibles, cada una con lo que hace bien y lo que no.

Lighthouse (Google Chrome)

Viene integrada en las DevTools de Chrome (F12 > Lighthouse > Accessibility). Gratuita, rápida, da una puntuación de 0 a 100 y usa el motor axe-core internamente, aunque ejecuta menos reglas que axe completo.

• A favor: no necesitas instalar nada, genera informes descargables, combina accesibilidad con rendimiento y SEO en un solo análisis.
• En contra: ejecuta menos reglas que axe DevTools, la puntuación puede dar falsa sensación de seguridad (un 90 en Lighthouse no significa que tu web sea accesible), solo analiza una página cada vez.

WAVE (WebAIM)

Extensión gratuita para Chrome y Firefox que superpone los errores directamente sobre la página. Muy visual y fácil de entender sin conocimientos técnicos.

• A favor: la representación visual ayuda mucho a entender dónde están los problemas, gratuita, no requiere conocimientos de desarrollo.
• En contra: analiza solo una página cada vez, puede saturar visualmente en páginas complejas, no detecta problemas que requieran renderizado completo del CSS.

axe DevTools (Deque)

Extensión para Chrome y Firefox creada por Deque, la referencia en accesibilidad. El motor axe-core es el mismo que usa Lighthouse internamente, pero la extensión ejecuta más reglas y tiene la política de cero falsos positivos.

• A favor: la herramienta automatizada más precisa del mercado, informes técnicos detallados, versión gratuita muy potente, cero falsos positivos declarados.
• En contra: orientada a desarrolladores (la interfaz puede intimidar), la versión gratuita tiene limitaciones, solo analiza una página cada vez.

Accessibility Insights (Microsoft)

Extensión para Chrome que combina un análisis rápido (FastPass) con una guía paso a paso para revisión manual. La guía de evaluación manual es lo más interesante, te lleva de la mano por los criterios que las herramientas automáticas no pueden verificar.

• A favor: la combinación de análisis automático y guía manual es única, gratuita y de código abierto, excelente para aprender sobre accesibilidad mientras evalúas.
• En contra: solo disponible en inglés, requiere más tiempo que un simple escaneo automático.

Soluciones de superposición (accessiBe, UserWay, etc.)

Son widgets que se instalan en tu web y prometen corregir problemas de accesibilidad automáticamente con IA. Tengo que ser claro aquí, y es que la comunidad de accesibilidad las desaconseja de forma casi unánime. No corrigen los problemas reales del código, solo ponen una capa encima.

Algunos estudios incluso han demostrado que pueden empeorar la experiencia para usuarios de lectores de pantalla, y no te protegen legalmente porque no modifican el HTML subyacente. Si te interesa el tema tengo un artículo sobre plugins de accesibilidad a un clic donde profundizo más en estas cosas.

Auditoría profesional

La opción más completa y la única que realmente puede certificar cumplimiento. Un auditor profesional combina herramientas automáticas, revisión manual experta, pruebas con tecnologías de asistencia y, en el mejor de los casos, pruebas con usuarios reales con discapacidad. El coste varía mucho según el tamaño del sitio, pero en España hay que contar con un mínimo de 1.500 a 3.000 euros para un sitio pequeño.

• A favor: la única vía para detectar el 100% de los problemas, genera documentación válida legalmente, incluye plan de aplicación de soluciones por prioridades.
• En contra: coste elevado para pequeñas empresas, hay que repetirla periódicamente (cada cambio importante del sitio puede introducir nuevas barreras).

Analizador de accesibilidad online

La herramienta de análisis de accesibilidad para webs WordPress tiene un funcionamiento sencillo. Solo tienes que introducir la URL de tu web WordPress y obtener un análisis automático con 25 comprobaciones organizadas en los 4 principios WCAG más requisitos legales españoles y comprobaciones específicas de WordPress.

• A favor: gratuita, sin registro, en español, orientada específicamente a WordPress (detecta tema, maquetadores, plugins de accesibilidad, tema accessibility-ready), incluye correcciones concretas para WordPress con plugins recomendados, cubre requisitos legales españoles (Ley 11/2023, RD 1112/2018, LSSICE, RGPD), también acepta HTML pegado directamente para analizar sin necesidad de URL pública.
• En contra: como toda herramienta automática solo detecta problemas verificables en el HTML estático (no procesa el CSS completo ni simula interacción alguna), no sustituye una auditoría profesional ni pruebas manuales. La puntuación orienta pero no certifica cumplimiento.

Te recomiendo usarla como primer paso rápido para saber dónde estás, complementarla con una navegación con teclado y, si tu sitio tiene obligaciones legales, plantearte seriamente pedir una auditoría profesional.

El enfoque realista

Si tu presupuesto es limitado y no puedes contratar una auditoría profesional la combinación más eficaz es:

1. Pasa el analizador online de accesibilidad o Lighthouse para tener un mapa de errores automáticos
2. Instala WAVE o axe DevTools en tu navegador para ir revisando página por página
3. Navega tu web con el teclado y detecta trampas de foco y problemas de navegación
4. Prueba con NVDA o VoiceOver al menos la portada y el flujo principal (menú, página, formulario)
5. Revisa los requisitos legales manualmente (pie de página, declaración de accesibilidad, cookies)
6. Documenta todo y corrige empezando por lo más grave

No es un kit perfecto pero es mucho mejor que no hacer nada, y sobre todo es un proceso continuo.

La accesibilidad no se «arregla» una vez y se olvida, cada actualización del tema, cada plugin nuevo, cada cambio de contenido puede introducir nuevas barreras. Lo ideal es incorporar estas comprobaciones a tu flujo de trabajo habitual.

Para gestionar la accesibilidad en el día a día de tu WordPress no olvides revisar también la guía de accesibilidad en WordPress y a los plugins de accesibilidad que pueden ayudarte.

x402 es un protocolo abierto de pagos nativos de Internet que utiliza el código de estado HTTP 402 (Payment Required) para que servidores y clientes (incluidos agentes de IA) negocien y procesen pagos de forma automática dentro de las propias peticiones HTTP.

Creado por Coinbase en mayo de 2025, desde abril de 2026 está bajo la gobernanza de la Linux Foundation, con Google, Stripe, Visa, Mastercard, AWS, Cloudflare y Shopify como miembros fundadores.

En WordPress ya existen plugins como PayLayer e ICPay que permiten implementar x402 para cobrar a agentes de IA por acceso a contenido o para procesar compras automatizadas en WooCommerce, sin afectar a la experiencia de los visitantes humanos.

Esto sería un resumen rápido, pero hay mucho más que contar, y todo interesante…

El protocolo del código 402

Si leíste el artículo sobre qué es el código de estado HTTP 402 y cómo usarlo en WordPress, recordarás que hablamos de un código HTTP que lleva casi tres décadas reservado «para uso futuro» y que estaba empezando a despertar. Mencionaba de pasada el protocolo x402 de Coinbase como una de las implementaciones reales que le dan sentido al 402.

Desde que se publicó aquel artículo han pasado cosas bastante gordas, y lo más gordo es que x402 ha dejado de ser un proyecto de una empresa de criptomonedas para convertirse en un estándar abierto bajo la Linux Foundation, con medio sector tecnológico mundial respaldándolo. Y además, ya hay plugins de WordPress que lo implementan.

Vamos a ver qué es exactamente x402, cómo funciona a nivel técnico, quién está detrás, qué opciones hay para WordPress y cuánto de todo esto es real hoy y cuánto es promesa de futuro.

Qué es x402 y cómo funciona

x402 es un protocolo abierto que integra pagos directamente dentro de las peticiones HTTP. La idea es que el dinero se mueva por internet con la misma facilidad con la que se mueve la información. Sin formularios, sin cuentas de usuario, sin pasarelas de pago intermediarias.

Un cliente (sea un navegador, una aplicación o un agente de IA) solicita un recurso, el servidor le dice cuánto cuesta, el cliente paga, y el servidor le da acceso. Todo dentro del propio protocolo HTTP.

El flujo básico es así:

1. Un cliente hace una petición HTTP a un recurso protegido.
2. El servidor responde con un HTTP 402 Payment Required e incluye en la respuesta las instrucciones de pago: cuánto cuesta, qué métodos acepta, a qué dirección de wallet hay que pagar.
3. El cliente procesa el pago (actualmente con stablecoins como USDC) y reenvía la petición con una cabecera de autorización de pago.
4. Un «facilitador» (un servicio intermedio) verifica que el pago se ha completado en la cadena de bloques.
5. El servidor responde con un HTTP 200 OK y entrega el contenido.

Lo que diferencia a x402 de un muro de pago tradicional es que todo sucede a nivel de protocolo. No hay una página de pago, no hay un formulario donde meter los datos de la tarjeta, no hay una suscripción mensual. Es una transacción única con petición, pago, acceso, y está diseñado para que las máquinas lo hagan solas, sin intervención humana.

En la web de x402.org lo resumen con un ejemplo de código que da una idea bastante clara de la filosofía:

•  Añades un middleware a tu servidor con una línea de código indicando qué endpoints requieren pago, cuánto cuestan y qué métodos de pago aceptas.
  • Si llega una petición sin pago, el servidor devuelve un 402.
  • Si llega con pago válido, devuelve el contenido.

La versión 2 del protocolo

x402 se lanzó en mayo de 2025 y en diciembre de ese mismo año ya salió la versión 2, basada en lo aprendido con los primeros meses de uso.

Los cambios principales del V2 son bastantes:

• Soporte multichain de serie, lo que significa que funciona con stablecoins y tokens en varias cadenas de bloques (Base, Solana y otras) sin necesidad de lógica personalizada. También es compatible con pasarelas de pago tradicionales, de modo que un «facilitador» puede procesar pagos por ACH, SEPA o tarjeta dentro del mismo modelo.
• Sesiones reutilizables basadas en wallet, para que un cliente que ya ha pagado no tenga que repetir la transacción en cada petición. Esto es importante para agentes de IA que hacen muchas llamadas seguidas: sin sesiones, cada petición individual sería una transacción en la cadena de bloques, algo lento y caro. Con sesiones, el agente paga una vez y mantiene el acceso durante un periodo definido.
• Arquitectura modular de plugins que permite añadir nuevas cadenas de bloques, métodos de pago o esquemas de precio sin tocar el núcleo del protocolo. Y descubrimiento automático de endpoints, para que los facilitadores puedan indexar los servicios de pago disponibles sin configuración manual.
• Las cabeceras HTTP se han actualizado, y ahora las antiguas cabeceras con prefijo X- (ya obsoletas según las convenciones HTTP) se han reemplazado por PAYMENT-REQUIRED, PAYMENT-SIGNATURE y PAYMENT-RESPONSE.

Quién está ahora detrás de x402

Aquí es donde la cosa se pone seria. x402 empezó como un proyecto de Coinbase (la mayor plataforma de intercambio de criptomonedas de Estados Unidos). En septiembre de 2025 Coinbase y Cloudflare anunciaron su intención de crear la x402 Foundation, y el 2 de abril de 2026 la fundación se ha constituido oficialmente bajo el paraguas de la Linux Foundation.

Los miembros fundadores son Amazon Web Services, American Express, Cloudflare, Coinbase, Google, Mastercard, Microsoft, Shopify, Stripe y Visa. También están Adyen, Circle, Fiserv, KakaoPay, Polygon Labs, PPRO y la Solana Foundation. Es decir, prácticamente todos los actores relevantes del sector de pagos global, las principales plataformas cloud y las empresas de infraestructura web más grandes del mundo.

El propio Jim Zemlin, director ejecutivo de la Linux Foundation, ha dicho que x402 tendrá gobernanza abierta y comunitaria, igual que otros estándares que gestiona la fundación. Coinbase ha cedido la propiedad del protocolo y ya no es «su» estándar, es un estándar de la industria.

Las cifras actuales del protocolo pasan porque en los últimos 30 días se han procesado más de 75 millones de transacciones por un volumen superior a 24 millones de dólares, con más de 94.000 compradores y 22.000 vendedores. No es tráfico de prueba, hay empresas ya cobrando y pagando a través del protocolo.

Un dato que merece atención es que Google ya ha integrado x402 como pasarela de pago por defecto en su protocolo de pagos para agentes de IA, Visa ha lanzado una herramienta CLI de pagos orientada a comercio de agentes, y Circle ha construido sus Nanopayments (micropagos de fracciones de céntimo) directamente sobre x402. El ecosistema va creciendo a toda leche.

Lo que más llama la atención no es la tecnología en sí, sino que empresas de criptomonedas (Coinbase, Circle, Solana Foundation), gigantes del pago tradicional (Visa, Mastercard, American Express, Stripe), plataformas cloud (AWS, Google, Microsoft) e infraestructura web (Cloudflare, Shopify) están todas en la misma mesa.

No es habitual ver a Visa y a la Solana Foundation compartiendo fundación, y eso te dice algo sobre lo en serio que se están tomando la idea de que los pagos entre máquinas necesitan un estándar común.

x402 frente al enfoque manual con status_header(402)

En el artículo anterior sobre el 402 mostrábamos cómo devolver un código 402 desde WordPress usando status_header( 402 ) con cabeceras informativas de precio y una URL de contacto. Ese enfoque sigue siendo válido, pero conviene entender en qué se diferencia de lo que hace x402.

El código que te proponía en aquel artículo es declarativo, o sea, le dices al bot «esto cuesta dinero, aquí tienes dónde informarte». Es una señal, un cartel que dice «hay precio», pero el pago no ocurre dentro del propio protocolo HTTP. Si el bot quiere pagar, tiene que salir de la petición, ir a la URL de contacto, negociar un acuerdo y volver con algún tipo de credencial.

x402 es transaccional, pues el pago sucede dentro del propio intercambio HTTP. El servidor dice cuánto cuesta, el cliente paga en la cadena de bloques, reenvía la petición con la prueba de pago, y el contenido se sirve. Todo automático, todo en tiempo real, sin intervención humana en ningún punto.

Son dos niveles distintos y, en la práctica, complementarios. El enfoque manual es viable hoy para cualquier WordPress sin dependencias externas y funciona como barrera frente a rastreadores de IA. x402 requiere plugins específicos y un ecosistema cripto funcional (wallets, stablecoins, facilitadores), pero a cambio permite cobros reales automatizados.

Si tu objetivo es simplemente bloquear rastreadores de IA con una señal de que tu contenido no es gratis, el snippet manual con status_header( 402 ) sigue siendo la opción más sencilla y controlable. No depende de ningún servicio externo, no requiere wallet, y lo puedes implementar en cinco minutos con un mu-plugin. Si lo que quieres es cobrar de verdad, automáticamente y sin intervención humana, ahí es donde x402 entra en juego.

También hay un escenario intermedio: puedes usar el enfoque manual como primera barrera y tenerlo listo para el día en que los facilitadores x402 estén suficientemente maduros para añadir la capa transaccional encima. El código de estado 402 es el mismo en ambos casos, lo que cambia es lo que hay detrás.

El elefante en la habitación son las criptomonedas

No tiene sentido hablar de x402 sin mencionar la parte que seguramente genere más resistencia en la comunidad WordPress en general, y la hispana en particular, y es que todo esto funciona con criptomonedas.

Un matiz importante es no estamos hablando de Bitcoin o de tokens especulativos. x402 usa stablecoins, que son criptomonedas vinculadas al valor de una moneda fiduciaria (USDC está vinculada al dólar estadounidense 1:1). Sin fluctuación, sin especulación. Pagar 0,05 USDC equivale a pagar 0,05 dólares, hoy y mañana, funciona de este modo, para bien y para mal.

Dicho esto, la realidad práctica para un propietario de web WordPress en España, Mexico, Argentina, Chile, Perú, Costa Rica o cualquier otro país que no sea los EEUU es que necesitas un wallet de criptomonedas, necesitas saber qué es USDC, necesitas entender en qué cadena de bloques estás operando, y necesitas gestionar la conversión a euros o tu divisa local si quieres ese dinero en tu cuenta bancaria.

Para quien esté familiarizado con el ecosistema cripto, es trivial, para el resto es una barrera considerable.

Hay dos señales de que esto podría cambiar.

1. La primera es que Stripe y Visa son miembros fundadores de la x402 Foundation. Que las dos mayores infraestructuras de pago del mundo estén dentro sugiere que eventualmente habrá puentes con métodos de pago tradicionales (tarjeta, transferencia, domiciliación).
2. La segunda es que la versión 2 del protocolo ya contempla explícitamente la compatibilidad con pasarelas de pago estándar (ACH, SEPA, tarjetas). Pero hoy, en abril de 2026, la única pasarela funcional es cripto.

Luego está la regulación europea, como siempre poniendo todo aún más complicado. El reglamento MiCA (Markets in Crypto-Assets), en vigor desde junio de 2024, establece un marco normativo para las stablecoins en la UE. USDC de Circle cumple con MiCA, lo que le da cierta seguridad jurídica, pero las obligaciones fiscales y contables de recibir pagos en stablecoins son algo que cada propietario de web tendrá que consultar con su asesor.

Para ponerte un ejemplo concreto, si recibes 50 $ en USDC al mes por acceso de agentes de IA a tu contenido, esos ingresos hay que declararlos. Necesitas saber cómo convertirlos a euros (a través de un exchange como Coinbase o Binance, o directamente con Stripe si integra x402 como facilitador), cómo registrarlos contablemente, y cómo aplicar el IVA si corresponde. Nada de esto es algo insalvable, pero es una capa de complicación que no existe cuando cobras por PayPal o por transferencia.

Cloudflare y su CMS (EmDash) con x402 de serie

Un detalle que merece mención aunque no vamos a entrar en profundidad ahora, porque ya escribí sobre ello es que Cloudflare ha presentado EmDash, un CMS de código abierto que se posiciona como «sucesor espiritual de WordPress» y que trae soporte nativo para x402 integrado de fábrica. Cualquier sitio EmDash puede cobrar por acceso a contenido configurando qué páginas son de pago, cuánto cuestan y una dirección de wallet, todo ello sin código, sin plugins adicionales.

Que Cloudflare haya decidido que los micropagos a agentes de IA son una funcionalidad nativa de CMS, no un plugin, es una señal que WordPress debería tomarse en serio. Pero ya te digo que no me enrollo más al respecto, ya he escrito de sobra de EmDash, qué es, cómo afecta a WordPress y cómo probarlo en otros artículos.

x402 en WordPress

Y ahora la parte que nos interesa, ¿se ya puede usar x402 en WordPress? Pues sí, aunque con matices importantes. De momento dos opciones disponibles.

PayLayer

PayLayer es un plugin WordPress diseñado específicamente para monetizar el tráfico de agentes de IA usando el protocolo x402. Su propuesta es que los bots de IA pagan por acceder al contenido, mientras que los visitantes humanos siguen viendo la web con normalidad y sin interrupciones.

Instalas el plugin, conectas un wallet de Solana, y configuras qué contenido requiere pago y cuánto cuesta. Puedes definir precios por petición, por cada mil palabras o una tarifa fija por recurso, y puedes aplicar las reglas por tipo de contenido, categoría, etiqueta o ruta de la REST API.

• Cuando un agente de IA solicita un contenido protegido, PayLayer le devuelve un HTTP 402 con las instrucciones de pago en las cabeceras, el agente paga, y recibe el contenido.
• Cuando un visitante humano solicita el mismo contenido, recibe un HTTP 200 y ve la página con normalidad. La distinción se hace analizando las cabeceras de la petición (user agent y cabeceras Accept).

Tiene también integración con WooCommerce, pudiendo permitir que agentes de IA compren productos de tu tienda de forma automática y recurrente. El agente añade productos al carrito, procesa el pago mediante x402, y WooCommerce genera el pedido automáticamente. Los pedidos de agentes se etiquetan para que puedas distinguirlos de las compras normales.

El escritorio muestra las visitas pagadas frente a las bloqueadas, los ingresos por contenido y qué agentes han pagado. Útil para ir ajustando precios según datos reales.

Un ejemplo práctico sería por ejemplo un blog de recetas con 500 artículos bien posicionados. y los agentes de IA de ChatGPT o Gemini pasan por tu sitio constantemente para alimentar sus respuestas. Pues bien, con PayLayer podrías cobrar 0,002 € por cada receta a la que un agente acceda, mantener el contenido completamente abierto para los humanos que llegan desde Google, y a final de mes tener un ingreso extra proporcional al volumen de tráfico automatizado que recibes.

No es un modelo que vaya a reemplazar a AdSense mañana pero sí una fuente de ingresos complementaria por un tráfico que hasta ahora no generaba nada.

ICPay (Instant Crypto Payments)

ICPay es un plugin de pagos crypto más generalista que está en el repositorio oficial de WordPress.org. Admite más de 50 criptomonedas y tokens en varias cadenas (Base, Solana, Internet Computer), y ha añadido x402 de Coinbase como opción de pago.

A diferencia de PayLayer, ICPay no está centrado en la monetización de tráfico de IA. Es un plugin de pagos crypto con integración WooCommerce que incluye bloques de Gutenberg y shortcodes para botones de pago, botes de propinas, muros de contenido premium y termómetros de donaciones. x402 es uno más de sus métodos de pago, no el eje central del plugin.

Tiene menos de 10 instalaciones activas y ninguna reseña a día de hoy. Cobra una comisión del 0,5% por transacción y los pagos van directos a tu wallet sin intermediarios.

¿Funcionan?

Esto aún está en fase muy temprana. PayLayer se lanzó en enero de 2026 y el otro, ICPay, tiene menos de 10 instalaciones. Ningún sitio WordPress grande los está usando a escala todavía, al menos de forma pública o que yo sepa. Yo los tengo en pruebas, pero aún sin datos que pueda (ni deba) compartir. Ten en cuenta que son las primeras herramientas de un ecosistema que está naciendo.

Dicho esto, que la infraestructura de plugins exista ya, antes incluso de que la x402 Foundation se haya constituido formalmente, dice algo sobre la velocidad a la que se mueve este espacio.

Para quién tiene sentido x402 hoy

• Tiene sentido no perderle la pista a x402 si gestionas un sitio WordPress con contenido de alto valor que los rastreadores de IA visitan con frecuencia (guías técnicas extensas, directorios de datos, comparativas, documentación especializada).
• Si operas una API con WordPress, sirves datos estructurados y quieres monetizar el acceso.
• Si tienes una tienda WooCommerce y quieres estar preparado para cuando los agentes de IA de tus clientes compren productos directamente.

No tiene mucho sentido aún si gestionas un blog pequeño o mediano donde el tráfico de bots de IA es marginal, si tu audiencia no está familiarizada con criptomonedas (y tú tampoco), o si dependes del tráfico orgánico de Google como fuente principal de visitas, porque las páginas que devuelven un 402 a los rastreadores dejarán de indexarse.

Lo que hay que vigilar de cerca es:

1. Cómo evoluciona la integración de métodos de pago dentro del protocolo (cuando Stripe o Visa actúen como facilitadores x402, la barrera cripto desaparece)
2. Cómo reacciona el ecosistema WordPress (plugins nuevos, integraciones con WooCommerce, posibles movimientos de Automattic)
3. Qué pasa con EmDash y otros CMS que están naciendo con x402 integrado de raíz.
4. También merece la pena seguir de cerca el esquema de pagos diferidos que Cloudflare ha propuesto para x402, que permitiría cobros automatizados en lugar de transacción por transacción, algo mucho más práctico para sitios con mucho volumen de tráfico automatizado.

El protocolo x402 es la pieza que faltaba para que el código de estado HTTP 402 dejara de ser una curiosidad histórica y se convirtiera en infraestructura real. Que Google, Stripe, Visa, Mastercard y la Linux Foundation estén empujando en la misma dirección indica que no es una moda pasajera.

Para WordPress, hoy por hoy, estamos en la casilla de salida. Los cimientos ya están, las primeras herramientas existen, y la industria se ha posicionado, lo único que falta es que todo madure lo suficiente para que un propietario de web normal pueda activarlo sin necesitar un máster en criptografía.

Qué se puede migrar y qué no

Antes de tocar nada, conviene tener claro qué es lo que EmDash puede traerse de WordPress y qué se queda en el camino.

Lo que sí migra:

• Entradas y páginas, incluidos borradores y contenido privado (con el método WXR).
• Tipos de contenido personalizados (CPTs).
• Categorías, etiquetas y taxonomías personalizadas, con toda su jerarquía.
• Medios (imágenes, vídeos, documentos) con metadatos como texto alternativo, pie de foto y dimensiones.
• Datos de SEO de Yoast SEO y Rank Math como datos meta.
• Autores y su atribución al contenido.
• Ajustes (parcial, solo los que contempla EmDash)

Lo que no migra:

• Plugins: La arquitectura es completamente diferente (PHP vs. TypeScript, acceso total vs. sandbox). No hay equivalencia directa posible.
• Temas: Hay que reconstruirlos como proyectos de Astro. EmDash incluye Agent Skills para ayudar a portarlos con agentes de IA, pero no es automático.
• Bloques de Gutenberg personalizados: Se pueden reconstruir con el Block Kit de EmDash, pero hay que hacerlo uno a uno.
• Funcionalidad específica de plugins: formularios de contacto, pasarelas de pago, sistemas de reservas, constructores de páginas, membresías. Todo eso tendrías que rehacerlo en EmDash (si es que existe la posibilidad) o prescindir de ello.
• Widgets y menús de navegación: La estructura de navegación se define de forma diferente en Astro.
• Campos personalizados, incluidos los de ACF (Advanced Custom Fields), con información de tipo.

El contenido y los datos migran bien, la funcionalidad no. Si tu web es un blog o un sitio de contenido la migración es relativamente sencilla. Si tienes una tienda online con WooCommerce, un sistema de membresía con Restrict Content Pro o una web con varios plugins haciendo cosas distintas, la migración es otro cantar y seguramente no te compense ni de lejos.

Método 1: exportar WXR desde WordPress

El WXR (WordPress eXtended RSS) es el formato de exportación nativo de WordPress, un archivo XML que contiene todo el contenido de tu sitio. Es el método más completo y el más sencillo si tienes un sitio de tamaño pequeño o mediano.

Paso 1: exportar el contenido desde WordPress

Entra en tu panel de WordPress y ve a Herramientas → Exportar.

Selecciona Todo el contenido para exportar entradas, páginas, comentarios, campos personalizados, términos de navegación y Custom Post Types. Si solo quieres migrar una parte (por ejemplo, solo las entradas), puedes filtrar por tipo de contenido, categoría, autor o rango de fechas.

Pulsa Descargar el archivo de exportación. WordPress generará un archivo XML con extensión .xml que se descargará a tu ordenador.

Si prefieres hacerlo por WP-CLI (por ejemplo, para sitios grandes o si quieres automatizarlo), el comando es:

wp export --dir=/ruta/donde/guardar/

Esto genera uno o varios archivos WXR en la carpeta que indiques.

Paso 2: importar el WXR en EmDash

Abre el panel de administración de EmDash (normalmente http://localhost:4321/admin si es local, o la URL de tu despliegue en Cloudflare).

Ve a la sección de importación. EmDash tiene un importador integrado en el propio panel de administración.

Selecciona la opción de importar desde archivo WXR y sube el archivo XML que exportaste de WordPress.

EmDash analizará el archivo y te mostrará un resumen de lo que va a importar: número de entradas, páginas, tipos personalizados, taxonomías y archivos de medios.

Confirma la importación. El proceso tarda entre unos segundos y varios minutos dependiendo del tamaño del sitio. EmDash descargará automáticamente los archivos de medios desde las URLs originales de tu WordPress y los almacenará en su propia librería de medios (sistema de archivos en local, R2 en Cloudflare).

Qué pasa con el contenido durante la importación

Hay varios detalles que conviene saber sobre cómo EmDash procesa el contenido de WordPress:

• El HTML se convierte a Portable Text: WordPress almacena el contenido como HTML (o como bloques de Gutenberg serializados en HTML con comentarios). EmDash lo convierte a Portable Text, su formato nativo en JSON estructurado. El texto, los enlaces, las imágenes incrustadas y el formato básico (negritas, cursivas, encabezados, listas, citas) se mantienen. Los bloques de Gutenberg más complejos (columnas, grupos, bloques personalizados) pueden perder estructura o convertirse en HTML genérico.
• Las taxonomías se convierten en colecciones: Las categorías y etiquetas de WordPress se importan como colecciones separadas en EmDash, manteniendo la jerarquía de las categorías (padres e hijas).
• Los Custom Post Types se pueden asignar: Si tu WordPress tiene tipos de contenido personalizados (por ejemplo, «Proyectos», «Testimonios», «Productos»), EmDash puede crear colecciones equivalentes durante la importación. Lo ideal es crear las colecciones en EmDash antes de importar, definiendo los campos que necesitas, y luego mapear los tipos de WordPress a las colecciones de EmDash durante el proceso.
• Los campos personalizados se importan con tipo: El exportador reconoce los grupos de campos y exporta los valores con información de tipo. Un campo de imagen se importa como campo de tipo media en EmDash, un campo de texto como texto, un repetidor como array. No es perfecto al 100% (los campos más complejos pueden necesitar ajustes), pero para campos estándar funciona bien.

Método 2: el plugin EmDash Exporter

El segundo método es instalar un plugin en tu WordPress que crea un endpoint seguro por el que EmDash puede importar el contenido directamente, sin necesidad de descargar y subir archivos. Es más rápido para sitios grandes porque transmite el contenido en streaming en vez de pasar por un archivo intermedio.

Paso 1: instalar el plugin en WordPress

Descarga el plugin EmDash Exporter desde GitHub. De momento no está en el directorio de plugins de WordPress.org, así que tienes que instalarlo manualmente.

Sube la carpeta emdash-exporter a /wp-content/plugins/ de tu WordPress (por FTP, por el gestor de archivos de tu hosting o por WP-CLI) y actívalo desde Plugins en el panel de WordPress.

Paso 2: crear una contraseña de aplicación

El plugin usa las contraseñas de aplicación de WordPress para verificar las peticiones de EmDash. Ve a tu perfil de usuario en WordPress (Usuarios → Tu perfil), baja hasta la sección de Contraseñas de aplicación, escribe un nombre identificativo (por ejemplo, «EmDash») y pulsa Añadir nueva contraseña de aplicación.

WordPress te mostrará la contraseña generada. Cópiala ahora porque no la podrás ver de nuevo. La vas a necesitar en el siguiente paso.

Paso 3: conectar EmDash a tu WordPress

En el panel de EmDash, ve a la sección de importación y selecciona la opción de importar desde WordPress (API REST).

Introduce la URL de tu sitio WordPress y las credenciales: tu nombre de usuario de WordPress y la contraseña de aplicación que acabas de generar.

EmDash sondeará tu sitio WordPress y te mostrará un resumen del contenido disponible, algo parecido a esto:

Selecciona lo que quieres importar y lanza el proceso. El plugin transmite el contenido directamente desde WordPress a EmDash, incluyendo los medios. Para sitios con muchos archivos de medios, este método es bastante más rápido que el WXR porque no tienes que descargar un XML gigante a tu ordenador y luego volver a subirlo.

El plugin también admite importación incremental, así que puedes ejecutarlo varias veces durante una ventana de migración para sincronizar contenido nuevo sin duplicar lo que ya se importó.

Seguridad del proceso

El endpoint que crea el plugin solo es accesible con autenticación mediante la contraseña de aplicación. Nadie puede acceder a él sin las credenciales. Aun así, asegúrate de que tu WordPress tiene HTTPS habilitado antes de hacer la migración. Las contraseñas de aplicación viajan en las cabeceras de las peticiones HTTP, así que sin HTTPS estarías enviando las credenciales en texto plano.

Una vez terminada la migración, desactiva y borra el plugin de tu WordPress. No tiene sentido dejarlo instalado si ya no lo necesitas.

¿Y después de la migración que hago?

Importar el contenido es solo la primera parte. Si tu objetivo es que EmDash sustituya a tu WordPress en producción (algo que a día de hoy, con la versión 0.1.0, yo no recomendaría para un sitio real), hay varias cosas que necesitas resolver después.

Las URLs y el SEO

Si tu sitio WordPress tenía la estructura de permalinks /nombre-de-la-entrada/, necesitas asegurarte de que EmDash genera las mismas URLs. De lo contrario, todos tus enlaces posicionados en Google devolverán un 404 y perderás el tráfico orgánico.

EmDash tiene gestión de redirecciones integrada, así que puedes configurar redirecciones 301 desde las URLs antiguas a las nuevas si la estructura no coincide. Pero lo ideal es que las URLs sean idénticas para evitar problemas.

Revisa también que los metadatos de SEO (títulos, descripciones, URLs canónicas) se han importado correctamente si usabas Yoast SEO o Rank Math. El importador trae estos datos, pero conviene comprobar que están en el lugar correcto.

Los medios

Verifica que las imágenes se ven bien en el contenido importado. El proceso de importación intenta descargar los archivos y actualizar las URLs internas, pero si tenías imágenes con rutas absolutas metidas a mano en el HTML (fuera del sistema de medios de WordPress), esas podrían quedarse apuntando a tu WordPress antiguo. Revisa un par de entradas con muchas imágenes para asegurarte.

Los bloques de Gutenberg

Si tu contenido WordPress usaba bloques básicos de Gutenberg (párrafos, encabezados, imágenes, listas, citas, código), la conversión a Portable Text debería funcionar bien. Los bloques más complejos y específicos (columnas, grupos anidados, bloques de plugins como los de Kadence o Spectra) pueden perder formato o convertirse en HTML plano.

EmDash incluye un Block Kit Agent Skill que ayuda a reconstruir bloques personalizados como componentes nativos de EmDash. Si usas Claude Code u otro agente de IA compatible con Agent Skills, puedes apuntarlo al skill y pedirle que reconstruya tus bloques. No es magia, pero acelera bastante el proceso.

El tema

Tu tema de WordPress no migra, de esto te olvidas, pero no es diferente en WordPress. En EmDash los temas son proyectos de Astro con páginas, layouts y componentes. Si usabas un tema personalizado o un tema hijo con muchas modificaciones, toca reconstruirlo.

EmDash incluye un skill para portar temas de WordPress a EmDash con tablas de equivalencia entre los template tags de WordPress y las llamadas a la API de EmDash. Está pensado para dárselo a un agente de IA y que haga el trabajo pesado. Para temas sencillos puede funcionar, para temas complejos con mucha lógica en functions.php vas a necesitar reescribir bastante.

Las plantillas que trae EmDash pueden servirte como punto de partida si tu sitio encaja en alguno de esos formatos.

Los plugins es lo que duele

Aquí es donde la migración se pone cuesta arriba porque tus plugins de WordPress no migran y no tienen equivalente directo en EmDash. El ecosistema de plugins de EmDash está vacío, no hay directorio, no hay marketplace, no hay nada publicado salvo un par de experimentos que hizo la comunidad el día del lanzamiento.

Esto significa que toda la funcionalidad que dependía de plugins la pierdes, y en un WordPress típico, casi en cualquier web actual, los plugins son los que marcan la diferencia entre unas paginitas web o una web profesional. De todos modos vamos a repasar los casos más comunes y qué opciones tienes:

• SEO (Yoast SEO, Rank Math, SEOPress): EmDash trae funcionalidad SEO básica integrada (títulos, descripciones y URLs canónicas). Pero no tienes análisis de contenido, sitemaps XML configurables, esquema de datos estructurados avanzado ni la monitorización que ofrecen estos plugins. Para un blog sencillo puede valer, para un sitio que depende del SEO técnico te vas a quedar corto, y eso siendo generoso.
• Formularios de contacto (Contact Form 7, WPForms, Gravity Forms): No hay un sistema de formularios configurable como los que ofrecen estos plugins. Si tu negocio depende de formularios complejos con lógica condicional, integraciones con CRM o pagos, no tienes solución en EmDash ahora mismo.
• Caché y rendimiento (WP Super Cache, W3 Total Cache, Zero Config Performance Optimization): No los necesitas, en teoría, y de momento. EmDash en Cloudflare es serverless y funciona en el edge, así que el rendimiento es nativo de la arquitectura (Astro, Cloudflare). No hay capas de caché que configurar porque no hay un servidor PHP generando páginas en cada petición. Este es uno de los puntos donde EmDash tiene ventaja razonable.
• Seguridad (Wordfence, Vigilant, Solid Security): Tampoco los necesitas en el sentido tradicional. El modelo de sandboxing de plugins (si lo tienes en Cloudflare) y la identificación con passkeys eliminan las dos vías de ataque más comunes en WordPress, que suelen ser plugins vulnerables y contraseñas débiles. Eso sí, recuerda que el sandboxing solo funciona en Cloudflare de pago.
• Tienda online (WooCommerce, Easy Digital Downloads): No hay equivalente. EmDash tiene soporte nativo para x402 (micropagos por HTTP), que sirve para cobrar por acceso a contenido de forma automatizada, pero no es un sistema de ecommerce. No hay carrito, no hay gestión de productos, no hay pasarelas de pago tradicionales, no hay gestión de pedidos ni de envíos. Si tu web vende productos o servicios EmDash no es una opción.
• Maquetadores visuales (Elementor, Divi, Gutenberg). No existen en EmDash y no van a existir en el formato que conoces. Los temas en EmDash son código Astro (HTML, CSS, JavaScript/TypeScript). La edición permite modificar contenido de texto e imágenes pero no es un maquetador de arrastrar y soltar, no ya como Elementor, ni siquiera como Gutenberg. Si tu sitio fue creado entero con Elementor o Divi la migración implicaría reconstruir todo el diseño desde cero a pelo.
• Membresías y restricción de contenido (MemberPress, Restrict Content Pro, Paid Memberships Pro): No hay sistema de membresías integrado. El soporte de x402 permite cobrar por contenido individual, pero no gestiona suscripciones, niveles de acceso ni cuentas de usuario con contenido exclusivo al estilo de una membresía tradicional. También te olvidas de esto hasta que alguien no cree plugins y esas cosas a las que tan acostumbrados nos tiene sea CMS tan malo malísimo que es WordPress.
• Email marketing (Mailchimp, Mailerlite, etc.): No hay integración nativa con servicios de email marketing. Tendrías que implementar las conexiones tú mismo mediante un plugin personalizado de EmDash (usando el sistema de capacidades) o con los scripts de tu sistema de newsletter.
• Analítica (Site Kit, VigIA): No hay plugin de analítica ni rastreo. Puedes añadir manualmente el código de seguimiento de Google Analytics, Plausible o cualquier otro servicio en la plantilla de tu tema de Astro. No es difícil, pero tampoco tienes un panel integrado con los datos.
• Backups (UpdraftPlus, BackWPup, BlogVault): No hay sistema de backups integrado. En Cloudflare, la base de datos D1 tiene sus propios mecanismos de respaldo. En local con SQLite, la base de datos es un archivo que puedes copiar. Pero no hay nada comparable a la programación automática de backups con restauración en un clic que ofrecen estos plugins.

Vamos, que no hace falta casi que te lo diga, si tu WordPress usa más de tres o cuatro plugins para funcionar como necesitas, la migración a EmDash significa perder esa funcionalidad y esperar a que alguien la reconstruya (o hacerlo tú mismo).

Para un blog o un sitio de contenido donde los plugins principales eran SEO, caché y un formulario de contacto, la transición es más o menos viable. Para cualquier cosa más compleja el coste de la migración es muy alto y el resultado va a ser un sitio con menos funcionalidad que el que ya tenías.

¿Y si me arrepiento?, ¿se puede volver de EmDash a WordPress?

Antes de migrar conviene saber si tiene vuelta atrás. La respuesta corta es que sí, pero no es tan fácil como la ida. Curioso ¿verdad?. Recuerda, te querías ir de un sistema totalmente abierto a otro no tan abierto.

EmDash no tiene un botón de exportar WordPress. No existe un plugin exportador en sentido inverso ni un archivo WXR de salida. Lo que sí tiene es una API REST y una CLI que devuelve datos en JSON, así que el contenido es accesible de forma programática. La cuestión es cómo meterlo de vuelta en WordPress.

• El contenido en texto_ Tus entradas y páginas están almacenadas como Portable Text (JSON). Para llevarlas de vuelta a WordPress necesitas convertir ese JSON a HTML, que es lo que WordPress espera. No hay una herramienta oficial para hacerlo, pero Portable Text es un formato documentado y existen librerías en JavaScript (como @portabletext/to-html) que hacen la conversión. Con un script puedes extraer el contenido de la API de EmDash, convertirlo a HTML y usar la API REST de WordPress o WP All Import para importarlo. No es un clic, pero es factible.
• Los medios: Las imágenes y archivos están en el sistema de archivos local o en R2 de Cloudflare. Puedes descargarlos y subirlos a WordPress con cualquier método habitual (FTP, librería de medios, WP-CLI con wp media import). Lo que tendrás que actualizar después son las URLs internas del contenido para que apunten a la nueva ubicación en WordPress.
• Las taxonomías: Categorías, etiquetas y taxonomías personalizadas se pueden recrear en WordPress manualmente o por importación. Si tienes pocas, a mano va más rápido. Si tienes muchas, un script que lea la API de EmDash y escriba en la API REST de WordPress te ahorra tiempo.
• Los campos personalizados: Si creaste colecciones con campos tipados en EmDash (el equivalente a los Custom Post Types + ACF en WordPress), necesitas recrear la estructura en WordPress: registrar el tipo de contenido personalizado, configurar los grupos de campos en ACF y luego importar los datos. El mapeo no es automático.
• El SEO: Si EmDash importó tus títulos y descripciones de Yoast o Rank Math, esos datos están en las colecciones de EmDash. Puedes extraerlos y reimportarlos en WordPress asociándolos a los meta fields que usa tu plugin de SEO. Pero ojo: si durante el tiempo que estuviste en EmDash cambiaste URLs o estructura, tendrás que gestionar las redirecciones para no perder posicionamiento.
• Lo que no vuelve: Cualquier funcionalidad que construiste como plugin de EmDash (en TypeScript, con el modelo de capabilities) no se puede portar a WordPress. Tendrías que buscar el plugin de WordPress equivalente o reconstruir esa funcionalidad desde cero en PHP.

El escenario más realista para la vuelta es que si mantuviste tu WordPress original funcionando en paralelo mientras probabas EmDash (lo cual es lo recomendable con una beta), volver es simplemente seguir usando tu WordPress de siempre. El único contenido que tendrías que migrar de vuelta sería lo que hubieras publicado en EmDash durante el período de prueba, y eso normalmente es poco.

Moraleja: no borres tu WordPress hasta estar completamente seguro de que EmDash te funciona. Y con una versión beta ese momento está muy lejos siquiera de planteárselo.

¿Merece la pena migrar ahora?

Mi consejo de amigo es que no migres un sitio en producción a EmDash a día de hoy. La versión beta es para desarrolladores, no un producto listo para producción.

Pero si quieres probar cómo quedaría tu contenido, hacer una migración de prueba en local (con SQLite, sin coste) es rápido y no afecta a tu WordPress para nada. Exportas el WXR, lo importas en una instalación local de EmDash y en unos minutos tienes una idea bastante clara de lo que funciona y lo que no.

Otra posibilidad es animarte a instalarlo desde cero, y para eso también publiqué un tutorial con hasta 3 maneras de hacerlo, así que no puedes decir que no te lo pongo fácil, incluso te animo. Otra cosa es que sea fan, que te lo recomiende.

Si te interesa seguir el desarrollo de EmDash y compararlo con lo que ofrece WordPress, también te puede interesar el análisis completo que publiqué sobre EmDash, donde entro en detalle sobre la licencia MIT, el modelo de seguridad de plugins y si tiene sentido como alternativa real a WordPress.