WooCommerce podría exigir PHP 8.1: qué se propone realmente
El 8 de septiembre de 2026, el equipo de ingeniería de WooCommerce publicó en su blog para desarrolladores una propuesta: subir la versión mínima de PHP a 8.1, a partir de WooCommerce 11.5, entonces prevista para enero de 2027. Un comentario del 29 de septiembre menciona un aplazamiento a WooCommerce 11.6. Se trata de una propuesta abierta a debate, no de una decisión publicada: la versión objetivo, el calendario e incluso el principio podrían cambiar. No se ha anunciado ninguna fecha firme de cambio, y este artículo no se inventa ninguna.
¿Por qué preocuparse si nada está decidido? Porque la documentación de WooCommerce indica hoy que funciona con PHP 7.4 y superiores, y recomienda PHP 8.3 o más. La distancia entre ese mínimo y esa recomendación es grande, y muchas tiendas de clientes viven en ella. La propuesta tiene al menos un mérito: obliga a plantear una pregunta que una agencia debería hacerse de todos modos, a saber, qué versión de PHP corre en cada tienda y quién decide cambiarla.
Qué le pasaría a una tienda que se quedara en PHP 7.4 u 8.0
Según la entrada, WordPress dejaría, por defecto, de ofrecer la actualización de WooCommerce a las tiendas que no cumplan el nuevo requisito. Esas tiendas seguirían en su versión actual y continuarían recibiendo las versiones correctivas de su rama. La entrada precisa también que PHP no se cambiaría en lugar del propietario y que las instalaciones existentes no se desactivarían.
El riesgo para una agencia no es, por tanto, la caída brusca sino el silencio: una tienda que deja de recibir nuevas versiones sin aviso, hasta el día en que el cliente pide una función o una extensión exige por sí misma una versión reciente. Nada se pone en rojo y nadie recibe una alerta. De ahí el interés de hacer el inventario antes, en lugar de descubrirlo bajo la presión de una petición del cliente.
Por qué prepararse ya, aunque el cambio se aplace o se abandone
- PHP 7.4 ya no tiene soporte — la documentación de WooCommerce recuerda que PHP 7.4 llegó al final de su vida en noviembre de 2022, y PHP 8.0 también salió del soporte de seguridad. Seguir en ellas es un riesgo independiente de WooCommerce.
- La recomendación oficial supera el mínimo — WooCommerce recomienda PHP 8.3 o superior. Apuntar solo a 8.1 equivale a preparar una migración más a corto plazo.
- Una muestra no es su cartera — la entrada sitúa en torno al 7 % las tiendas observadas con PHP 7.4 y en torno al 2 % las de PHP 8.0, pero ese seguimiento es voluntario (opt-in): un orden de magnitud, no un censo. Los sitios heredados de otro proveedor suelen ir más atrasados que la media.
- Las extensiones suelen decidir antes que WooCommerce — la propia entrada lo dice: subir el mínimo no garantiza que cada extensión, tema o fragmento de código funcione. La prueba en una copia sigue siendo imprescindible.
- Un calendario elegido vale más que uno impuesto — escalonar las migraciones tienda a tienda, fuera de los periodos de mucha venta, cuesta menos que una serie de urgencias.
- El cliente ve a la agencia, no a la plataforma — si una tienda se queda anclada en su rama, acudirá a usted. Mejor haberlo anunciado.
Primer paso: conocer la versión de PHP de cada tienda
El método general para inventariar un parque se describe en el artículo sobre el inventario de versiones de PHP; no lo repetimos aquí. Para una tienda WooCommerce bastan al principio tres datos: la versión de PHP, la versión de WooCommerce y el estado de las extensiones.
La fuente más fiable es la página WooCommerce > Estado, sección «Entorno del servidor», fila «Versión de PHP»: es la que la documentación de WooCommerce indica para comprobar el mínimo. Por SSH, wp --info muestra la versión de PHP que usa WP-CLI, y wp eval 'echo PHP_VERSION;' la que WordPress ejecuta realmente. Ojo: en línea de comandos el binario de PHP puede diferir del del servidor web, así que, si no coinciden, manda la página Estado. En cPanel la versión se elige por dominio, como explica la guía para cambiar la versión de PHP de un sitio.
Anote el resultado en una tabla: tienda, versión de PHP, versión de WooCommerce, extensiones que bloquean, estado, fecha prevista del cambio. Trate primero las tiendas con PHP 7.4 y 8.0, y después las demás.
Migrar una tienda a una versión de PHP más reciente sin romper el pago
Hacer copia y anotar el punto de partida
Copie los archivos y la base de datos y compruebe que la copia se restaura. Anote la versión actual de PHP del dominio: es su vuelta atrás.
Listar las extensiones y el tema
wp plugin list --fields=name,status,version,updateda el inventario. Para cada extensión y para el tema, anote la compatibilidad con PHP declarada por el editor (campo «Requires PHP» o notas de versión). Actualice primero lo que se pueda con la versión actual de PHP.Crear una copia de pruebas
Misma versión de WooCommerce, mismas extensiones, base de datos copiada. Ponga la pasarela de pago en modo de prueba o sandbox y corte los envíos de correo a clientes reales.
Cambiar la versión de PHP en la copia
Apunte a la versión que recomienda WooCommerce si todas las extensiones la admiten; si no, a la más alta que acepten. Solo en la copia, active
define( 'WP_DEBUG_LOG', true );para leer los errores sin mostrarlos a los visitantes.Repetir el proceso de compra
Recorra los puntos de control de la tabla siguiente, del carrito a la confirmación, incluido un reembolso. Corrija o sustituya toda extensión que falle antes de seguir.
Cambiar la producción
Elija una franja tranquila, avise al cliente, cambie la versión de PHP del dominio, vacíe las cachés (página, objeto, opcode) y vuelva a leer WooCommerce > Estado para confirmar la versión efectiva.
Vigilar y conservar la vuelta atrás
En los días siguientes, vigile el registro de errores, los pedidos recibidos, los correos y las acciones programadas. Conserve a mano la versión anterior hasta que la tienda haya pasado un ciclo completo de pedidos.
Puntos de control propios de una tienda
Desplace la tabla
| Punto de control | Qué puede romperse | Cómo comprobarlo |
|---|---|---|
| Pasarelas de pago | Módulo incompatible con la nueva versión: pago rechazado o página en blanco al validar | Pedido de prueba en el sandbox de la pasarela, del carrito a la confirmación |
| Webhooks | Notificaciones de pago no recibidas o rechazadas, pedidos que se quedan pendientes | Registro de entregas en la pasarela y después el estado del pedido de prueba |
| Tareas programadas | Acciones recurrentes que fallan: recordatorios, sincronizaciones, suscripciones | WooCommerce > Estado > Acciones programadas, lista de fallos; `wp cron event list` |
| Correos de pedido | Confirmación al cliente o aviso a la tienda ausente o mal formado | Pedido de prueba y recepción de los dos mensajes |
| Extensiones que tocan los pedidos | Función personalizada que lee o modifica pedidos y se bloquea | Crear, modificar y reembolsar un pedido de prueba; releer la compatibilidad declarada de cada extensión |
| Proceso completo | Error fatal en un paso poco probado (código promocional, envío, cuenta de cliente) | Recorrido completo con código promocional, dos modos de envío y una cuenta nueva |
Quién se encarga de qué: agencia, cliente, alojamiento
La agencia conserva la relación con el cliente y el calendario: anuncia la ventana de mantenimiento, decide qué extensiones sustituir y valida la reanudación. El alojamiento aporta la infraestructura: versiones de PHP disponibles, elección de la versión sitio a sitio, cuentas cPanel aisladas para que un cambio en una tienda no afecte a las demás. En ServOrbit, la versión de PHP se elige por dominio; la migración asistida y la administración pueden añadirse como opciones, no van incluidas por defecto.
Una regla sencilla evita malentendidos: dejar por escrito, antes de tocar nada, quién responde de qué. Extensiones de pago del cliente, tema a medida, alojamiento, pasarela de pago: cada elemento tiene un responsable, y la migración de PHP no borra esas fronteras.
Orden de paso recomendado
Ensaye el procedimiento en una tienda poco crítica de la cartera, después trate las que están en PHP 7.4 y 8.0 y por último las más activas, nunca en un periodo de mucha venta. Cronometre cada migración: ese tiempo es la base de un presupuesto honesto para las siguientes.
Solución de problemas: lo que más se rompe tras el cambio
Tras un cambio, los mismos síntomas se repiten de una tienda a otra. Estos son los cinco más frecuentes, con el primer gesto para cada uno.
Los cinco síntomas que conviene conocer
- «Ha habido un error crítico en este sitio web» — mensaje de WordPress cuando una extensión o el tema provoca un error fatal con la nueva versión. Remedio: volver a la versión de PHP anterior en cPanel y leer el registro de errores de la copia para identificar la extensión; actualizarla o sustituirla.
- Pedidos bloqueados «pendientes de pago» — la notificación de la pasarela ya no llega o se rechaza. Remedio: vuelta atrás y revisión del registro de webhooks de la pasarela y de la compatibilidad de PHP declarada del módulo.
- Pantalla en blanco al pagar — a menudo una extensión de pago o de envío. Remedio: vuelta atrás y desactivación de las extensiones una a una en la copia hasta dar con la culpable.
- Faltan los correos de pedido — la prueba de envío no se repitió tras el cambio. Remedio: pedido de prueba, lectura del registro de correo y revisión de la extensión de envío.
- Acciones programadas que fallan — tareas recurrentes que se bloqueaban en silencio con la versión antigua salen a la luz, o al revés. Remedio: abrir la lista de acciones fallidas, leer el mensaje y actualizar la extensión implicada.
¿Y si el cambio se aplaza o se abandona?
El plan sigue siendo útil. PHP 7.4 y 8.0 ya no tienen soporte de seguridad, la recomendación oficial es superior a 8.1 y el inventario que acaba de hacer sirve también para el siguiente vencimiento, por ejemplo la checklist de migración al fin de vida de una rama de PHP o el calendario de fin de vida del alojamiento.
Vigile el blog para desarrolladores de WooCommerce y su documentación: ahí se publicará la decisión, si se toma, con su versión y su fecha. Mientras tanto, más vale tener una lista al día y un procedimiento ensayado que descubrir el asunto el día en que una tienda deja de actualizarse.
