WordPress 7.0 para developers: lo que puede romper tu código

WordPress 7.0 «Armstrong» salió el 20 de mayo de 2026. La prensa generalista habla del rediseño del admin y de la IA nativa en core. Con razón: son las cabeceras. Pero si mantienes plugins, temas o proyectos custom, hay una capa entera de cambios menos visibles que merecen tu atención antes que los titulares.

Esta es la primera entrega de una miniserie de cinco posts dedicada a esa otra capa. Empezamos por lo más urgente: los cambios que pueden romper código que tienes en producción ahora mismo.

PHP 7.4 como mínimo

La base de PHP soportado sube a 7.4. Si tu plugin todavía declara compatibilidad con versiones anteriores, toca actualizar el header Requires PHP del plugin, el composer.json si tienes, y la pipeline de tests CI. La mayoría del ecosistema ya estaba ahí, pero conviene revisar antes de que un cliente con hosting antiguo te abra un ticket.

Aprovecha para revisar también si usabas alguna función polyfilleada. Muchas que tenías que parchear (str_contains, str_starts_with, str_ends_with) ahora son nativas y puedes tirar el wrapper.

Soporte legacy html5 para scripts, eliminado

El subargumento script de add_theme_support( 'html5' ) se elimina del todo:

add_theme_support( 'html5', array( 'script' ) );

Si tu tema lo declara, no rompe nada visible, pero la línea ya no hace lo que hacía. Limpia el functions.php. Los demás subargumentos (search-form, comment-form, comment-list, gallery, caption, style) siguen funcionando.

Block API v3 obligatoria para el editor iframed

A partir de 7.0, los bloques con apiVersion: 3 corren en el editor iframed por defecto. Los que declaran v1 o v2 caen automáticamente al modo no-iframed, lo que implica:

• Diferencias en herencia de estilos del body del documento principal.
• Problemas de aislamiento CSS cuando otros bloques v3 conviven con los tuyos.
• Inconsistencia visual entre editor y frontend en bloques con CSS complejo.

Si llevas tiempo posponiendo la migración a v3, este es el momento. El editor no-iframed es a efectos prácticos un modo legacy y va a tener cada vez menos cariño en próximas versiones.

CSS personalizado por bloque ya no se preserva sin edit_css

Hasta 7.0, un usuario sin capacidad edit_css que tocaba un bloque con CSS personalizado podía preservar ese CSS sin querer al guardar. En 7.0 se descarta automáticamente, alineando el comportamiento con lo que ya ocurría con el CSS personalizado general del Customizer.

Si tu plugin gestiona roles de colaborador en flujos multiusuario — agencias, sitios editoriales con autores externos, intranets — comprueba que ninguna pieza depende de este comportamiento residual para mantener estilos puntuales. Si lo hace, mueve el CSS a una fuente con permisos explícitos.

Extensión .heic corregida a .jpg en uploads

Cuando el navegador convierte una imagen HEIC a JPEG antes de subirla — el caso típico al subir desde Safari en iPhone — el archivo final ahora lleva la extensión .jpg correcta. Antes el archivo se subía con extensión .heic aunque su contenido fuera JPEG, lo que provocaba que algunos workflows lo trataran erróneamente como HEIC.

Si tu código inspecciona extensiones para clasificar medios, filtrar uploads, generar miniaturas o ejecutar lógica específica de formato, regulariza el handling. El comportamiento previo era objetivamente erróneo y ahora se ha enderezado, pero el código que confiaba en él va a comportarse distinto.

Resumen accionable

Antes de actualizar un sitio a 7.0:

1. Revisa los headers Requires PHP de tus plugins. Sube a 7.4 si no estabas ahí.
2. Busca 'html5' en tus temas y elimina la línea de 'script' si la tienes.
3. Auditea tus bloques: cualquiera con apiVersion menor que 3 debería tener migración planificada.
4. Si gestionas sitios con roles de colaborador y CSS por bloque, prueba el flujo en staging antes de actualizar producción.
5. Revisa el código que inspecciona extensiones de medios subidos.

En el próximo post de la serie entramos en las APIs y patrones nuevos que justifican un upgrade que vaya más allá de mantener el código andando: autoRegister para bloques solo PHP, Pattern Overrides para bloques custom, Interactivity API con watch(), y @wordpress/boot para construir páginas dentro del site editor.