WordPress 7.0: que se sabe, que es especulación, que hacer ahora

Una nota previa: al momento de escribir (abril de 2026), WordPress 7.0 esta en la hoja de ruta publica pero no se ha lanzado. Las listas especificas de funciones, los cambios de esquema y los cronogramas de migración que circulan en linea, incluyendo en publicaciones que se presentan como "guia completa", son en parte pronostico, en parte lista de deseos. Trata cualquier afirmacion definitiva sobre 7.0 como especulación hasta que aterrice en un release candidate publicado en el blog oficial de Make WordPress y etiquetado en el core trac.

Lo que sabemos por publicaciones publicas de Make WordPress: el trabajo de la Fase 3 sobre edicion colaborativa esta en curso, una integración mas profunda entre el Block Editor y los proveedores de IA se discute en reuniones del core, y el modelo de templating del Site Editor se esta refinando. Lo que aun no sabemos: que funciones de IA (si hay alguna) llegaran al core frente a quedarse como plugins, el minimo final de PHP, o la fecha exacta de lanzamiento.

Si planificas trabajo que se solapara con el ciclo de 7.0, el movimiento honesto es seguir make.wordpress.org/core y los tickets de core trac directamente, en vez de confiar en predicciones de terceros. La comunidad WordPress española, incluidos los organizadores de WordCamp España, sigue los mismos canales. Esta publicación es una de esas predicciones de terceros; leela con esa consciencia.

Descubre más sobre desarrollo profesional de WordPress en WPPoland.

#Que se sabe realmente sobre 7.0 ahora mismo

Quitando el envoltorio de marketing, el panorama es mas estrecho de lo que sugieren la mayoria de las publicaciones “guia completa”.

Confirmado en discusion publica de Make WordPress:

• La Fase 3 de la hoja de ruta de Gutenberg es el tema de trabajo, con la colaboración y el flujo de trabajo editorial como las dos areas que han visto mas propuestas publicas y PRs.
• La integración de IA se esta prototipando en el plugin Gutenberg y se discute en reuniones del core, pero la frontera entre “se entrega en el core” y “queda como plugin” no esta resuelta.
• El Site Editor y el sistema de patterns continuan iterandose, con refinamientos de la edicion de plantillas y el bloqueo de bloques aterrizando primero en releases puntuales 6.x.

No confirmado, pese a afirmaciones frecuentes:

• Una fecha especifica de lanzamiento para 7.0. Los calendarios de release se desplazan; trata cualquier fecha unica como un objetivo, no un compromiso.
• Una lista definitiva de funciones de IA en el core. Existen varias propuestas, incluidas abilities independientes del proveedor y una UI de connectors, pero las propuestas no son releases.
• El aumento del minimo de PHP y las deprecations exactas. Estas decisiones se toman tarde en el ciclo.

Para agencias y equipos de producto que entregan en 2026, la conclusion practica es mas simple que cualquier lista de funciones: construir sobre WordPress 6.x usando patrones compatibles con el futuro (block themes, theme.json, REST API, Action Scheduler para trabajo en segundo plano) para que, sea lo que sea que 7.0 acabe entregando, la migración sea incremental en lugar de una reescritura.

#IA en WordPress hoy, y hacia donde podria ir 7.0

La versión honesta de “funciones de IA en WordPress 7.0” comienza con lo que ya funciona en 6.x, porque eso es lo que ejecutan sitios reales.

Disponible hoy, en WordPress de producción:

• Yoast y Rank Math (incluyendo versiones en español) ambos incluyen asistentes de escritura asistidos por IA (titulos, meta descripciones, sugerencias de enlaces internos) construidos sobre APIs de modelos de terceros.
• Jetpack AI Assistant ofrece generación en el editor, resumen y traducción. La calidad varia segun el idioma y el prompt; la calidad en español es aceptable para borradores pero exige revisión editorial.
• Plugins independientes de generación de contenido existen en un amplio rango de calidad; utiles para borradores, peligrosos cuando se conectan directamente a la publicación sin revisión humana.
• Automattic y los equipos de contribuidores ejecutan experimentos de Fase 3, incluyendo edicion colaborativa y llamadas de IA del lado del editor, en el plugin Gutenberg antes de cualquier merge al core.

Una arquitectura pragmatica para añadir IA a un sitio WordPress hoy, que probablemente sobrevivira a lo que sea que 7.0 entregue:

• Expone un pequeño endpoint REST API por proveedor (OpenAI, Anthropic, Google, o un modelo auto-alojado). Manten el codigo especifico del proveedor detras de una interfaz para que cambiar de modelo sea un cambio de configuracion, no una reescritura.
• Ejecuta cualquier cosa que tarde mas de unos segundos a traves de Action Scheduler, no una solicitud sincrona. Este es el mismo patron que usa WooCommerce; escala.
• Almacena las claves de API como constantes de wp-config.php o via un almacen de secretos gestionado cargado en el arranque. Nunca pongas claves vivas en opciones de plugins ni en archivos .env commiteados a un repositorio.
• Cachea las respuestas con clave en un hash del prompt mas la versión del modelo. Las llamadas de IA son caras y se repiten con frecuencia.

Modos de fallo que vale la pena diseñar contra desde el primer dia:

• Fuga de claves de API mediante auto-actualizaciones de plugins o backups que incluyen volcados de wp-content.
• Fallos de rate-limit durante picos de trafico, que silenciosamente degradan la experiencia del editor si no hay fallback.
• Hechos, citas o especificaciones de producto alucinados publicados sin un paso de revisión humana. El coste de una pagina mala en busqueda es mayor que el coste de cualquier flujo de revisión.

Si 7.0 introduce una capa de abilities o connectors en el core, se aplican las mismas fronteras: la superficie de la API cambia, los modos de fallo no. Para etica y enmarque editorial, ve la guia de etica de contenido de IA para editores.

#Como prepararse sin adivinar la migración

Escribir una guia paso a paso “como migrar a 7.0” antes de que 7.0 se haya lanzado es deshonesto. Los comandos especificos de la versión, la rutina de actualización de la base de datos, los nuevos ajustes de admin: nada de eso es final. Cualquiera que publique pasos exactos de migración hoy esta rellenando huecos con suposiciones.

Lo que puedes hacer ahora es reducir el coste futuro de migración independientemente de como sea 7.0. El trabajo es ingrato y se paga en cada release, no solo en este.

Audita las partes del stack mas propensas a romperse en una actualizacion mayor:

• Temas que aun usan template tags en functions.php en vez de block themes. Convierte a block themes o planifica el trabajo.
• Bloques Gutenberg personalizados construidos contra versiones tempranas de @wordpress/scripts. Fija y prueba contra la ultima estable.
• Page builders con su propia capa de renderizado. Estas son la causa mas comun de deuda “no podemos actualizar”.
• Endpoints REST personalizados sin versionado. Añade namespacing /v1/ ahora para que un futuro incremento no sea disruptivo.

Configura la infraestructura aburrida que te permite actualizar rapido cuando 7.0 se lance:

• Un entorno de staging que refleje la versión de PHP, conjunto de plugins y volumen de contenido de producción. La paridad de base de datos importa mas de lo que la gente espera.
• Backups automatizados con un camino de restauración probado. Un backup no probado es teatro.
• Actualizaciones de plugins y temas corriendo a un ritmo regular, no aplazadas hasta el siguiente release mayor. Los sitios atascados en 6.0 estan atascados porque nadie actualizo 6.1 a 6.8.
• Una lista corta de autores de plugins en los que confias, con contactos de email. Cuando 7.0 se lance, querras saber dentro de una semana cuales de tus plugins estan probados contra el.

Cuando 7.0 alcance efectivamente RC en el calendario oficial de releases, la ruta de actualizacion es la misma que ha funcionado para cada release mayor de WordPress: ejecuta primero en staging, observa el log de errores, espera dos a cuatro semanas tras la disponibilidad general antes de tocar producción para sitios de clientes, y lee la publicación oficial de field guide en Make WordPress antes de asumir que cualquier guia de terceros (esta incluida) refleja lo que realmente se entrego.

#Que hacer hasta que 7.0 se lance realmente

Hasta que WordPress 7.0 alcance una release tagged en wordpress.org, lo mas util que cualquier equipo puede hacer es ignorar las publicaciones de prediccion (esta incluida) y seguir las fuentes primarias: el blog Make WordPress core, las notas de release de Gutenberg y el milestone de trac para 7.0.

Para un proyecto existente que entrega en 2026, construye sobre una release actual 6.x usando block themes, theme.json y la REST API. Trata la IA como una capa de integración detras de tus propios endpoints, no como una funcion por la que esperas que el core la provea. Cuando 7.0 aterrice, la migración se convierte en una pregunta de cuales de tus integraciones personalizadas pueden sustituirse por una API del core, no en una reescritura.

Si quieres ayuda para auditar un stack para preparación de actualizacion, nuestro equipo de desarrollo WordPress hace ese trabajo para sitios en producción en cada ciclo de release.