Si has llegado aquí doy por hecho que desarrollas plugins, temas o código a medida para WordPress, así que voy al grano. Esto no es una guía de actualización a WordPress 7.0 para usuarios, sino para devs, y nos vamos a centrar en lo que necesita atención técnica, en qué orden meterle mano y qué APIs nuevas merecen la pena para algo más que ir corriendo detrás de la compatibilidad.
WordPress 7.0 sale el 20 de mayo de 2026 tras el retraso de unas semanas que el equipo decidió para cerrar la arquitectura de la edición en tiempo real. La fase de RC ha sido más larga de lo habitual y la guía de campo está publicada con todas las dev notes individuales, así que tienes información de sobra para preparar el terreno antes de que llegue.
Vista rápida de los cambios técnicos que hay que revisar
Estos son los puntos donde WordPress 7.0 te puede afectar a desarrolladores, ordenados por probabilidad de que te toque hacer algo:
- Estilos propios del admin desalineados tras el rediseño visual del escritorio.
- Metaboxes clásicas que desactivan la edición en tiempo real en las entradas donde aparecen.
- Block API v3 y el comportamiento del editor en iframe.
WP_List_Tablesustituida porDataViewsen las pantallas de listados del editor del sitio.- PHP 7.4 mínimo en core, lo que afecta también a la compatibilidad de tus plugins y temas.
Y luego, lo que abre puertas nuevas:
- Connectors API para poder reutilizar las credenciales de IA centralizadas.
- Abilities API en core y no como experimento, lista para registrar capacidades en tu código para que cualquier IA externa pueda descubrirlas y usarlas.
PHP 7.4 mínimo
WordPress 7.0 sube el suelo a PHP 7.4 y deja atrás 7.2 y 7.3. Para ti como desarrollador esto significa dos cosas, y la primera es que la cabecera Requires PHP de tus plugins y temas debe declarar al menos 7.4, porque si dejas 7.0 o 7.2 el repositorio va a entender que tu código funciona en versiones con las que el core ya no admite.
Luego, además, te afecta el hecho de que puedes empezar a usar sintaxis que estuvo limitada hasta ahora, como arrow functions, typed properties, null coalescing assignment o spread operator en arrays asociativos.
Lo razonable es declarar la compatibilidad que hayas probado. Si tu plugin funciona desde PHP 7.4 hasta PHP 8.3, pones Requires PHP: 7.4 y compruebas en las dos puntas del rango, sin subir el mínimo a 8.0 sin necesidad, porque cerrarías la puerta a los hosting que todavía no han migrado a 8.x.
Block API v3 y el editor en iframe
Aquí hay un matiz que mucha gente está contando regular, no por mala fe, sino porque ha habido cambios. Originalmente la versión 7.0 iba a forzar el iframe en el editor de entradas para todos los bloques sin importar su apiVersion, pero en febrero el equipo del editor revisó el calendario y eligió un despliegue gradual.
Lo que pasa de verdad en WordPress 7.0 es que el editor comprueba la versión de los bloques insertados en el post, no la de los registrados en general, y si todos los bloques que hay en la entrada son v3 o superior el editor se carga en iframe, mientras que si hay alguno con v2 se queda fuera del iframe igual que ahora.
Esto significa que el iframe sigue avanzando, pero no se te va a romper la web el 20 de mayo si tu bloque está en la v2. Lo que sí toca hacer es migrar cuanto antes, porque la fase de aviso ha terminado y los próximos pasos sí van a ser obligatorios.
El cambio mínimo es trivial. En tu archivo block.json subes la apiVersion a la 3:
{
"apiVersion": 3,
"name": "ayudawp/mi-bloque",
...
}
Si tu bloque solo pinta cosas con React y no toca el DOM directamente con eso suele bastar. El problema viene cuando dentro del bloque accedes a document o window de forma directa, porque dentro del iframe esos objetos apuntan al iframe y no al admin, y ahí es donde se rompen muchas integraciones de scripts antiguos.
La forma correcta es usar el contexto del nodo del bloque mediante una referencia, accediendo a ownerDocument y defaultView:
import { useRef, useEffect } from '@wordpress/element';
export default function Edit() {
const ref = useRef();
useEffect( () => {
// Acceso correcto al document que contiene el bloque
const doc = ref.current.ownerDocument;
const win = doc.defaultView;
// A partir de aqui, doc y win apuntan al iframe del editor
// y todo lo que hagas se aplica donde toca
}, [] );
return <div ref={ ref }>...</div>;
}
Si dependes de librerías de terceros que tiran de window global, como plugins jQuery antiguos o sliders sin namespacing, toca revisar uno por uno. La buena noticia es que un bloque que ya funciona en el editor del sitio o en el editor de plantillas está prácticamente preparado, porque esos editores llevan años funcionando en iframe.
Cajas meta clásicas y la edición en tiempo real
Aquí no hay matiz que valga. Si tu código registra una caja meta clásica con add_meta_box(), la edición en tiempo real se desactiva en las entradas donde aparece esa caja, y el editor le muestra al usuario un aviso que pone «esta entrada usa plugins que no son compatibles con la colaboración en tiempo real».
No es un fallo, es una decisión arquitectónica del equipo, porque las cajas meta clásicas guardan datos por fuera de la capa del editor de bloques y no se pueden sincronizar entre clientes en tiempo real sin riesgo de perder cambios por el camino.
El camino correcto es registrar tu caja meta con register_post_meta() y show_in_rest a true, para que esté dentro de la capa de datos del editor de bloques:
/**
* Registra el meta del plugin de forma compatible con la colaboracion en tiempo real.
*/
function ayudawp_register_post_meta() {
register_post_meta(
'post',
'_ayudawp_destacado',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'boolean',
'default' => false,
'auth_callback' => function() {
return current_user_can( 'edit_posts' );
},
)
);
}
add_action( 'init', 'ayudawp_register_post_meta' );
A partir de aquí, en lugar de ofrecer la caja meta clásica entregas un panel en la barra lateral del editor de bloques con PluginDocumentSettingPanel y enganchas los datos del meta usando los hooks de @wordpress/data.
Si quieres ver el caso real con todo el código de migración, en este artículo enseño cómo migré la caja meta de AI Share & Summarize a un panel lateral del editor manteniendo la compatibilidad con el editor clásico, porque ambos sistemas leen y escriben en la misma clave de meta.
Si por lo que sea no puedes migrar antes del 20 de mayo no es ningún drama, ya que la caja meta clásica sigue funcionando como hasta ahora y lo único que pierde el usuario es la edición simultánea en esas entradas. Eso sí, deja claro en el changelog del plugin que la migración está en marcha, porque la gente que active la colaboración va a ver el aviso y va a buscar al culpable.
Rediseño visual del admin
El admin de WordPress 7.0 estrena lo que en el ticket #64308 de Trac llaman un «coat of paint visual reskin».
Son cambios solo en CSS y no tocan markup ni JavaScript, así que sobre el papel cualquier plugin debería seguir funcionando igual, pero en la práctica te dejan mal, porque hay muchos plugins con estilos propios para sus botones, sus tablas y sus avisos, y esos estilos chocan con los nuevos espaciados y tipografías unificadas.
El esquema por defecto pasa del fresco al moderno, los componentes del sistema de diseño están alineados con @wordpress/components y @wordpress/base-styles, y el resultado es que cualquier estilo que pelee contra el sistema queda desalineado o con dimensiones raras.
Te lo digo desde la experiencia, he tenido que repasar estilos en plugins propios y ajenos para que las pantallas de ajustes vuelvan a verse limpias, y no es algo que se solucione con un parche en cinco minutos cuando hay mucho CSS heredado.
La forma de evitar este problema, ahora y en futuras versiones, es usar las clases nativas del admin y dejar de inventar selectores propios para cosas que el core ya genera:
- Botones con
button,button-primary,button-secondaryybutton-linken lugar de tus propias clases. - Tablas con
wp-list-table widefat fixed striped. - Avisos con
notice notice-success,notice notice-error,notice notice-warningenotice notice-info, añadiendois-dismissiblesi quieres el botón de cerrar. - Formularios con
form-tabley la API de Settings, que ya te da el aspecto correcto sin escribir CSS propio.
Si ya tienes hojas de estilo propias para el admin, una limpieza rápida pasa por quitar los !important innecesarios, sustituir píxeles fijos por las variables CSS del sistema de diseño y revisar selectores demasiado genéricos del tipo .button o input[type="submit"] sin contexto, encerrándolos en el contenedor de tu plugin para que no se peleen con nada del core.
DataViews en vez de WP_List_Table
Las pantallas de listados en el editor del sitio pasan a usar el sistema DataViews en lugar de la vieja WP_List_Table. Para el usuario es una mejora visible, con filtros que se aplican sin recargar y vistas configurables, y para el desarrollador es un cambio de modelo, porque los ganchos de siempre que añadían columnas, filtros o acciones rápidas no se aplican igual.
Si usas hooks como manage_posts_columns, manage_pages_columns, manage_media_columns o sus equivalentes para acciones rápidas y acciones en lote, siguen funcionando con retro-compatibilidad, pero la experiencia ya no es la misma y algunos casos avanzados se rompen.
La parte donde más he visto problemas, porque soy un bobo y me pasa de todo, es en plugins que pintaban cajas meta ocultas vinculados a columnas, o que insertaban controles personalizados directamente en el thead de la tabla.
Si tu plugin o tema necesita integrarse con estas pantallas, toca pasar por @wordpress/dataviews y registrar las vistas con la nueva API. Hay también un cambio menor pero importante en la API, el parámetro groupByField como string ha sido sustituido por un objeto groupBy con más opciones, así que si has tocado esto en versiones anteriores, ajústalo.
Para la mayoría de código, que solo añade una columna o un filtro sencillo, no hay que hacer nada urgente, pero conviene probar la pantalla en un staging con WordPress 7.0 antes de soltarlo a producción.
Connectors API: integración con la IA desde el core
Una de las novedades más interesantes para devs que tocamos IA es la pantalla nueva en Ajustes > Conectores.
Hasta ahora, cada plugin que conectaba con OpenAI, Anthropic, Gemini o cualquier otro proveedor montaba su propia pantalla de ajustes con su propio formulario para la API key, lo que provocaba que el usuario tuviera que meter la misma clave en tres sitios distintos si usaba tres plugins de IA. Con la Connectors API esto cambia.
De serie vienen tres conectores, OpenAI, Anthropic y Google, y si quieres registrar el tuyo propio o ajustar los metadatos de uno existente, lo haces a través del action wp_connectors_init:
/**
* Registra un conector personalizado para un proveedor de IA
*/
function ayudawp_register_connector( $registry ) {
$registry->register( 'mi-proveedor-ia', array(
'name' => 'Mi Proveedor IA',
'description' => __( 'Conector para mi servicio de IA personalizado.', 'mi-plugin' ),
'authentication' => 'api_key',
'icon' => plugins_url( 'assets/icon.svg', __FILE__ ),
'documentation_url' => 'https://miproveedor.com/docs/',
) );
}
add_action( 'wp_connectors_init', 'ayudawp_register_connector' );
El registro automático genera un nombre de opción siguiendo el patrón connectors_ai_{$id}_api_key, y la API key queda disponible para cualquier plugin compatible que la quiera usar mediante wp_ai_client_prompt(). Eso significa que si tu plugin usa el AI Client del core no tienes que pedirle al usuario una clave API propia, ya está.
Un apunte importante es que en la versión 7.0 de WordPress solo los conectores con identificación de tipo api_key reciben la UI completa en la pantalla de conectores, mientras que otros métodos de identificación están aceptados por el registro PHP pero la integración visual completa llegará en la 7.1. Si tu proveedor usa OAuth conviene esperar o registrar la UI por tu cuenta de momento.
Abilities API ya de verdad en WordPress 7.0
Si solo te llevas una cosa de este artículo que sea esta. La Abilities API entra en 7.0 ya a tope en el núcleo de WordPress y no como experimento ni como propuesta, y es la pieza que va a transformar la forma en que las IAs interactúan con tu sitio.
La idea es que si tu desarrollo registra abilities concretas con un nombre, una descripción, parámetros y un callback, y esas capacidades quedan disponibles tanto vía REST como vía MCP para que cualquier IA externa las pueda descubrir y ejecutar de forma estandarizada.
Te dejo un ejemplo mínimo de registro de una ability:
/**
* Registra una ability para que pueda ser descubierta por agentes externos.
*/
function ayudawp_register_ability() {
wp_register_ability( 'ayudawp/contar-entradas', array(
'label' => __( 'Contar entradas publicadas', 'ayudawp' ),
'description' => __( 'Devuelve el numero de entradas publicadas en el sitio.', 'ayudawp' ),
'input_schema' => array(
'type' => 'object',
'properties' => array(
'post_type' => array(
'type' => 'string',
'default' => 'post',
'description' => __( 'Tipo de contenido a contar.', 'ayudawp' ),
),
),
),
'execute_callback' => function( $input ) {
$post_type = isset( $input['post_type'] ) ? sanitize_key( $input['post_type'] ) : 'post';
$count = wp_count_posts( $post_type );
return array(
'count' => isset( $count->publish ) ? (int) $count->publish : 0,
);
},
'permission_callback' => function() {
return current_user_can( 'edit_posts' );
},
) );
}
add_action( 'abilities_api_init', 'ayudawp_register_ability' );
A partir del momento en que tu código registra esta ability una IA con acceso al sitio puede descubrirla, leer su esquema de entrada, pedir el permiso correspondiente y ejecutarla, todo sin que tengas que escribir un endpoint REST adicional ni una integración específica con cada IA del mercado.
Si te interesa entender por qué esto cambia el panorama y qué es exactamente la Abilities API a fondo, lo cuento en este artículo introductorio, y para el caso práctico de cómo registrar abilities en tus plugins y temas tienes el detalle en este otro.
El siguiente paso natural, una vez que tienes abilities registradas, es exponerlas usando MCP para que herramientas como Claude Code, Cursor o cualquier asistente compatible con el Model Context Protocol puedan usarlas directamente. Eso es harina de otro costal y da para un artículo aparte, pero conviene que lo tengas en el radar.
Resumen de comprobaciones antes del 20 de mayo
Si tienes un plugin o tema en producción y quieres asegurarte de que no se te rompe nada con la actualización a 7.0, esta es la rutina que sigo yo:
- Comprueba la cabecera
Requires PHPsúbela a7.4si todavía está en7.2o7.3. - Sube la cabecera
Tested up toa7.0tras probarlo de verdad, no por las buenas. - Cambia la
apiVersionde tus bloques a3en elblock.json. - Revisa los
documentywindowdirectos en el código del bloque y sustitúyelos porownerDocumentydefaultViewa través de una referencia. - Si registras cajas meta clásicas, plantea la migración a
register_post_meta()conshow_in_restatrue. - Pasa todas las pantallas de ajustes de tu plugin o tema por el navegador con WordPress 7.0 y mira si hay desalineaciones en botones, tablas o avisos.
- Si tu desarrollo manipula columnas, filtros o acciones rápidas en las pantallas de entradas, páginas o medios, prueba el comportamiento con
DataViewsactivado. - Si conectas con IAs de terceros, valora migrar la gestión de credenciales a la Connectors API.
- Si quieres dar un paso más allá, registra
abilitiesconcretas de tu plugin o tema para que las puedan descubrir agentes externos. - Activa
SCRIPT_DEBUGen tu entorno de pruebas y revisa la consola del navegador en busca de avisos dedeprecated.
Recursos oficiales para profundizar
Para entrar al detalle técnico de cualquiera de estos cambios, los enlaces que conviene tener a mano son:
- Guía de campo de WordPress 7.0, con todas las dev notes individuales recopiladas en un único índice.
- Etiqueta dev-notes-7-0 en Make WordPress Core, donde están publicadas las notas a medida que salen.
- Guía de migración de bloques a iframe en el handbook del editor de bloques.
- Introducing the Connectors API in WordPress 7.0, dev note oficial.
Y si quieres pasar el resumen a tus clientes
Mañana publico el artículo hermano de este, dirigido a propietarios de webs hechas con WordPress, y lo escribo justo para que se lo puedas pasar a quien delegue en ti la actualización del sitio sin entrar en código. Lo enlazaré aquí en cuanto esté disponible.
Si en tus revisiones ves algún caso raro que no termina de encajar con lo que cuento, escríbeme en los comentarios. Cualquier patrón que aparezca en plugins reales y que merezca la pena cubrir lo voy añadiendo en revisiones del artículo.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
