El 5 de junio de 2026, el equipo de WordPress publicó un post que suena a nota técnica rutinaria: la actualización a React 19 en Gutenberg se había revertido temporalmente. Lo leí dos veces porque el titular no refleja lo que pasó en la práctica. Gutenberg 23.3.0 salió con React 19, plugins empezaron a petar en producción, y dos días después llegó el 23.3.2 con marcha atrás. No fue un retraso de calendario. Fue un choque en caliente.
Si mantienes sitios WordPress con plugins de pago, integraciones propias o un stack de editor personalizado, esto no es una anécdota de desarrolladores. Es la prueba de que el ecosistema que te venden como estable sigue dependiendo de capas que nadie controla del todo: React, el runtime JSX embebido en cada plugin, y un calendario de releases que no espera a que tu cliente termine la migración.
La historia oficial, recogida en Make WordPress Core, admite el problema sin dramatizarlo. El plan era razonable: subir a React 19 en el plugin Gutenberg, usar el ciclo completo del plugin como ventana de pruebas y meter el salto en WordPress 7.1, previsto para el 19 de agosto. WordPress 6.6 ya había avisado con deprecaciones en React 18.3. Todo muy ordenado, en papel.
En la calle fue otra cosa. Plugins compilados contra React 18 incluían su propio helper react/jsx-runtime. React 19 cambió la forma de los elementos JSX y, lo peor, rechaza activamente los generados con el runtime anterior. No es un warning bonito en consola: es pantalla en blanco, panel de bloques muerto, metaboxes que desaparecen. En un CMS que vive de plugins, eso es caída de negocio disfrazada de actualización menor.
Lo que me choca no es el fallo. Los upgrades de dependencias rompen cosas. Lo que me choca es la velocidad con la que se empujó React 19 al canal estable de Gutenberg sin un colchón real para el inventario de plugins ya publicados. El propio post habla de que la estrategia fue «menos ingenua» de lo necesario. Traducción: salió antes de tiempo y ahora toca inventar una capa de compatibilidad, un flag experimental (gutenberg-react-19) y más pruebas e2e. O sea, lo que debió existir antes del 23.3.0.
En el blog para desarrolladores de junio, Fatih Kadir Akín lo deja en la sección de cosas a vigilar: React 19 sigue siendo el objetivo para 7.1, pero el revert obliga a repasar patrones obsoletos (ReactDOM.render(), findDOMNode(), defaultProps en componentes funcionales, refs mal gestionados). Bien. Pero si tu plugin no es un block editor de moda y lleva cinco años sin tocarse, ese consejo suena a lista de la compra para otro equipo. El tuyo tiene un cliente que pregunta por qué el CRM embebido en el admin dejó de cargar tras activar Gutenberg.
The WP Clan lo resume con una frase que me resuena: el revert es un regalo, no un aplazamiento. WordPress 7.1 sigue en el calendario. Tienes unas diez semanas desde mediados de junio para dejar de empaquetar tu propio JSX runtime y tratar @wordpress/element como la superficie canónica en admin y editor. Las capas de compatibilidad suavizan la migración; no la sustituyen. Si eres agencia, eso significa auditar el stack de cada cliente antes del verano, no cuando salga el RC.
Y aquí está la parte incómoda para quien vende mantenimiento WordPress estándar. El 97% de vulnerabilidades en el ecosistema vienen de plugins y temas, no del core. Eso ya lo sabíamos. Pero este episodio muestra otra grieta: la fragilidad estructural del admin moderno. Cada plugin que mete su copia de React o su runtime JSX es una bomba de compatibilidad. WordPress intenta centralizar dependencias, pero el directorio lleva décadas premiando la velocidad de publicación sobre la homogeneidad del stack. No puedes exigir disciplina a 78.000 plugins y luego sorprenderte cuando una subida de versión menor tumba mitad del back office.
¿La respuesta del core? Más infraestructura: dos builds de React en vendors, polyfills, experimentos, tests con plugins simulados que imitan patrones legacy. Suena sensato técnicamente. Para ti, como responsable de un sitio en producción, suena a otro vector de prueba que no pediste. Cada flag experimental en Gutenberg es una bifurcación más entre «lo que funciona en mi entorno» y «lo que WordPress considera el futuro». Eso encarece QA y alarga ventanas de despliegue. No es teórico: ya pagaste el precio con 23.3.0.
Tampoco ayuda el contexto del mes. En junio, WordPress anunció Protect The Shire, con 24 horas de espera en auto-updates de plugins por seguridad. En paralelo, empuja React 19, lo revierte, y te pide que pruebes colaboración en tiempo real para 7.1. El mensaje es contradictorio: te frenan actualizaciones por precaución y al mismo tiempo aceleran cambios de plataforma que rompen producción. Entiendo la estrategia de largo plazo. Lo que no entiendo es quién asume el coste operativo de cada vaivén: el core team lo documenta; tú lo explicas al cliente.
Mi lectura, y aquí meto mano, es que WordPress 7.x está intentando demasiadas cosas a la vez para un ecosistema tan heterogéneo: IA nativa, edición colaborativa, React 19, procesamiento de medios en cliente, guidelines para tono de marca. Cada pieza tiene sentido en una demo. En un hosting compartido con 40 plugins activos, la suma es riesgo acumulado. El revert de React 19 no es una excepción; es la forma en que este ciclo de releases va a funcionar: avance, rotura, parche, compat layer, blog post tranquilizador.
¿Qué haría yo ahora, en tu lugar? Tres cosas concretas. Primero, congelar Gutenberg por encima de la versión empaquetada en tu core hasta tener un entorno de staging que replique el admin real, no un Playground limpio. Segundo, inventariar plugins que toquen el editor o el admin con JavaScript propio; si alguno lleva más de un año sin actualizar, asúmelo como candidato a fallo en 7.1. Tercero, negociar con el cliente que «actualizar WordPress» ya no es un clic: es una ventana de pruebas con coste. Si no lo metes en el presupuesto, lo pagarás en horas nocturnas.
WordPress seguirá siendo la opción razonable para muchos proyectos. Lo sigo recomendando. Pero dejar de fingir que el ecosistema de plugins es un mercado ordenado sería un buen primer paso. React 19 volverá. La pregunta no es si, sino cuántos sitios volverán a romperse antes de que la capa de compatibilidad esté fina de verdad.
Si tu contrato de mantenimiento incluye «actualizaciones incluidas» pero no menciona pruebas de regresión en el admin, ¿subirías hoy Gutenberg 23.4 en un ecommerce con quince plugins activos la semana antes de rebajas?