PHP 8.2 termina su soporte en diciembre de 2026: guía de migración para WordPress

Actualizado: 21 de octubre de 2026.

Respuesta rápida: PHP 8.2 llega al final de su soporte de seguridad el 31 de diciembre de 2026. Si tu web todavía depende de esa rama, planifica la migración antes de esa fecha y no esperes al último día. PHP 8.3, 8.4 y 8.5 siguen siendo ramas soportadas; la versión adecuada depende de la compatibilidad del CMS, los plugins, el tema y el hosting. Para una migración segura, inventaría dependencias, crea un entorno de pruebas, ejecuta pruebas funcionales y prepara una vuelta atrás.

Las actualizaciones de seguridad de PHP del 21 de octubre de 2026 han recordado que mantener el intérprete actualizado es una tarea operativa crítica, no un detalle técnico que pueda aplazarse indefinidamente. PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas. Aunque instalar el parche urgente es la prioridad inmediata, los responsables de sitios que aún usan ramas antiguas deberían aprovechar este momento para planificar una estrategia de versiones a medio plazo.

Qué significa el fin de soporte de PHP 8.2

PHP mantiene sus ramas durante un periodo de soporte activo y, después, durante un periodo de correcciones de seguridad. Según la tabla oficial de versiones soportadas, PHP 8.2 deja de recibir soporte de seguridad el 31 de diciembre de 2026. Cuando una rama llega al final de su vida útil, los errores y vulnerabilidades nuevos pueden quedar sin una corrección oficial para esa versión.

Esto no significa que una web deje de funcionar a medianoche ni que el fin de soporte provoque por sí solo un ataque. Significa que mantener esa versión aumenta progresivamente el riesgo y la carga operativa: las incidencias futuras pueden requerir cambios de código, migraciones urgentes o soluciones de terceros. La compatibilidad heredada también puede impedir aprovechar mejoras de rendimiento y mantenimiento disponibles en ramas más recientes.

Qué versión de PHP deberías elegir

No existe una versión universalmente mejor para todas las instalaciones. A fecha de esta guía, PHP 8.3, 8.4 y 8.5 figuran en la tabla oficial de ramas soportadas; PHP 8.2 tiene soporte de seguridad hasta finales de 2026. Elige la versión más reciente que sea compatible con la aplicación y sus dependencias, y que tu proveedor pueda mantener con actualizaciones oportunas.

Para WordPress, la decisión no debe basarse únicamente en que el núcleo arranque en una versión nueva. Un plugin antiguo puede utilizar funciones retiradas, un tema puede depender de una librería sin mantenimiento y una tienda puede tener integraciones con pasarelas de pago que necesitan pruebas. Antes de cambiar la versión de producción, consulta la documentación de WordPress y de cada extensión crítica, y verifica que el hosting permita cambiar y volver a cambiar la versión sin una intervención prolongada.

Fase 1: inventario de sitios y dependencias

Haz una lista de todos los dominios, subdominios, entornos de pruebas, tareas cron, procesos de importación y aplicaciones que ejecutan PHP. En alojamientos compartidos puede haber una versión por dominio; en servidores propios pueden convivir varias versiones y pools de PHP-FPM. Registra qué sistema es propietario de cada servicio, su importancia para el negocio y la persona que puede aprobar la migración.

Después, anota las versiones del CMS, los plugins, el tema, las bibliotecas y las integraciones externas. Identifica extensiones que ya no se actualizan y código personalizado que no tenga pruebas. Este inventario ayuda a distinguir una actualización sencilla de una migración que necesita presupuesto, un proveedor especializado o una ventana de mantenimiento.

Fase 2: prepara una copia y un entorno de pruebas

Antes de modificar producción, crea una copia reciente de los archivos y de la base de datos, y confirma que puede restaurarse. Replica el sitio en un entorno de staging protegido, con una copia de datos que respete las obligaciones de privacidad. No expongas el staging al público sin autenticación y evita que envíe correos, procese pagos reales o ejecute tareas que afecten a clientes.

Configura en staging la versión objetivo de PHP y reproduce los ajustes relevantes: extensiones, límites de memoria, configuración de errores, trabajos programados y servicios externos. Una prueba que solo carga la página de inicio no es suficiente para detectar incompatibilidades.

Fase 3: ejecuta pruebas funcionales

Prueba el inicio de sesión, formularios, búsquedas, subida de imágenes, generación de PDF, correos, pagos de prueba, importaciones y exportaciones. En una tienda, revisa el carrito, el checkout y los webhooks en modo de prueba. En un portal editorial, comprueba el editor, las imágenes destacadas, la publicación programada y los permisos de los usuarios.

Revisa también los registros de errores de PHP y del servidor. Los avisos que antes pasaban desapercibidos pueden revelar llamadas a funciones obsoletas o comportamientos distintos. No soluciones todos los avisos ocultándolos; identifica si el origen está en código propio, una extensión o una configuración y decide cómo corregirlo.

Fase 4: define un plan de despliegue y vuelta atrás

Establece una ventana de cambio, un responsable y criterios claros de éxito. Conserva la versión anterior disponible si la arquitectura del hosting lo permite, junto con la copia de seguridad y los pasos para revertir el cambio. Asegúrate de que la reversión no dependa de una única persona y que el equipo sepa cuándo activar el plan.

Después del cambio, verifica la versión efectiva en el servidor, no solo el valor seleccionado en el panel. Comprueba las funciones principales, el registro de errores, los tiempos de respuesta y las integraciones. Mantén vigilancia reforzada durante las primeras horas y días, y registra cualquier desviación para poder correlacionarla con el despliegue.

Cómo encaja la migración con los parches urgentes de octubre

La migración a una rama más nueva no sustituye la aplicación inmediata de las versiones corregidas. Si hoy estás en una rama soportada vulnerable, aplica primero el parche correspondiente o acuerda con el proveedor la medida temporal apropiada. Después, programa la migración de versión mayor o menor con pruebas. No confundas actualizar de 8.2.x a la versión corregida de 8.2 con completar la transición a otra rama.

PHP ha indicado que no hay una mitigación completa que reemplace la instalación de las versiones corregidas para las vulnerabilidades publicadas el 21 de octubre. Puedes leer nuestra guía de respuesta ante PHP2Shell para el checklist urgente. Para mejorar el rendimiento general después de estabilizar la seguridad, consulta también nuestra guía para acelerar WordPress y revisar caché, imágenes y Core Web Vitals.

Errores frecuentes que conviene evitar

• Actualizar directamente en producción: puede romper procesos críticos sin una forma rápida de recuperación.
• Confiar en la página de inicio: los fallos suelen aparecer en formularios, pagos, importaciones o tareas programadas.
• Ignorar plugins abandonados: una extensión sin mantenimiento puede bloquear el salto a una rama nueva.
• Confundir el parche con la migración: instalar una versión de corrección no elimina la necesidad de planificar el fin de soporte.
• Olvidar las tareas cron y los workers: no todo el código PHP se ejecuta durante una visita web.
• No verificar la restauración: una copia de seguridad que nunca se ha probado no es un plan de recuperación completo.

Preguntas frecuentes sobre el soporte de PHP

¿Cuándo termina el soporte de seguridad de PHP 8.2?

El calendario oficial indica el 31 de diciembre de 2026. Conviene preparar la migración antes de esa fecha, no cuando ya haya terminado el soporte.

¿Debo saltar directamente a PHP 8.5?

Solo si tu aplicación, sus extensiones y el proveedor son compatibles. Selecciona una rama soportada que puedas probar y mantener de forma fiable.

¿Actualizar PHP puede romper WordPress?

Puede revelar incompatibilidades en plugins, temas o código personalizado. Un staging con pruebas funcionales reduce el riesgo antes de tocar producción.

¿Tengo que cambiar la versión del CMS al mismo tiempo?

No necesariamente. Planifica los cambios para que sean comprobables y recuperables; en algunos sitios es mejor separar la actualización del intérprete y la del CMS.

¿Una copia de seguridad basta para revertir?

No siempre. Verifica que puedes restaurar archivos y base de datos, y que las transacciones realizadas después de la copia pueden gestionarse sin pérdida inesperada de datos.

¿El proveedor de hosting puede hacerlo por mí?

Sí, muchos proveedores permiten cambiar PHP desde el panel o gestionan la actualización. Pide que confirmen qué versión ejecuta cada dominio, el momento del cambio y cómo volver atrás si aparece un fallo.

Fuentes oficiales

• PHP.net: versiones soportadas y calendario de mantenimiento.
• PHP.net: ramas fuera de soporte.
• PHP.net: publicaciones y parches de seguridad de octubre de 2026.
• Manual oficial de PHP: introducción a la seguridad.

La compatibilidad varía según el proyecto. En aplicaciones críticas, valida la migración con un entorno de pruebas y con el proveedor responsable de la infraestructura.