El 10 de junio WordPress empezó a desplegar la 6.6 de forma automática en miles de instalaciones. Dos días después, en varios grupos de agencias ya no se hablaba de novedades del editor de bloques: se hablaba de pasarelas caídas, temas rotos y tiendas que no podían cobrar. Según recogen medios especializados como Ecommerce Times, más de 180.000 tiendas WooCommerce han sufrido fallos críticos desde entonces. Yo no me sorprendo del número. Me sorprende que sigamos vendiendo WooCommerce como la opción «flexible y tuya» sin advertir del coste real cuando el ecosistema se desincroniza.
Porque esto no es un bug aislado de un plugin cutre. WordPress 6.6 trae cambios profundos en la arquitectura del editor de bloques y exige compatibilidad con PHP 8.3. WooCommerce, en teoría, lleva meses preparándose. En la práctica, el catálogo de extensiones de pago, envíos, suscripciones y fidelización sigue siendo un mosaico de versiones, forks abandonados y código legacy que nadie mantiene hasta que explota un martes por la tarde.
Los datos que circulan son brutales: caídas medias de facturación del 47% en las 72 horas posteriores a la actualización en tiendas afectadas. Stripe for WooCommerce en versiones anteriores a la 7.4.0, PayPal Standard sin actualizar desde 2024, temas premium como Astra u OceanWP esperando parches… El patrón es siempre el mismo. El merchant cree que «actualizar es bueno para la seguridad» —y tiene razón—, pero nadie le ha contado que esa actualización puede tumbar el checkout sin aviso previo.
En mi experiencia, el problema no es solo técnico. Es de modelo. WooCommerce no es un producto cerrado con QA unificado: es WordPress más un plugin más otros cuarenta plugins que tú has ido acumulando porque cada campaña de marketing pedía una funcionalidad distinta. Cuando WordPress mueve una pieza estructural, la cadena entera tiembla. Y quien paga la factura no es Automattic ni el desarrollador del plugin que lleva dos años sin commits: eres tú, con el carrito abandonado y el soporte de tu pasarela preguntándote por qué han caído las transacciones.
Lo irónico es que, mientras esto pasa, Shopify reporta picos de consultas de migración desde WooCommerce. Ecommerce Times habla de aumentos del 420% en solicitudes a agencias especializadas en mudanzas hacia Shopify desde el 11 de junio. Razorpay y Mollie también han visto subidas enormes de peticiones de integración alternativa. No digo que Shopify sea la panacea —ya he escrito aquí que sus Scripts mueren el 30 de junio y que la migración a Functions no es para todos—, pero sí que estos episodios alimentan la narrativa del SaaS estable frente al WordPress «barato pero frágil».
Y aquí viene lo que casi nadie dice en voz alta: el rollback no arregla la confianza. Sí, el 34% de los afectados ha vuelto a WordPress 6.5.4 como parche de emergencia. Vuelves a cobrar, respiras, publicas un post en LinkedIn diciendo que «ya está solucionado». Pero ¿qué haces la semana que viene, cuando otra actualización automática vuelva a la carga? ¿Congelas WordPress para siempre y renuncias a parches de seguridad? ¿Contratas retainer con una agencia para probar cada minor release en un staging que nunca montaste porque «no había presupuesto»?
La documentación oficial de WooCommerce deja claro qué versiones mínimas exige cada release —puedes consultarlo en su guía de requisitos PHP y WordPress—, pero eso no sustituye un plan operativo. Saber que WooCommerce 9.0 pide WordPress 6.4 no te salva si tu stack real incluye un plugin de facturación español sin mantenimiento, un multi-almacén custom y un checkout modificado con hooks que el nuevo motor de bloques ya no respeta igual.
Automattic promete sistemas de alerta temprana y WordPress.org habla de ampliar pruebas de compatibilidad con plugins de comercio. Me parece bien. Pero llevo años viendo promesas parecidas después de cada catástrofe de actualización, y el patrón se repite: comunicado tranquilizador, parches en cadena, merchants resolviendo en urgencias. El ecosistema open source escala en funcionalidades, no en predictibilidad operativa. Y en e-commerce la predictibilidad es dinero.
Si gestionas tiendas para clientes, este episodio debería cambiar cómo presupuestas. No basta con «hosting + tema + WooCommerce». Necesitas entorno de pruebas, inventario de plugins críticos con responsable y fecha de última revisión, política clara de cuándo NO actualizar automáticamente, y conversación honesta con el cliente sobre el riesgo de quedarse en versiones antiguas. Si no puedes cobrar eso, estás regalando seguros que no puedes pagar cuando llega la tormenta.
Y si eres merchant, la pregunta incómoda es si tu negocio puede permitirse depender de una pila donde una actualización del CMS —hecha con las mejores intenciones de seguridad— puede apagarte la caja en temporada alta. No es retórica barata. Es la pregunta que deberías hacerte antes del próximo clic en «Actualizar todo».
¿Tienes hoy un plan documentado para saber qué plugin tumba el checkout si actualizas WordPress mañana, o sigues confiando en que «esta vez no pasará nada»?