WordPress 6.8 + WooCommerce 9: las 7 cosas que rompen tus plugins antiguos (y cómo arreglarlas)

WordPress 6.8 (publicado en marzo de 2026) y WooCommerce 9 (publicado en febrero de 2026) introdujeron varios cambios que rompen sigilosamente plugins antiguos. Si tu web tiene plugins anteriores a 2025, esta es la lista de siete cosas que conviene revisar este mes antes de que algo se rompa en el peor momento.

1. PHP 8.0 mínimo, 8.2 recomendado

WordPress 6.8 ha subido la versión mínima de PHP a 8.0. La mayoría de plugins anteriores a 2024 todavía parsean con sintaxis 7.4, pero usan patrones obsoletos (como pasar null a parámetros no nullables) que producen fatales en PHP 8.0. Solución rápida: un escaneo con phpcs --standard=PHPCompatibility contra PHP 8.0 los encuentra en minutos.

2. Tipado más estricto en hooks de WooCommerce 9

Varios filtros de WooCommerce que antes devolvían mixed ahora tienen tipos estrictos. Plugins que devolvían arrays donde ahora se esperan strings (o viceversa) lanzan fatales. Los más habituales son los filtros alrededor de woocommerce_product_get_price y woocommerce_get_price_html.

3. jQuery quitado del front por defecto

WordPress 6.8 deja de cargar jQuery en el front por defecto por rendimiento. Plugins que asumían que jQuery siempre estaría disponible ahora deben llamar a wp_enqueue_script('jquery') de forma explícita. Cerca del 30% de plugins de tienda antiguos asumían jQuery global; se rompen en cuanto un cliente interactúa con cualquier elemento dinámico.

4. El Editor del Sitio es ya la experiencia por defecto

Los temas clásicos siguen funcionando, pero las webs nuevas usan temas de bloques por defecto. Los plugins que registraban widgets con la API antigua (no bloques) solo aparecen en "Widgets clásicos", al que casi nadie entra. Solución: registrar un equivalente basado en bloques. El widget clásico sigue funcionando para usuarios legacy.

5. El admin de WooCommerce ya solo en React

Las páginas admin clásicas (en PHP) de pedidos, productos y clientes pasan a opt-in. Las tiendas nuevas reciben "WC-Admin" en React por defecto. Los plugins que se enganchaban con add_meta_box a las pantallas PHP también deben registrar un slot vía la API de extensibilidad de WC-Admin para aparecer en la nueva UI.

6. La REST API ahora exige permission_callback

WordPress 6.8 hace obligatorio el argumento permission_callback en register_rest_route(). Los plugins antiguos que lo omitían (patrón muy común) ahora fallan al registrar sus rutas en silencio. Síntoma: los endpoints REST devuelven 404 aunque el código parece correcto. Solución: añadir explícitamente 'permission_callback' => '__return_true' para endpoints públicos, o un check real para los privados.

7. Auth por cookie obsoleta para peticiones cross-origin

Plugins que usaban auth por cookie para AJAX desde un frontend separado (setups headless, apps móviles) deben migrar a application passwords o autenticación REST. La auth por cookie sigue funcionando para AJAX admin same-origin.

Cómo saber si tus plugins están afectados

El escaneo más rápido: activa WP_DEBUG_LOG en una copia de staging, navega por el front y el admin durante diez minutos, y revisa wp-content/debug.log. Casi todas las roturas anteriores producen una línea clara de "Deprecated" o "Fatal error".

Para plugins a medida antiguos (hechos por una agencia o freelance hace años y nunca actualizados), tienes tres opciones:

• Pagar al desarrollador original para actualizar — típicamente 100-400 € por plugin.
• Que un freelance audite y parchee — 200-600 € según tamaño.
• Regenerar el plugin desde cero a partir de su descripción funcional — 3-15 €, sin necesidad de implicar a un dev. La nueva versión es por definición compatible con WordPress 6.8 y WooCommerce 9 porque está construida contra la API actual.

El coste oculto del legacy

La tercera opción es la que casi nadie considera, pero suele ser la más barata. Un plugin construido en 2022 ha acumulado cuatro años de parches de compatibilidad en su código, no todos limpios. Regenerar desde una descripción fresca produce código más limpio que es compatible por construcción. La pega es que necesitas una descripción clara de qué hace el plugin: para los plugins que tu equipo usa a diario es fácil; para los que nadie recuerda para qué sirven, tómalo como señal de que quizá no los necesites.

Plan de acción para esta semana

Si no has hecho una auditoría de plugins desde 2024, agenda dos horas el viernes. Activa debug logging en staging, navega por tu tienda, lista cada plugin que da errores y decide una de tres: actualizarlo, sustituirlo por una regeneración o eliminarlo. La mayoría de tiendas descubren que el 30-40% de los plugins instalados caen en "eliminarlo" cuando se les obliga a justificar cada uno.