Si mantienes un WordPress en serio, abril de 2026 te ha dejado dos mensajes en la mesa. El primero es técnico y visible: Gutenberg 22.9 ya está ahí, con mejoras de editor que suenan a detalle de diseño pero acaban tocando cómo trabajan equipos enteros. El segundo es político y de calendario: el ciclo de WordPress 7.0 se ha estirado porque la colaboración en tiempo real necesita un arreglo de arquitectura más profundo que un parche de última hora. Yo te cuento qué me importa de verdad de cada cosa y qué haría yo antes de darle al botón de actualizar en un sitio con tráfico.
Empiezo por lo que ha publicado el equipo del editor sobre Gutenberg 22.9. El bloque Group ahora permite combinar gradientes de fondo con imagen de fondo sin que se pisen, lo que en la practica significa overlays y capas de lectura sin pelearte con CSS a mano en cada landing. La paleta de comandos (Cmd+K / Ctrl+K) gana secciones y sugerencias, pero ojo: va como experimental y hay que activar el experimento de “Workflow Palette” en el plugin si quieres probarlo en condiciones. No es un cambio para el usuario final distraído; es una señal de que WordPress sigue empujando el editor hacia un entorno de productividad tipo IDE, con lo bueno y lo malo que eso trae.
También entra en juego el paquete wordpress/ui con un componente de estados vacíos (EmptyState) y, en el apartado de colaboración, varios arreglos de sincronización de notas y bloqueos entre sesiones. Si en tu agencia ya habéis probado la edición colaborativa, sabes que esas cosas no son “cosmética”: son la diferencia entre “podemos trabajar en paralelo” y “alguien refresca y se pierde el hilo”. Yo no vendo la moto de que todo el mundo necesite RTC en el blog de la empresa; pero cuando lo necesitas, la estabilidad es el producto.
Aquí es donde entra el segundo documento que te recomiendo leer con calma: el resumen para desarrolladores de abril en el Developer Blog. Ahí se explica el contexto del retraso de 7.0: volver a fase beta después de haber tocado Release Candidate no es lo habitual, y la razón que dan es clara: la implementación actual de sincronización en tiempo real tiene un problema de rendimiento ligado a cómo se guardan datos y a cómo interactúa con caches de consultas persistentes. La solución que barajan pasa por una tabla dedicada para datos de colaboración, no un parche superficial. El calendario de prelanzamientos se pausa hasta el 17 de abril y el nuevo plan debería quedar publicado antes del 22 de abril. Traducción para el que factura por proyecto: tus estimaciones de “cuando salga 7.0” siguen siendo humo hasta que ese calendario se cierre.
¿Qué te afecta a ti si tu negocio no es contribuir al núcleo? Te afecta en tres frentes que no son abstractos:
- PHP: en WordPress 7.0 se cae el soporte para PHP 7.2 y 7.3; el mínimo pasa a 7.4 y la recomendación apunta a 8.2 o superior. Si tu hosting sigue en una versión antigua por comodidad, el problema no es el blog en sí: es el contrato de mantenimiento que no actualizaste.
- Plugins y temas: la interacción entre nuevas APIs (cliente de IA, conectores, abilities en el cliente) y la Interactivity API significa que “no tocar nada” deja de ser una estrategia neutra. Si tu plugin favorito usa patrones viejos, el riesgo de fricción sube.
- Hosting y rendimiento: funciones como la colaboración en tiempo real empujan a que el servidor y la capa de caché se entiendan con sesiones largas y sincronización. No es magia: si tu proveedor te vende “WordPress optimizado” pero no te permite ajustar PHP-FPM, timeouts o exclusiones de caché para el editor, vas a notar el dolor antes en el escritorio que en el front.
Yo no soy de los que celebran cada release como si fuera Navidad. Prefiero mirar si el cambio reduce trabajo repetido o añade superficie de error. En 22.9 veo lo primero en diseño y edición (gradientes + imagen, bloque Forms con campos ocultos, etc.) y lo segundo si activas todo lo experimental sin un entorno de pruebas. Si encima mezclas eso con la incertidumbre del calendario de 7.0, la tesis es sencilla: prueba en staging, mide, y no confundas “núcleo nuevo” con “mi web lista para producción”.
En mi experiencia, los clientes no te preguntan por el número de PRs fusionados en Gutenberg; te preguntan si el editor se va a comer el fin de semana. Por eso me gusta que el proyecto haya frenado cuando el diagnóstico de fondo no cuadra. Me gusta menos que quienes venden WordPress como “fácil” sigan sin contar el coste real de mantenerlo al día. Pero prefiero un retraso con motivos técnicos publicados a un lanzamiento forzado que te deje el escritorio en llamas.
Fuentes
- What’s new in Gutenberg 22.9? (8 April) – Make WordPress Core
- What’s new for developers? (April 2026) – WordPress Developer Blog
- The path forward for WordPress 7.0 – Make WordPress Core
Si tu proveedor te dijera que el próximo WordPress major solo lo garantiza en PHP 7.2 y sin tocar el plan de hosting, ¿migrarías antes de que te cierre el calendario o esperarías a que te lo imponga un fallo en producción?