La versión de PHP condiciona qué funciones puede ejecutar WordPress, el tema y los plugins. Mantener un runtime antiguo puede dejar al sitio fuera de soporte; cambiarlo sin comprobar compatibilidad puede producir avisos, errores fatales o cambios de comportamiento.
La elección debe hacerse con información del proyecto, no con una cifra universal de rendimiento o memoria.
Compatibilidad antes que el cambio
Consulta las versiones de PHP admitidas por el núcleo, el tema y las extensiones críticas. Revisa el registro de cambios y busca funciones obsoletas. Un plugin abandonado puede ser el componente que impida avanzar, aunque la página principal parezca sencilla.
El servidor puede ofrecer varias versiones, pero cambiarla no corrige una incompatibilidad del código. Necesitas identificar qué componente la provoca y decidir si se actualiza, se sustituye o se retira.
Prueba representativa
Replica el sitio en staging y cambia allí el runtime. Prueba login, formularios, búsqueda, medios, tareas cron y las integraciones que no aparecen en la portada. En WooCommerce recorre carrito, pago, reembolsos y correos.
Un caso habitual es un plugin que usa una función eliminada o cambia tipos de datos entre versiones. La prueba debe capturar los errores de PHP y revisar el comportamiento, no limitarse a confirmar que el HTML inicial carga.
Rendimiento y consumo con contexto
Una versión más reciente puede aportar mejoras del runtime, pero el resultado depende del código y de la carga. Mide tiempos, errores, memoria y procesos PHP antes y después. Si el problema está en consultas o en un plugin que ejecuta tareas pesadas, cambiar PHP no bastará.
El número de trabajadores y la memoria disponible también dependen del plan y de la configuración del servidor. No hay una asignación válida para todos los sitios.
Planificar la ventana de mantenimiento
Haz una copia verificable, registra la versión anterior y define cómo volver atrás. El rollback puede consistir en cambiar el runtime si sigue disponible, pero si el cambio alteró datos o archivos, también necesitarás restaurar componentes compatibles.
Comunica la ventana cuando haya procesos de compra o publicación. Tras el cambio, revisa registros, tareas programadas, extensiones y páginas críticas durante un periodo de observación.
Qué comprobar después
Confirma la versión efectiva desde el panel o una herramienta de diagnóstico segura, y elimina páginas de información que expongan detalles innecesarios. Revisa cabeceras, HTTPS, formularios y conexiones con la base de datos.
Cuando el proyecto ya no depende de componentes sin mantenimiento, documenta la versión y la fecha de revisión. Así la próxima actualización parte de un inventario real y no de una suposición.
Errores después del cambio
Los avisos pueden aparecer en una página poco visitada, en una tarea cron o cuando un usuario sube un archivo. Revisa el registro de PHP y del servidor con el nivel de detalle adecuado, sin mostrar errores internos al público. Identifica el plugin o tema responsable antes de desactivar componentes al azar.
Si el sitio utiliza código propio, busca funciones obsoletas y prueba sus rutas principales. La compatibilidad declarada por el proveedor es una señal, no una prueba de que la instalación concreta esté libre de problemas.
Actualizar sin bloquear el mantenimiento
Elige una ventana que permita observar el sitio y comunicar una reversión. Mantener indefinidamente una versión antigua por miedo a cambiar también tiene coste: se acumulan diferencias y la siguiente migración resulta más difícil. La solución es reducir el tamaño del salto mediante pruebas periódicas.
Registra el resultado y programa una nueva revisión. Así PHP forma parte del mantenimiento normal de WordPress y no se convierte en una emergencia cuando el proveedor retira una versión.
Cuando aún no puedes actualizar
Si un plugin crítico impide el cambio, limita la exposición mientras preparas una sustitución: reduce permisos, desactiva funciones no necesarias y aumenta la observación de errores. No presentes esa medida temporal como una solución definitiva.
La alternativa más sostenible es actualizar el componente, reemplazarlo o adaptar el código. Un inventario de compatibilidad evita que el mismo bloqueo vuelva a aparecer en la siguiente versión.
Registrar la compatibilidad
Guarda la versión probada, los plugins revisados, las rutas recorridas y los errores encontrados. Ese registro sirve para repetir el cambio en otra instalación y para detectar qué dependencia sigue bloqueando la actualización.
La compatibilidad es una propiedad del conjunto concreto de núcleo, tema, plugins, código propio y configuración. Por eso las recomendaciones generales deben terminar siempre con una prueba del proyecto real.
Si el proveedor anuncia la retirada de una versión, adelanta la prueba en vez de esperar al último momento. Disponer de una versión compatible y de una copia probada convierte el cambio en una tarea planificada.
La prueba debe cubrir también tareas que se ejecutan sin una visita, como copias, importaciones y envíos de correo. Es frecuente que el primer error aparezca fuera de la página principal.
Incluye esas comprobaciones en el registro de compatibilidad.
Si el cambio requiere actualizar un plugin o tema, repite la prueba con la combinación completa y no solo con PHP aislado. La compatibilidad final pertenece al conjunto instalado, a sus datos y a la configuración concreta del servidor.
La fecha de la siguiente revisión debe quedar registrada junto con el inventario.