La primera llamada que recibe una agencia después de una actualización mayor rara vez es por un error 500. Suele ser una persona de marketing preguntando por qué el panel se ve distinto y dónde ha ido a parar el botón que usaba cada mañana. WordPress 7.0 «Armstrong», publicado el 20 de mayo de 2026, trae exactamente ese tipo de cambio: el nuevo escritorio de WordPress 7 no rompe nada de forma evidente, pero reordena la superficie con la que trabaja a diario todo el equipo que administra el sitio.
El cambio tiene tres piezas visibles y una cuarta que solo se nota cuando algo falla. Las visibles son el nuevo esquema de color por defecto, las transiciones de vista que evitan la recarga completa al moverse entre pantallas y la paleta de comandos global disponible con Cmd+K o Ctrl+K en toda la administración, no solo dentro del editor. La cuarta es DataViews, el sistema que empieza a sustituir a las tablas clásicas de listados. Esa es la que afecta a quien haya escrito código propio contra WP_List_Table en los últimos diez años, y la que conviene revisar antes de tocar producción.
Este artículo se centra en el nuevo escritorio: qué cambia para el usuario final, qué cambia para quien mantiene el sitio y cómo comunicar la transición a un cliente que se encuentra el panel distinto sin previo aviso. Si buscas la visión completa de la versión y el plan de actualización, lo tienes desglosado en nuestra guía para actualizar a WordPress 7 en un entorno de empresa. Aquí bajamos al detalle de la interfaz de administración, que es donde tu equipo pasa las horas.
1. El nuevo escritorio de WordPress 7: un rediseño que no es solo estético
Lo primero que se percibe al entrar en wp-admin tras la actualización es el color. WordPress 7.0 estrena un esquema por defecto distinto al que arrastrábamos desde hace años, con un tratamiento más sobrio del menú lateral y de los acentos de interfaz. No es un cambio de marca ni un capricho: acompaña a la unificación progresiva entre el editor de bloques y el resto de la administración, que hasta ahora convivían con dos lenguajes visuales bastante distintos.
La buena noticia para quien gestiona equipos acostumbrados a una interfaz concreta es que el esquema «Fresco» sigue estando disponible. Cada usuario puede recuperarlo desde su perfil, en la pantalla de opciones personales. No hay que tocar código ni instalar nada. Es un detalle menor en apariencia, pero resuelve el 80% de las quejas iniciales de un equipo editorial numeroso: quien no quiera el cambio de color, no lo tiene.
El segundo ajuste visible son los campos de formulario más altos. Los inputs, selects y áreas de texto ganan altura y área de pulsación. Sobre el papel es una mejora de accesibilidad y de uso en pantallas táctiles; en la práctica tiene un efecto secundario que conviene anticipar. Cualquier interfaz que un plugin o un tema inyecte en el admin usando las clases y los tamaños antiguos va a quedar desalineada respecto a los controles nativos que tenga al lado.
Qué se rompe realmente aquí
Nada crítico, pero sí cosmético y visible para el cliente. Los casos que hemos visto con más frecuencia son metaboxes personalizados con alturas fijas en píxeles, pantallas de ajustes de plugins que combinan controles nativos con controles propios, y tablas de configuración donde un input nativo más alto desplaza el resto de la fila. También aparecen desajustes en interfaces que posicionan elementos de forma absoluta contando con la altura anterior de un campo.
La revisión es rápida si se hace con método: abre las pantallas de administración que tu equipo usa a diario en un entorno de staging, en resolución de escritorio y en tablet, y anota lo que se ve mal. No hace falta auditar las 200 pantallas del panel. Hace falta auditar las quince que alguien abre todos los días.
2. Transiciones de vista: navegar sin recarga completa
El segundo cambio estructural es la navegación entre pantallas del administrador sin recarga completa de página. Al pasar de un listado a otro, o de una vista a su detalle, la interfaz transiciona en lugar de repintar el navegador desde cero. Para el usuario, la sensación es de aplicación en lugar de web clásica: el menú lateral no parpadea, el foco no se pierde y el desplazamiento vertical no salta al inicio.
El beneficio real no es la estética de la transición. Es el tiempo acumulado. Un editor que se mueve doscientas veces al día entre el listado de entradas, la biblioteca de medios y la pantalla de edición ahorra fracciones de segundo que suman, y sobre todo evita la interrupción cognitiva de la recarga. En equipos que trabajan con volumen alto de contenido, esto se nota en la primera semana.
Qué implica técnicamente
Aquí es donde conviene ser honesto: cualquier cosa que asuma que cada pantalla del admin es una carga de página completa puede comportarse de forma extraña. Los patrones que revisamos siempre son tres.
El primero es el código que se engancha a DOMContentLoaded o al ready de jQuery esperando que se dispare en cada navegación. Si la pantalla se sustituye sin recarga, ese evento no vuelve a ocurrir y la inicialización se queda a medias. Los síntomas típicos son un selector que deja de funcionar al segundo uso, un datepicker que no se engancha o un contador que se queda congelado.
El segundo son los listeners globales que se registran varias veces sin limpiarse. Al no destruirse el contexto anterior, se acumulan y acabas con la misma acción ejecutándose dos o tres veces. Esto es especialmente feo en acciones que escriben datos: un guardado duplicado en una pantalla de ajustes puede pasar desapercibido durante meses.
El tercero es el estado global en variables de JavaScript que antes se reseteaba de forma natural con cada recarga y ahora persiste. Es la fuente clásica de errores fantasma que solo se reproducen «cuando llevo un rato en el panel».
Si mantienes plugins propios con interfaz en el admin, la delegación de eventos sobre un contenedor estable y la inicialización idempotente dejan de ser buena práctica opcional y pasan a ser requisito. No es un trabajo enorme, pero hay que hacerlo con la pantalla delante y no de memoria.
3. DataViews: el sistema que sustituye a las tablas clásicas de listados
DataViews es el cambio de más calado de todo el rediseño, y también el que menos se nota el primer día. Se trata del componente unificado con el que WordPress presenta colecciones de elementos: entradas, páginas, plantillas, patrones, medios. En lugar de la tabla HTML rígida de siempre, ofrece un contenedor con vistas alternativas, filtrado, ordenación y agrupación resueltos de forma moderna y coherente entre pantallas.
Para el usuario final es una mejora directa. Poder cambiar entre vista de tabla y vista de cuadrícula, filtrar por varios criterios combinados sin recargar y guardar una configuración de vista concreta cambia la forma de trabajar con bibliotecas grandes. Quien administra un sitio con miles de entradas y una taxonomía compleja lo agradece en la primera sesión. Quien tiene cuarenta páginas, apenas lo notará.
A quién afecta de verdad
La respuesta corta: a quien haya extendido WP_List_Table. La respuesta larga merece detalle, porque hay mucha confusión al respecto.
Durante más de una década, la forma canónica de personalizar un listado de administración ha sido engancharse a los filtros de la tabla clásica. Columnas propias con manage_{$post_type}_posts_columns y su pareja manage_{$post_type}_posts_custom_column. Ordenación con manage_edit-{$post_type}_sortable_columns. Filtros a medida inyectados en restrict_manage_posts y procesados en pre_get_posts. Acciones masivas con bulk_actions-{$screen} y handle_bulk_actions-{$screen}. Enlaces de acción por fila con post_row_actions. Y, en el peor de los casos, subclases enteras de WP_List_Table escritas a mano para pantallas propias.
Todo eso está construido sobre la premisa de que el listado es una tabla renderizada en PHP durante la carga de la página. DataViews rompe esa premisa: renderiza en el cliente a partir de datos servidos por la API REST. Los filtros de PHP que modifican el marcado de una tabla no tienen dónde aplicarse cuando esa tabla no se genera en PHP.
Qué se puede romper, en orden de probabilidad
Empezando por lo más frecuente. Las columnas personalizadas que muestran un dato calculado, un estado de sincronización con un ERP o un indicador de un flujo interno son el caso número uno: dejan de aparecer cuando la pantalla migra a DataViews, sin error ni aviso. Simplemente no están.
Le siguen los filtros a medida colocados sobre el listado. Los desplegables que un desarrollador añadió para filtrar pedidos por comercial asignado, entradas por campo personalizado o productos por proveedor viven en restrict_manage_posts y desaparecen con la tabla clásica.
En tercer lugar, las acciones masivas propias. Suelen ser las más críticas del conjunto, porque son las que ejecutan procesos de negocio: reenviar a un sistema externo, recalcular precios, regenerar un campo derivado. Su pérdida no rompe la web, pero rompe un procedimiento operativo que alguien ejecuta cada semana.
Y por último, las subclases completas de WP_List_Table para pantallas propias. Aquí la buena noticia es que ese código sigue funcionando mientras la clase permanezca en el core: si has creado tu propia pantalla de administración con tu propia tabla, no se convierte automáticamente a DataViews ni deja de renderizar. La mala es que tu pantalla propia va a verse cada vez más distinta del resto del panel, y esa deuda visual crece con cada versión.
Cómo abordar la revisión sin desmontar todo
Nuestra recomendación de agencia es no reescribir por adelantado. La migración a DataViews en el core es progresiva: no todas las pantallas cambian a la vez, y lo que hoy sigue en tabla clásica puede cambiar en 7.1 o 7.2. Reescribir una integración entera antes de saber qué pantalla concreta migra y cuándo es gastar presupuesto en una apuesta.
Lo que sí conviene hacer ahora es un inventario. Recorre el código propio y de los plugins que mantienes buscando los enganches de la tabla clásica. Un grep por manage_, restrict_manage_posts, bulk_actions, row_actions y WP_List_Table sobre el directorio de plugins y el tema te da el mapa en diez minutos. Anota qué hace cada uno, quién lo usa y qué pasa si desaparece.
Con ese inventario delante, clasifica en tres cajas. Lo cosmético que puede esperar. Lo que sostiene un procedimiento operativo y necesita alternativa antes de que la pantalla migre. Y lo que ya no usa nadie, que es más de lo que parece y se puede borrar. Esa tercera caja suele justificar por sí sola la hora dedicada al inventario.
Para lo que hay que conservar, la dirección técnica está clara: exponer el dato por la API REST y consumirlo desde el cliente. Registrar campos con register_rest_field, asegurar que los parámetros de consulta que necesitas están soportados y trasladar la lógica de acción masiva a un endpoint propio. Es más trabajo que un filtro de PHP de cinco líneas, pero es código que sobrevive a la siguiente versión. Si estás valorando ese salto, muchas de las decisiones se parecen a las que ya se toman al plantear una arquitectura headless con WordPress y Next.js: la API deja de ser un extra y pasa a ser el contrato principal.
¿Tienes listados de administración personalizados y no sabes qué pasará con ellos?
Inventariamos los enganches a WP_List_Table de tu instalación, identificamos qué procedimientos operativos dependen de ellos y planificamos la migración a DataViews sin parar a tu equipo.
4. La paleta de comandos global
La paleta de comandos existía desde hacía varias versiones, pero vivía encerrada en el editor de bloques. En WordPress 7.0 se abre a toda la administración: pulsas Cmd+K en macOS o Ctrl+K en Windows y Linux desde cualquier pantalla del panel y aparece un campo de búsqueda que entiende comandos, no solo texto.
Desde ahí se salta a pantallas de ajustes, se buscan entradas y páginas por nombre, se abren plantillas y se ejecutan acciones registradas. La diferencia con el buscador clásico es que no busca contenido: busca lo que puedes hacer. Escribir «medios» y llegar a la biblioteca en dos pulsaciones sustituye a desplegar el menú lateral, localizar el elemento y hacer clic.
Dónde ahorra tiempo real
Vale la pena bajar a casos concretos, porque en abstracto suena a atajo prescindible. En un equipo editorial que publica a diario, el patrón que más se repite es abrir una entrada concreta que se está revisando: en lugar de ir al listado, filtrar y hacer clic, se escriben tres letras del título y se entra directamente. Con cincuenta o cien entradas en borrador, esa diferencia es de veinte segundos por operación.
El segundo patrón es el salto a pantallas de configuración que se usan poco y cuya ubicación nunca se recuerda. Ajustes de enlaces permanentes, opciones de lectura, la pantalla de usuarios. Cualquiera que administre WordPress sabe que la mitad del tiempo perdido en el panel es buscar dónde estaba una opción.
El tercero, y el más relevante para una agencia, es el trabajo con muchos sitios. Cuando gestionas veinte instalaciones y cada una tiene un menú lateral distinto por los plugins que lleva, la memoria muscular no sirve: en cada sitio el elemento está en otro sitio. La paleta es igual en todas. Aprendes un flujo y lo aplicas en toda la cartera, lo que reduce de forma medible el coste de los cambios de contexto.
Y hay un cuarto uso que se subestima: la paleta es una herramienta de formación. Cuando un cliente pregunta cómo llegar a una pantalla, la respuesta deja de ser un recorrido de menús con capturas y pasa a ser una palabra. Eso simplifica la documentación de procedimientos internos más de lo que parece.
El matiz honesto
La paleta sirve a quien usa el teclado. Un perfil que trabaja con ratón y menús no la va a adoptar porque se lo digas en una formación. Nuestra experiencia es que la adopción es alta entre desarrolladores y editores intensivos, y baja entre perfiles ocasionales. No hay que forzarla. Enséñala, deja que la use quien la encuentre útil y no la conviertas en la única forma documentada de hacer las cosas.
5. Impacto en formación y adopción
El coste real del nuevo escritorio de WordPress 7 no está en el código. Está en las horas de soporte de la semana siguiente a la actualización. Un panel que cambia de aspecto de un día para otro genera desconfianza en usuarios no técnicos, y la desconfianza se traduce en tickets, en llamadas y en la sensación de que «la actualización ha roto algo» aunque no haya roto nada.
La forma de evitarlo es sencilla y casi nadie la aplica: avisar antes. Un correo breve, enviado dos o tres días antes de la actualización, ahorra la mitad de las incidencias. No hace falta un manual de cuarenta páginas.
Guion breve de comunicación del cambio
Este es el esqueleto que usamos con clientes, adaptable en cinco minutos. Primero, qué va a pasar y cuándo: «el martes por la mañana actualizamos el gestor de contenidos a WordPress 7». Segundo, qué vas a notar: «el panel se ve distinto, con otros colores y campos algo más grandes; el contenido y los permisos no cambian». Tercero, cómo volver atrás en lo cosmético: «si prefieres los colores anteriores, en tu perfil de usuario puedes seleccionar el esquema Fresco». Cuarto, qué ganas: «al moverte entre pantallas ya no hay recarga y puedes buscar cualquier sección pulsando Ctrl+K». Y quinto, a quién escribir si algo no cuadra, con un canal concreto y una persona concreta.
Ese mensaje ocupa un párrafo y cambia por completo la percepción del cambio. La diferencia entre «han tocado algo y ahora no encuentro nada» y «han actualizado, ya me avisaron y sé cómo funciona» es enteramente de comunicación.
Para equipos grandes añadimos una sesión de quince minutos en videollamada la semana de la actualización, grabada y compartida. No es formación formal: es enseñar tres cosas, la paleta de comandos, el cambio de esquema de color y dónde han quedado los filtros que usaban. Con eso se cubre el 90% de las dudas. Conviene aprovechar la sesión para hablar también de otras novedades que sí cambian el trabajo diario, como los controles de visibilidad por dispositivo o el nuevo sistema de revisiones con comparación visual, que resuelve la pregunta recurrente de qué cambió exactamente entre dos versiones de una página.
Lo que no hay que prometer
Un aviso importante para quien prepare esta comunicación. WordPress 7.0 no incluye colaboración en tiempo real. La funcionalidad se retiró el 8 de mayo de 2026 por motivos de superficie de ataque, condiciones de carrera, carga de servidor y eficiencia de memoria, y la RC3 ya salió sin ella. Está pospuesta a la 7.1. Circulan bastantes artículos de abril de 2026 que la anuncian como novedad porque se escribieron antes del lanzamiento, y más de un equipo de marketing ha llegado a la reunión esperando editar a la vez sobre el mismo documento. Aclararlo por adelantado evita una decepción que ensucia todo lo demás.
Tampoco conviene vender las novedades de IA como un botón mágico. Lo que llega en 7.0 es infraestructura: un panel centralizado de credenciales en Ajustes > Conectores, la Abilities API y un adaptador MCP, con proveedores de serie que requieren instalar un plugin específico y consumir tu propia clave API pagada por uso. Lo explicamos en detalle en el artículo sobre cómo configurar los conectores de IA de WordPress 7.
6. Qué revisar en plugins y temas que inyectan interfaz en el admin
Llegamos a la parte operativa. Si mantienes sitios de terceros o desarrollo propio, esta es la lista de comprobación que aplicamos antes de dar por buena una actualización a 7.0 en producción.
Empieza siempre por staging con una copia real de la base de datos. Un entorno limpio no reproduce los problemas, porque los problemas están en los datos y en la combinación concreta de plugins del cliente.
- Listados personalizados. Abre cada listado con columnas, filtros o acciones masivas propias y comprueba que siguen ahí y que funcionan. No basta con verlos: ejecuta la acción masiva sobre dos elementos de prueba.
- Pantallas de ajustes de plugins. Revisa alineación y espaciado con los campos de formulario más altos. Presta atención a los que mezclan controles nativos con controles propios.
- JavaScript del admin. Navega entre pantallas sin recargar y verifica que los scripts se reinicializan. Ten la consola abierta: los errores de inicialización duplicada se ven ahí antes que en la interfaz.
- Metaboxes en el editor. El editor usa iframes internos, lo que puede dar conflictos con maquetadores como Elementor, Divi o Bricks. Si el sitio depende de uno de ellos, esta prueba no es opcional.
- WooCommerce. Tenía actualizaciones de compatibilidad pendientes. No actualices una tienda sin probar antes en staging, con el flujo completo de pedido y con las pantallas de administración de pedidos y productos.
Sobre WooCommerce merece la pena insistir, porque es donde más personalización de listados existe. Las pantallas de pedidos y productos suelen acumular columnas propias, filtros de negocio y acciones masivas que alguien añadió hace años y que sostienen operaciones diarias. Si gestionas una tienda con integraciones, revisa también nuestro repaso de plugins de WooCommerce para un ecommerce profesional antes de decidir el orden de actualización.
Sobre PHP, para cerrar un malentendido frecuente
WordPress 7.0 requiere PHP 7.4 como mínimo y recomienda PHP 8.3. No exige PHP 8, y conviene repetirlo porque circula lo contrario. Dicho esto, nuestra postura de agencia es que por debajo de PHP 8 estás en territorio sin soporte de seguridad, y que la actualización mayor es el momento natural para dar ese salto. Hacer las dos cosas a la vez concentra el riesgo en una sola ventana de mantenimiento en lugar de repartirlo en dos. Si vas a tocar la configuración del servidor, aprovecha para revisar la configuración de PHP-FPM y php.ini para PHP 8, porque una actualización de rama sin ajustar pools ni límites de memoria suele dejar rendimiento sobre la mesa.
Espera a 7.0.1, o mejor dicho, no actualices a 7.0 a secas
WordPress 7.0.1 se publicó el 9 de julio de 2026 con 31 correcciones en el core y el editor de bloques. Entre ellas hay varias que afectan directamente a lo que se describe en este artículo: mejoras de accesibilidad en la interfaz de revisiones visuales, un fallo en el callback de copiar al portapapeles y un bug del bloque de navegación con Page List dentro de submenús. También corrige una regresión en wp_kses() que corrompía declaraciones background-image: url(...) dejándolas en style=")", y una incompatibilidad con PHP 8.5 en una función del core relacionada con adjuntos de imagen.
La lectura práctica es sencilla: si todavía no has actualizado, ve directo a la versión de mantenimiento. Y si actualizaste a 7.0 en mayo y notaste estilos raros en elementos con imagen de fondo, ya tienes explicación y solución.
Conclusión
El nuevo escritorio de WordPress 7 es un cambio de superficie con consecuencias de fondo. Lo que se ve, colores, campos más altos, transiciones sin recarga y una paleta de comandos disponible en todo el panel, mejora el trabajo diario de quien administra el sitio y apenas necesita una nota informativa para que el equipo lo asimile. Lo que no se ve, la sustitución progresiva de las tablas clásicas por DataViews, es lo que puede costarte una sesión de depuración incómoda si tienes personalizaciones acumuladas.
La recomendación es la misma que damos con cualquier versión mayor. Inventaria antes de actualizar, prueba en staging con datos reales, actualiza a la versión de mantenimiento y no a la inicial, y avisa a las personas que van a usar el panel antes de que se lo encuentren cambiado. Ninguno de esos cuatro pasos es caro. Saltárselos sí lo es, porque el coste aparece en forma de horas de soporte no presupuestadas y de confianza erosionada.
Sobre DataViews en concreto, nuestra posición es de calma activa: no reescribas nada por adelantado, pero ten el mapa hecho. Cuando la pantalla que te importa migre, la diferencia entre una tarde de trabajo y una semana de sorpresas será haber sabido de antemano qué dependía de qué. Y si el inventario revela que tienes tres columnas personalizadas que nadie mira desde 2021, habrás ganado también en mantenimiento futuro.
Preguntas frecuentes
¿Puedo volver al aspecto anterior del panel de administración?
En parte. El esquema de color «Fresco» sigue disponible y cada usuario puede activarlo desde su perfil, sin tocar código. Lo que no revierte esa opción son los cambios estructurales: los campos de formulario más altos, las transiciones de vista sin recarga y DataViews forman parte del core y no se desactivan cambiando de esquema.
¿Mis columnas personalizadas en el listado de entradas van a dejar de funcionar?
Depende de si la pantalla concreta ha migrado a DataViews. La migración en el core es progresiva y no todas las pantallas cambian a la vez. Mientras un listado siga usando la tabla clásica, los filtros de siempre funcionan igual. Cuando esa pantalla migre, las columnas añadidas con los hooks tradicionales dejarán de mostrarse sin generar ningún error. Por eso conviene hacer el inventario ahora, aunque la reescritura pueda esperar.
¿Sigue existiendo WP_List_Table?
Sí, la clase continúa en el core y las pantallas propias construidas sobre ella siguen renderizando. El riesgo no es que desaparezca de un día para otro, sino que tu interfaz personalizada se aleje visualmente del resto del panel a medida que las pantallas nativas adopten DataViews. Es deuda técnica de crecimiento lento, no una rotura inminente.
¿La paleta de comandos funciona en toda la administración o solo en el editor?
En WordPress 7.0 está disponible en toda la administración, no solo dentro del editor de bloques como ocurría antes. Se abre con Cmd+K en macOS y Ctrl+K en Windows y Linux desde cualquier pantalla del panel.
¿WordPress 7 incluye edición colaborativa en tiempo real?
No. Se retiró el 8 de mayo de 2026, antes del lanzamiento, por motivos de superficie de ataque, condiciones de carrera, carga de servidor y eficiencia de memoria. Está pospuesta a la versión 7.1. Los artículos que la presentan como novedad de 7.0 son anteriores al lanzamiento y están desactualizados.
¿Necesito PHP 8 para actualizar?
No es obligatorio: el mínimo requerido es PHP 7.4 y la recomendación oficial es PHP 8.3. Ahora bien, mantener una versión anterior a PHP 8 te deja sin soporte de seguridad, así que la actualización mayor es un buen momento para planificar el salto en la misma ventana de mantenimiento.
¿Qué debería probar antes de actualizar un sitio con muchos plugins?
Los listados de administración con personalizaciones, las pantallas de ajustes de los plugins que inyectan interfaz propia, el comportamiento del JavaScript del admin al navegar entre pantallas sin recarga y los metaboxes dentro del editor, que ahora usa iframes internos y puede dar conflictos con maquetadores. Si el sitio es una tienda, prueba WooCommerce en staging con el flujo de pedido completo antes de tocar producción.
