Plugin de WordPress requiere PHP más nuevo: qué hacer si el alojamiento está desactualizado

Haces clic en “Actualizar” en un plugin y tu sitio te recompensa con una pantalla en blanco, un error fatal o el clásico “Este plugin requiere PHP 8.1, tú tienes 7.4.” El autor del plugin no está siendo dramático; está practicando higiene básica. Tu hosting, en cambio, vive en el pasado como si tuviera un teléfono plegable y opiniones firmes sobre los CDs.

Este es uno de esos problemas que parecen “cosas de WordPress” pero en realidad son ingeniería de sistemas: compatibilidad de runtime, cadencia de parches, radio de impacto, rollback y qué hacer cuando no controlas el entorno. Trátalo como producción, no como un sitio hobby.

Guía rápida de diagnóstico

Si tienes prisa y el sitio está caído (o estás a un clic de que lo esté), no “fisguees”. Haz esto en orden. Esto encuentra el cuello de botella rápido y evita tiempo de inactividad auto-infligido.

1) Confirma qué PHP está corriendo realmente (no lo que dice el panel de control)

• Revisa en el administrador de WordPress: Administración → Estado del sitio → Información → Servidor.
• O ejecuta una comprobación por CLI en el host. Ver la sección de comandos abajo.

Decisión: Si PHP está por debajo del mínimo del plugin, para y planifica una ruta de actualización. No instales el plugin forzosamente “de todos modos”. Así aprendes sobre errores fatales.

2) Identifica de dónde viene PHP (mod_php de Apache vs PHP-FPM vs handler)

• Hosting compartido: a menudo un “selector de PHP” por sitio, pero a veces es un valor por defecto global.
• VPS: podrías tener múltiples pools de PHP-FPM, cada uno en versiones distintas.

Decisión: Si puedes ejecutar varias versiones en paralelo, puedes actualizar WordPress primero sin romper otras apps en la máquina.

3) Determina el radio de impacto: ¿es un solo sitio o una flota?

• ¿Cuántos vhosts apuntan al mismo runtime de PHP?
• ¿Hay otros sitios legacy y anclados a PHP 7.4?

Decisión: Las actualizaciones a nivel de flota necesitan staging y despliegue por fases. Las actualizaciones de un solo sitio pueden ser más rápidas, pero aún necesitan rollback.

4) Captura el error real (logs, no impresiones)

• Registro de depuración de WordPress para errores PHP.
• Logs del servidor web y de PHP-FPM para problemas de arranque/configuración.

Decisión: Si el error es “requiere PHP X”, la actualización es obligatoria. Si el error es “función indefinida” o “propiedad tipada”, suele significar incompatibilidad de versión.

5) Elige la solución de menor riesgo que cumpla el requisito

• Mejor: actualizar PHP (versión soportada) con staging y rollback.
• Segunda mejor: aislar el sitio en un contenedor o VM separado.
• Último recurso: fijar una versión antigua del plugin (temporal) y programar migración.

Qué significa realmente el error (y qué no significa)

Cuando un plugin dice que requiere PHP 8.1+ (o 8.0+, etc.), raramente es “porque el autor te odia”. Usualmente es una de estas razones:

• Características del lenguaje: el plugin usa sintaxis no disponible en PHP más viejo (tipos unión, atributos, expresiones match, enums, propiedades readonly).
• Funciones y extensiones del core: depende de funciones más nuevas o de versiones modernas de extensiones como cURL, OpenSSL, JSON, mbstring o intl.
• Postura de seguridad: no quieren soportar versiones de PHP fuera de vida útil con vulnerabilidades conocidas.
• Realidad de la matriz de pruebas: mantener compatibilidad hasta PHP 7.4 (o más antiguo) multiplica el coste de pruebas. Cortan la cola.

Lo que no significa: que actualizar PHP rompa automáticamente WordPress. WordPress en sí es conservador, pero el ecosistema no lo es. Las rupturas de compatibilidad suelen venir de:

• Temas/plugins antiguos que dependían de comportamientos obsoletos.
• Suposiciones codificadas sobre conversiones de cadenas/arrays.
• Bibliotecas antiguas incluidas dentro de plugins (carpetas vendor) que colisionan con las expectativas de PHP moderno.

Y sí, a veces puedes “hacer que funcione” en un PHP antiguo editando un plugin. Eso también es la forma de convertirte en el nuevo mantenedor de un plugin que no querías mantener. Felicidades, has adoptado una pequeña mascota digital que muerde.

Hechos interesantes y un poco de historia (para entender el desorden)

Entender por qué estás atrapado en un PHP antiguo te ayuda a decidir si pelear con tu host o irte.

1. PHP 7.0 (2015) fue un gran salto de rendimiento comparado con PHP 5.x, por eso muchos hosts “finalmente actualizaron” y luego se relajaron de nuevo.
2. WordPress históricamente soportó PHP muy antiguo para mantener la larga cola de la web funcionando. Eso es noble, pero traslada la presión a los autores de plugins.
3. PHP 8.0 (2020) introdujo JIT (compilación just-in-time). JIT rara vez transforma cargas típicas de WordPress, pero señala que PHP no está “estancado”.
4. Propiedades tipadas y comportamiento más estricto en PHP 7.4/8.x dejaron al descubierto código descuidado. Muchos plugins que “funcionaron por años” murieron al contacto con PHP moderno.
5. Algunos hosts compartidos fijan versiones de PHP porque un módulo antiguo del panel de control, la integración de facturación o un handler personalizado de Apache depende de ello. Es una decisión de negocio, no una ley técnica.
6. Las actualizaciones automáticas de WordPress cambiaron expectativas: core y plugins pueden moverse rápido ahora, así que el retraso en el runtime duele más que hace una década.
7. Composer (gestor de dependencias de PHP) se volvió mainstream, y muchos plugins ahora dependen de librerías modernas que explícitamente dejan de soportar versiones viejas de PHP.
8. CloudLinux + CageFS se volvieron comunes en hosting compartido para aislar usuarios, y a menudo traen un “selector de PHP” que puede ejecutar múltiples versiones. Si tu host no tiene esto, es una señal sobre su madurez.
9. PCI y auditorías de seguridad marcan cada vez más runtimes EOL sin importar si personalmente “te parece bien”. Cumplimiento no se guía por sensaciones.

Árbol de decisión: actualizar, aislar o migrar

Aquí está la verdad directa: si tu hosting no puede ejecutar versiones soportadas de PHP, estás pagando por una máquina del tiempo. A veces eso está bien para un sitio archivo. No está bien para nada que procese pagos, guarde datos personales o necesite actualizaciones de plugins.

Opción A (preferida): Actualizar PHP donde está

Haz esto cuando:

• Controlas el servidor (VPS/dedicado/nube).
• Tu hosting compartido ofrece un selector de versión de PHP por sitio.
• Puedes hacer staging y rollback.

Una buena actualización es aburrida. Aburrido es el objetivo.

Opción B: Aislar el sitio (contenedor/VM) sin cambiar el host

Haz esto cuando:

• Tu host está desactualizado pero no puedes moverte de inmediato (contratos, burocracia o “la persona con credenciales está de vacaciones”).
• Puedes poner el sitio detrás de un proxy inverso y ejecutar PHP moderno en otro lugar.

Son más piezas móviles, pero puede ganar tiempo de forma segura.

Opción C: Migrar a un hosting que no esté atascado en 2019

Haz esto cuando:

• El host no puede proporcionar PHP 8.1/8.2/8.3 hoy.
• No puedes ejecutar múltiples versiones.
• El soporte te dice “simplemente usa una versión antigua del plugin”.

Si la plataforma no puede parchear, no se la puede confiar en producción. No es duro; es la realidad operativa.

Broma corta #1: Ejecutar PHP fuera de vida en producción es como guardar copias de seguridad en el mismo disco: técnicamente existe, espiritualmente no.

Tareas prácticas con comandos (y cómo decidir según la salida)

A continuación hay tareas concretas que puedes ejecutar en un VPS o cualquier host donde tengas acceso shell. Cada tarea incluye: comando, salida de ejemplo, qué significa y qué decisión tomar después. Si estás en hosting compartido sin SSH, harás el equivalente vía panel de control o ticket de soporte, pero la lógica es idéntica.

Task 1: Check the PHP version used by CLI (baseline sanity)

cr0x@server:~$ php -v
PHP 7.4.33 (cli) (built: Nov 16 2023 12:01:17) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

Qué significa: Tu CLI por defecto es PHP 7.4. Esto puede o no coincidir con lo que usa el servidor web.

Decisión: Si el plugin requiere 8.1+, necesitas una versión más reciente de PHP instalada y configurada para la pila web, no solo para CLI.

Task 2: Check what PHP version the web server is serving (the one that matters)

cr0x@server:~$ curl -sI https://example.com | grep -i x-powered-by
X-Powered-By: PHP/7.4.33

Qué significa: La respuesta HTTP publica PHP 7.4. Algunos sitios ocultan este header, pero si está presente es una pista fuerte.

Decisión: Si esto está viejo, procede a identificar el handler (FPM vs mod_php) y la ruta de actualización.

Task 3: If you have WP-CLI, ask WordPress what it sees

cr0x@server:~$ cd /var/www/example.com/public
cr0x@server:/var/www/example.com/public$ wp --info
OS:     Linux 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php7.4
PHP version:    7.4.33
wp-cli version: 2.10.0

Qué significa: WP-CLI se ejecuta bajo PHP 7.4. Eso es útil para la resolución, pero otra vez: el PHP web puede diferir.

Decisión: Trata esto como confirmación de que tu sistema está viejo. Ahora revisa el handler del servidor web.

Task 4: Find whether Apache is using mod_php (common legacy trap)

cr0x@server:~$ apache2ctl -M | grep -E 'php|proxy_fcgi'
 php7_module (shared)

Qué significa: Apache tiene cargado mod_php (aquí como php7_module). Eso normalmente ata Apache a una única versión de PHP.

Decisión: Considera migrar a PHP-FPM. Es la forma limpia de ejecutar múltiples versiones y reducir el acoplamiento.

Task 5: Check PHP-FPM services installed (multi-version readiness)

cr0x@server:~$ systemctl list-units --type=service | grep php | grep fpm
php7.4-fpm.service loaded active running The PHP 7.4 FastCGI Process Manager
php8.2-fpm.service loaded active running The PHP 8.2 FastCGI Process Manager

Qué significa: Ya tienes PHP 8.2 FPM instalado y en funcionamiento. Genial: ahora solo necesitas apuntar el sitio a él.

Decisión: Prefiere cambiar el vhost al php8.2-fpm para este sitio. Mantén 7.4 temporalmente para otros sitios hasta migrarlos.

Task 6: Inspect which FPM socket the site uses (real source of truth)

cr0x@server:~$ grep -R "proxy:unix" -n /etc/apache2/sites-enabled/example.com.conf
42:    SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost/"

Qué significa: Este sitio está anclado al PHP 7.4 FPM.

Decisión: Cámbialo al socket de 8.2 (o 8.1/8.3 según se requiera), recarga Apache y prueba.

Task 7: Verify installed PHP versions and modules (plugins care about extensions)

cr0x@server:~$ php8.2 -m | egrep 'curl|mbstring|intl|openssl|imagick'
curl
intl
mbstring
openssl

Qué significa: Estas extensiones están disponibles para PHP 8.2. Si un plugin necesita imagick y falta, seguirás rompiendo tras la actualización de versión.

Decisión: Instala las extensiones faltantes antes de cambiar el tráfico de producción, o cambia aceptando degradación funcional hasta arreglarlo (habitualmente inaceptable para sitios multimedia).

Task 8: Check for end-of-life PHP packages lingering on Debian/Ubuntu

cr0x@server:~$ apt-cache policy php
php:
  Installed: 2:8.2+93
  Candidate: 2:8.2+93
  Version table:
 *** 2:8.2+93 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

Qué significa: El meta paquete está alineado con PHP 8.2. Eso es bueno, pero no garantiza que tu vhost lo use.

Decisión: Confirma el pool FPM y la configuración del servidor web. El estado del paquete es necesario, no suficiente.

Task 9: Switch an Apache site from PHP 7.4 FPM to PHP 8.2 FPM (surgical change)

cr0x@server:~$ sudo sed -i 's#/run/php/php7.4-fpm.sock#/run/php/php8.2-fpm.sock#g' /etc/apache2/sites-available/example.com.conf
cr0x@server:~$ sudo apache2ctl configtest
Syntax OK
cr0x@server:~$ sudo systemctl reload apache2

Qué significa: La configuración es sintácticamente válida y Apache recargó sin error.

Decisión: Ejecuta inmediatamente una verificación de salud: carga de la página principal, acceso a wp-admin y una comprobación de phpinfo (ver tareas siguientes). Si algo falla, revierte rápido.

Task 10: Confirm the site is now served by the new PHP version

cr0x@server:~$ curl -sI https://example.com | grep -i x-powered-by
X-Powered-By: PHP/8.2.15

Qué significa: Las solicitudes ahora se ejecutan en PHP 8.2.

Decisión: Procede a las comprobaciones funcionales: login, checkout (si hay ecommerce), cron y actualización del plugin.

Task 11: Turn on WordPress debugging safely (log, don’t display)

cr0x@server:~$ sudo -u www-data bash -lc "grep -n \"WP_DEBUG\" -n /var/www/example.com/public/wp-config.php | head"
87:// define('WP_DEBUG', false);

Qué significa: Debug no está explícitamente activado (o está comentado). Puedes habilitar logging sin exponer errores a los visitantes.

Decisión: Habilita WP_DEBUG_LOG y mantiene WP_DEBUG_DISPLAY desactivado. Luego reproduce la falla y lee los logs.

Task 12: Watch PHP-FPM and web logs during a test request (best signal)

cr0x@server:~$ sudo tail -f /var/log/php8.2-fpm.log /var/log/apache2/error.log
[27-Dec-2025 10:11:07] NOTICE: ready to handle connections
[Sat Dec 27 10:11:14.282910 2025] [proxy_fcgi:error] [pid 21234] [client 203.0.113.10:53122] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function mysql_connect() in /var/www/example.com/public/wp-content/plugins/legacy-db/legacy.php:41'

Qué significa: Un plugin legacy usa mysql_connect(), función removida hace mucho. Esto no es un “bug de PHP 8”. Es un plugin que debió ser retirado.

Decisión: Desactiva o reemplaza el plugin. Si es crítico, quizá necesites mantener este sitio en PHP antiguo temporalmente y luego programar la remediación o migración. No mantengas pagos en esta configuración.

Task 13: Disable a broken plugin without wp-admin (safest emergency lever)

cr0x@server:~$ cd /var/www/example.com/public/wp-content
cr0x@server:/var/www/example.com/public/wp-content$ sudo mv plugins/legacy-db plugins/legacy-db.disabled

Qué significa: WordPress dejará de cargar ese plugin porque ya no está en el directorio esperado.

Decisión: Si el sitio se recupera, confirmaste la causa raíz. Reemplaza el plugin o refactoriza la funcionalidad. Si el sitio no se recupera, sigue revisando logs; pueden apilarse fallos múltiples.

Task 14: Check database connectivity and version quickly (some hosts break this during migrations)

cr0x@server:~$ mysql --version
mysql  Ver 8.0.36 for Linux on x86_64 (MySQL Community Server - GPL)

Qué significa: Estás en MySQL 8.0, que en general está bien. Si estuvieras en MySQL muy antiguo, algunos plugins también podrían quejarse.

Decisión: Si PHP se actualiza pero los errores persisten, confirma las extensiones del driver de base de datos (mysqli, pdo_mysql) y las credenciales.

Task 15: Validate WordPress cron behavior after PHP change (silent failure mode)

cr0x@server:~$ cd /var/www/example.com/public
cr0x@server:/var/www/example.com/public$ wp cron event list --fields=hook,next_run --allow-root | head
action_scheduler_run_queue  2025-12-27 10:15:00
wp_version_check            2025-12-27 12:00:00
wp_update_plugins           2025-12-27 12:00:00

Qué significa: Existen eventos de cron. Eso no prueba ejecución, pero es la primera comprobación.

Decisión: Si las tareas programadas dejan de ejecutarse tras una actualización (común al cambiar a un binario PHP distinto), configura un cron del sistema que llame al WP-CLI con la versión correcta de PHP, o arregla el endpoint web de cron.

Task 16: Snapshot before major changes (filesystem snapshot on modern storage)

cr0x@server:~$ sudo zfs snapshot tank/www@example.com@pre-php82
cr0x@server:~$ sudo zfs list -t snapshot | grep pre-php82
tank/www@example.com@pre-php82  0B  -  240G  -

Qué significa: Tienes un snapshot instantáneo. El rollback ahora es un comando, no una plegaria.

Decisión: Procede con la actualización. Si sale mal, puedes revertir rápido. Si no tienes snapshots, emula esto con backups y un clon de staging.

Broma corta #2: Si actualizas PHP un viernes por la tarde, el fin de semana también se actualizará—hacia un fin de semana de trabajo.

Rutas de actualización según el tipo de hosting

Hosting compartido (cPanel, Plesk, “panel personalizado”)

Este es el campo de batalla más común para “el plugin requiere PHP más nuevo”. Sueles tener control limitado, pero no nulo.

• Busca un selector de PHP por dominio. Si puedes elegir PHP 8.1/8.2 por sitio, tu problema se resuelve en 10 minutos. Hazlo en staging primero si el host lo ofrece.
• Si lo más nuevo disponible sigue siendo viejo, escala. Pregunta al soporte cuál es su calendario para PHP 8.2/8.3 y si pueden activarlo para tu cuenta. Su respuesta te dirá si migrar.
• Ojo con las afirmaciones “tenemos PHP 8.x” que son solo para CLI. Algunos hosts ofrecen múltiples CLI pero bloquean el handler web a una versión.

Consejo de opinión: si tu host no puede ofrecer una versión de PHP soportada hoy, empieza a planear una mudanza. No lo debatas meses mientras ignoras actualizaciones de seguridad.

Hosting gestionado de WordPress

Las plataformas gestionadas típicamente hacen despliegues por fases y ofrecen un selector de versión PHP. Tu trabajo es:

• Usar su entorno de staging, no producción, para el primer cambio.
• Confirmar que mantienen versiones antiguas solo temporalmente; no quieres una plataforma que trate EOL como opcional.
• Comprobar si también controlan cache de objetos, cache de página y reglas WAF—esos pueden cambiar el comportamiento cuando se actualiza PHP.

VPS / servidor dedicado (tú administras el desorden, pero también la solución)

Buenas noticias: puedes resolver esto correctamente. Malas noticias: también puedes resolverlo incorrectamente y serás tú quien reciba la pager.

• Prefiere PHP-FPM sobre mod_php. Desacopla el servidor web y permite pools por sitio.
• Instala múltiples versiones si alojas varios sitios, luego migra sitio por sitio.
• Aplica cambios de configuración a un solo vhost primero. No “apt upgrade todo” y esperes lo mejor.

Despliegues en contenedores / Kubernetes

Si ya despliegas WordPress en contenedores, el runtime es solo una etiqueta de imagen. Suena fácil—y lo es—hasta que el almacenamiento persistente y los flujos de actualización de plugins entran en juego.

• Construye o tira una imagen con la versión requerida de PHP.
• Despliega en staging con el mismo volcado de base de datos y snapshot de uploads.
• Asegura que tu volumen persistente soporte snapshots atómicos (o backups consistentes). De lo contrario, el rollback es complicado.

Tres micro-historias del mundo corporativo

Micro-historia #1: El incidente causado por una suposición errónea

Una empresa mediana tenía un sitio WordPress que desde afuera parecía simple: un sitio de marketing con blog, algunas landing pages y una integración de formularios. Estaba hospedado en un VPS que “nadie tocaba”, jerga corporativa para “nadie lo posee”.

Un desarrollador actualizó un plugin de formularios para arreglar un advisory de seguridad. El plugin empezó a requerir PHP 8.1. El servidor estaba en PHP 7.4. La suposición fue: “El SO está actualizado, así que PHP debe estarlo.” El SO estaba actualizado. PHP no. Apache todavía estaba atado al socket FPM antiguo, y los paquetes nuevos estaban instalados pero sin usar.

El sitio entró en un bucle de error fatal, pero solo en ciertas páginas—específicamente las que cargaban la nueva ruta de código del plugin. Eso retrasó el diagnóstico porque la página principal seguía funcionando y todos discutían que “es intermitente”.

El SRE de guardia hizo lo que ahorró tiempo: dejó de debatir y siguió los logs mientras reproducía la petición. El mensaje de error era vergonzosamente explícito: el plugin se negaba a ejecutarse en PHP 7.4.

La solución no fue heroica: cambiar el vhost a PHP 8.2 FPM, desactivar un plugin antiguo que usaba funciones mysql removidas, y luego reactivar funcionalidades una por una. El postmortem trató sobre la propiedad: la versión de runtime es una dependencia, y las dependencias necesitan un propietario. “Nadie lo tocaba” no es estrategia.

Micro-historia #2: La optimización que salió mal

Otra organización quiso menos piezas móviles. Tenían Apache con mod_php porque “es más rápido” y “no necesitamos daemons extra”. Alguien leyó un benchmark antiguo y decidió que PHP-FPM era complejidad innecesaria. También consolidaron varios sitios WordPress en una sola máquina para ahorrar costos.

Entonces un sitio necesitó una extensión moderna de WooCommerce que requería PHP 8.2. Otro sitio tenía un theme legacy que rompía en PHP 8.x debido a warnings de tipado estricto convertidos en excepciones por un manejador de errores personalizado.

Con mod_php, tenían exactamente una versión de PHP para todos. Su “optimización” eliminó la capacidad de migrar de forma incremental. Se vieron forzados a un upgrade big-bang: cambiar PHP para todos los sitios a la vez o dejar todo antiguo. Eligieron cambiar.

La mitad de los sitios fallaron de formas sutiles: formularios de contacto dejaron de enviar, el procesamiento de imágenes falló porque la extensión Imagick no estaba compilada para el nuevo PHP, y trabajos programados murieron silenciosamente. Llegaron tickets de soporte y el equipo pasó una semana haciendo triage de emergencia en lugar de una migración planificada.

Finalmente migraron a PHP-FPM, pools por sitio y un despliegue canario básico. La lección no fue “nunca optimices”. Fue “no optimices la aislación”. En producción, la aislación es rendimiento. Es el rendimiento de las personas bajo presión.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día

Una empresa regulada ejecutaba WordPress para un portal de documentación. No glamoroso, pero era público y auditado. Su equipo de infra tenía una política aburrida: cada cambio pasa por staging, y staging refleja producción lo más cercano posible. Mismo PHP, misma configuración del servidor web, mismas reglas de cache. También tomaban snapshots de filesystem y base de datos antes de cambios de runtime.

Cuando una actualización de plugin empezó a requerir PHP 8.1, no entraron en pánico. Clonaron producción a staging desde el snapshot de la noche anterior, cambiaron staging a PHP 8.2 y ejecutaron un plan de pruebas scriptado: login, búsqueda, render de páginas, subida de archivos y flujos específicos del plugin.

Encontraron un problema: un mu-plugin personalizado usaba funciones obsoletas que ahora eran warnings. En producción, los warnings se promovían a errores por un manejador estricto. Eso habría causado una caída si se hubiera descubierto en vivo.

Arreglaron el mu-plugin, volvieron a correr las pruebas y planearon el cambio a producción. Durante el corte observaron logs y métricas, y tenían un plan de rollback que incluía revertir snapshots y cambiar los sockets FPM de vuelta. Nunca usaron el rollback, que es el punto.

Lo que los salvó no fue genialidad. Fue aburrimiento: un flujo repetible, snapshots y negarse a tratar producción como un sandbox. Si quieres menos incidentes, necesitas más aburrimiento.

Errores comunes: síntoma → causa raíz → solución

Aquí es donde la mayoría de equipos pierde tiempo. Los síntomas parecen drama de WordPress, pero las causas raíz casi siempre son predecibles.

1) Síntoma: Mensaje “El plugin requiere PHP 8.1” en wp-admin

• Causa raíz: El runtime del sitio es más antiguo que la versión mínima del plugin.
• Solución: Actualiza el runtime PHP usado por el servidor web. Confirma revisando headers/logs. No te limites a actualizar PHP en CLI.

2) Síntoma: Pantalla en blanco o “Ha habido un error crítico” tras actualizar un plugin

• Causa raíz: Error fatal por versión de PHP incompatible o extensión faltante.
• Solución: Revisa logs web y de PHP-FPM. Desactiva el plugin renombrando su directorio, luego actualiza PHP o instala la extensión faltante.

3) Síntoma: El sitio sirve a visitantes pero wp-admin está roto (o viceversa)

• Causa raíz: Diferentes rutas de código, carga de plugins distinta o cache ocultando fallos.
• Solución: Evita cache y reproduce mientras sigues logs. Prueba front-end y admin tras cambiar PHP.

4) Síntoma: Tras actualizar PHP, fallan las subidas de medios o dejan de generarse miniaturas

• Causa raíz: Librerías de imagen faltantes (GD/Imagick) para la nueva versión de PHP, o problemas de permisos en uploads.
• Solución: Instala la extensión para el PHP nuevo y reinicia FPM. Verifica con php -m bajo la versión correcta.

5) Síntoma: Errores 502/504 después de cambiar a PHP-FPM

• Causa raíz: Mala configuración del pool FPM, permisos del socket, pm.max_children demasiado bajo o timeouts.
• Solución: Revisa logs para “connect() to unix socket failed” vs “upstream timed out.” Arregla permisos o ajusta límites del pool según tráfico real.

6) Síntoma: “Llamada a función indefinida” tras la actualización

• Causa raíz: Plugin/theme usando funciones removidas/deprecadas; o la extensión requerida no está habilitada.
• Solución: Identifica la función: si es de una extensión, instala/habilita la extensión. Si es comportamiento removido del core, reemplaza plugin/theme.

7) Síntoma: wp-cron se detiene, entradas programadas no se publican, trabajos ecommerce se atascan

• Causa raíz: Cron depende de peticiones web; tras cambios fallan las peticiones loopback, o el cron del sistema llama al binario PHP equivocado.
• Solución: Configura un cron del sistema que llame a WP-CLI con la versión correcta de PHP; revisa loopback y reglas de firewall.

8) Síntoma: Actualizaste PHP pero el plugin sigue diciendo que es antiguo

• Causa raíz: Actualizaste un PHP (CLI) pero el handler web sigue apuntando al antiguo; o existen múltiples runtimes y el sitio está anclado.
• Solución: Localiza el handler (socket FPM, módulo de Apache, fastcgi_pass de Nginx) y cámbialo. Confirma con headers y phpinfo.

Listas de verificación / plan paso a paso

Este es el plan que ejecutaría como SRE soportando WordPress: drama mínimo, máxima reversibilidad.

Checklist A: Antes de tocar producción

1. Lee el requisito del plugin. Versión mínima de PHP, extensiones requeridas y notas sobre la versión de WordPress.
2. Inventaría tu runtime. ¿Qué versión de PHP usa el web? ¿Qué usa CLI? ¿Son diferentes?
3. Lista los flujos críticos. Login, checkout, formularios de contacto, subida de medios, edición en admin, purga de cache, tareas cron.
4. Haz que el rollback sea real. Snapshot de filesystem + base de datos, o al menos un backup que hayas probado restaurar.
5. Construye un clon de staging. Mismo estilo de handler PHP, misma capa de cache, misma configuración.

Checklist B: Flujo de actualización en staging (recomendado aun para sitios “pequeños”)

1. Clona producción a staging (archivos + BD).
2. Cambia staging a la versión objetivo de PHP (8.1/8.2/8.3).
3. Instala extensiones PHP requeridas en staging.
4. Ejecuta la actualización del plugin primero en staging.
5. Ejercita los flujos críticos y sigue los logs.
6. Arregla o reemplaza cualquier plugin/theme incompatible.
7. Anota exactamente los cambios realizados (diffs de configuración, paquetes instalados).

Checklist C: Corte a producción con tiempo de inactividad mínimo

1. Elige una ventana tranquila. Incluso cambios “sin downtime” tienen riesgo, y el riesgo es menor con menos tráfico.
2. Aplica los mismos cambios de runtime que en staging. No improvises.
3. Recarga, no reinicies, cuando sea posible. Recargar la configuración del servidor web reduce la disrupción.
4. Ejecuta checks de salud inmediatamente. Página principal, wp-admin y un flujo específico del plugin.
5. Observa logs por 15–30 minutos. Muchos fallos aparecen solo cuando corren trabajos en background.
6. Solo entonces actualiza el plugin en producción (si no lo hiciste y si la política lo permite).

Checklist D: Si no puedes actualizar PHP en el host

1. Detén la actualización del plugin. Mantén la versión actual si no es vulnerable.
2. Evalúa el riesgo: si la actualización del plugin era por un parche de seguridad, date por en la cuenta que tienes tiempo limitado.
3. Elige una estrategia de contención:
   • Migrar el sitio a un host nuevo que soporte PHP moderno.
   • Levantar un VPS nuevo y migrar DNS.
   • Poner un proxy inverso delante y ejecutar WordPress en otro lugar.
4. Haz la migración aburrida. Archivos, base de datos, configuraciones y un plan de corte con rollback (TTL de DNS, snapshot, modo mantenimiento).

Cómo pensar en seguridad: compatibilidad, seguridad y rollback

La peor mentalidad es “actualizar PHP da miedo”. La segunda peor es “actualizar PHP no es nada”. Trátalo como cualquier actualización de runtime: cambia comportamiento, manejo de errores, características de rendimiento y ocasionalmente disponibilidad de librerías.

Este es el marco operativo que funciona:

• El riesgo de compatibilidad se centra en plugins/themes viejos. Inventaríalos y retíralos. Si algo no se actualiza desde años, no es “estable”, está abandonado.
• El riesgo de seguridad aumenta con el tiempo. Una versión vieja de PHP no es solo más lenta o fea; es una responsabilidad. A veces los hosts “backportean parches”, pero debes pedir claridad: ¿qué parchean y con qué rapidez?
• El rollback debe ser mecánico. Si el rollback es “intentaremos deshacerlo”, eso no es rollback. Eso es improvisación.

Idea parafraseada de Werner Vogels (CTO de Amazon): construyes sistemas fiables esperando fallos y diseñando la recuperación, no esperando que nada se rompa.

Qué evitar (opiniones firmes ganadas a pulso)

• No edites código vendor/plugin para “hacerlo compatible”. Lo olvidarás, las actualizaciones automáticas lo sobrescribirán y el próximo incidente será tu culpa.
• No hagas cambios en producción sin logs. Si no puedes ver errores de PHP-FPM y del servidor web, estás depurando con los ojos vendados.
• No mantengas ecommerce en un runtime EOL. Si pasa dinero, la cadencia de parches es parte del producto.
• No asumas “el host se encargará”. Algunos sí. Muchos no. Verifica.
• No confundas “WordPress lo soporta” con “los plugins lo soportan”. Tu plataforma real es el ecosistema que instalaste.

Preguntas frecuentes

1) ¿Puedo simplemente instalar una versión anterior del plugin?

Puedes, a veces. Es un parche temporal, no una solución. Si el plugin dejó versiones antiguas por motivos de seguridad o dependencias, anclar versiones antiguas puede dejarte expuesto. Usa esto solo para ganar tiempo mientras actualizas PHP o migras.

2) Si actualizo PHP, ¿se romperá el core de WordPress?

WordPress moderno generalmente funciona bien en PHP 8.1/8.2/8.3. Las rupturas suelen venir de themes/plugins antiguos o código personalizado. Por eso staging importa: te dice qué dependencia es el problema antes de que lo noten los usuarios.

3) Mi host dice “soportamos PHP 8”, pero el plugin aún se queja. ¿Por qué?

Porque “soportar” puede significar “disponible para algunas cuentas”, “disponible para CLI” o “disponible si cambias un selector por sitio”. Confirma el runtime usado por el servidor web, no solo lo que está instalado.

4) ¿A qué versión de PHP debería apuntar ahora mismo?

Apunta a una versión de PHP actualmente soportada ofrecida por tu distro/host—típicamente PHP 8.2 o 8.3. Si el plugin requiere 8.1, no te quedes solo en 8.1 sin motivo; pronto tendrás que repetir el ejercicio.

5) ¿Cómo actualizo PHP sin tiempo de inactividad?

Ejecuta múltiples versiones de PHP-FPM, cambia el socket upstream del sitio y recarga el servidor web. Eso suele ser un cambio casi instantáneo. El verdadero riesgo de downtime viene de incompatibilidades en la aplicación, que staging y snapshots mitigan.

6) ¿Y si otro sitio en el mismo servidor necesita PHP antiguo?

Entonces quieres PHP-FPM con múltiples pools/versiones y configuración por vhost. Si estás atascado en mod_php, te has encerrado. Migra sitios legacy o aíslalos en una VM/contenedor separado.

7) ¿Actualizar PHP es suficiente, o necesito actualizar MySQL/MariaDB también?

Usualmente PHP es el bloqueo para el error del plugin. Pero ya que estás ahí, revisa versiones de base de datos y extensiones. Algunos plugins modernos asumen comportamiento de MySQL/MariaDB más reciente, especialmente en juegos de caracteres y modos SQL estrictos.

8) El sitio funciona después de la actualización, pero el rendimiento empeoró. ¿Qué pasó?

Causas comunes: OPcache no está habilitado/configurado para el PHP nuevo, límites del pool FPM demasiado bajos o capas de cache comportándose distinto. Confirma el estado de OPcache y ajusta FPM en lugar de culpar a la versión sin más.

9) No tengo acceso SSH. ¿Qué puedo hacer?

Usa el panel de control de hosting para cambiar la versión de PHP si está disponible, y usa Estado del sitio de WordPress para confirmar el cambio. Si el host no ofrece un runtime moderno, migra. La falta de SSH no es fatal; la falta de runtimes soportados sí lo es.

Próximos pasos que puedes tomar hoy

Aquí hay una secuencia práctica que funciona en el mundo real:

1. Confirma la versión real de PHP usada por el servidor web. No confíes en el panel de marketing; confía en headers y logs.
2. Elige la ruta más limpia: actualizar in situ si puedes, aislar si debes, migrar si corresponde.
3. Haz staging. Clona, cambia PHP, actualiza el plugin, prueba los flujos de dinero y admin.
4. Haz el rollback mecánico. Snapshots o backups probados. No “recordaremos lo que cambiamos”.
5. Realiza el corte y observa. Logs, cron y tasas de error por al menos 15–30 minutos.
6. Luego limpia. Elimina plugins abandonados, documenta el handler de PHP y programa revisiones periódicas del runtime para que esto no te sorprenda otra vez.

Si tu host no puede proporcionar versiones de PHP soportadas, no negocies con la física. Muévete. Los sistemas de producción no mejoran con deseos; mejoran con propiedad y cambios repetibles.