No usar en producción
Un Release Candidate sigue siendo una versión preliminar. Sirve para identificar y notificar problemas, no para sustituir inmediatamente una rama estable en el servidor principal.
Procesando…
Compatibilidad y migración
PHP 8.6 entra en su última fase de estabilización antes de un lanzamiento general previsto para el 19 de noviembre de 2026. Para las aplicaciones PHP y los sitios WordPress, ha llegado el momento de probar la compatibilidad, no de migrar producción.
El desarrollo de PHP 8.6 superó el hard feature freeze el 22 de septiembre de 2026: las funcionalidades han quedado congeladas y los esfuerzos se centran ahora en la estabilización. El calendario prevé varios Release Candidates antes de la versión estable, pero el estado exacto de cada versión preliminar debe comprobarse en los anuncios oficiales.
PHP 8.6 está lo bastante avanzado como para iniciar pruebas representativas. Sin embargo, sigue siendo una versión preliminar: las pruebas deben realizarse en un entorno aislado que cubra el código, las dependencias, las sesiones, la base de datos y los recorridos de negocio.
El calendario del proyecto fija el hard feature freeze para el 22 de septiembre de 2026. Sitúa un Release Candidate el 24 de septiembre, seguido de otras versiones candidatas el 8 y el 22 de octubre y el 5 de noviembre, antes de un lanzamiento estable actualmente previsto para el 19 de noviembre de 2026.
El calendario se ha ajustado: RC1 aparece como cancelada y RC2 está prevista para el 24 de septiembre. En el momento de redactar este artículo, el 24 de septiembre de 2026, php.net todavía muestra PHP 8.6 Beta 3 como la última versión de prueba anunciada oficialmente.
Por tanto, RC2 figura en el calendario para esa fecha, pero no debe considerarse publicada antes de que se ponga en línea el anuncio oficial. Esta distinción ilustra una regla útil durante todo el ciclo: consultar tanto el calendario previsto como las publicaciones efectivas del proyecto.
Un Release Candidate sigue siendo una versión preliminar. Sirve para identificar y notificar problemas, no para sustituir inmediatamente una rama estable en el servidor principal.
Los resultados solo tienen valor si la configuración de PHP, las extensiones, la base de datos y los servicios externos son similares a los de producción.
El control debe cubrir el código a medida, el framework o CMS, las bibliotecas de Composer, las extensiones y los procesos programados.
Los errores, advertencias y obsolescencias deben revisarse, incluso cuando las páginas parezcan funcionar con normalidad.
Una aplicación que funciona con PHP 8.5 no puede declararse automáticamente compatible con PHP 8.6. Las rutas que se ejecutan con poca frecuencia — importaciones, exportaciones, tareas CRON, procesamiento de archivos o escenarios de error — suelen ser las que revelan las diferencias.
PHP 8.6 debe modificar tres valores predeterminados: session.use_strict_mode pasa de 0 a 1, session.cookie_httponly de 0 a 1, y session.cookie_samesite de un valor no definido a Lax.
Estas decisiones buscan una configuración más segura frente a ciertos riesgos relacionados con las sesiones y las solicitudes entre sitios. Deberían ser transparentes para muchas aplicaciones modernas, especialmente cuando estas protecciones ya están configuradas explícitamente.
Con session.cookie_httponly=1, la cookie deja de ser accesible desde document.cookie. Toda aplicación que recupere el identificador de sesión en el navegador debe revisarse y, en principio, orientarse hacia un mecanismo de autenticación específico.
Normalmente, la cookie no se envía en determinadas solicitudes cross-site. Por tanto, el SSO, los formularios entre dominios, los retornos de servicios de terceros y las arquitecturas multidominio requieren pruebas de extremo a extremo.
Un mecanismo de inicio de sesión puede superar una prueba unitaria y fallar cuando un navegador atraviesa varios dominios. La autenticación, el cierre de sesión, las redirecciones y los retornos de pasarelas externas forman parte de los primeros escenarios que deben repetirse.
También hay que comprobar el comportamiento de las sesiones existentes, la rotación de identificadores y las posibles suposiciones históricas del código. El modo estricto puede revelar implementaciones que antes aceptaban identificadores no inicializados por el servidor.
Las aplicaciones que leen la cookie de PHP en JavaScript o hacen circular una sesión entre varios dominios presentan un riesgo mayor. Deben examinarse antes de tomar cualquier decisión de migración.
El documento UPGRADING de PHP 8.6 recoge varios comportamientos que se vuelven más estrictos. Las funciones relacionadas con arrays, rutas, configuraciones regionales, procesos, archivos comprimidos o determinadas extensiones pueden lanzar ahora de forma más clara una ValueError o una TypeError.
En particular, array_filter() debe rechazar un modo no válido con una ValueError. pathinfo() comprueba con más rigor su parámetro de bandera, mientras que otras funciones ya no toleran ciertos valores fuera de rango.
Por tanto, una comprobación limitada a la página de inicio no es suficiente. Los formularios, las llamadas API, las importaciones, las exportaciones, los procesos asíncronos y los escenarios degradados deben ejecutarse con datos válidos y no válidos.
mbstring. Deben identificarse las llamadas directas e indirectas a través de Composer.COM_RESET_CONNECTION.configure.COM_RESET_CONNECTION permite devolver una conexión a su estado inicial antes de reutilizarla. Las versiones anteriores de la base de datos pueden seguir funcionando con PHP 8.6, pero ya no con las conexiones persistentes de la misma manera.
Una aplicación que dependa involuntariamente de un estado dejado por una consulta anterior también puede cambiar de comportamiento. Este riesgo es limitado en los entornos modernos, pero merece revisarse en software empresarial y servidores que se conservan desde hace varios años.
El requisito de Autoconf 2.71 afecta sobre todo a los entornos personalizados y a las pipelines que construyen PHP directamente desde sus fuentes Git. No se aplica del mismo modo a las compilaciones realizadas a partir de los archivos oficiales de publicación.
Por tanto, las imágenes internas deben auditarse para determinar su origen, sus herramientas de compilación y su compatibilidad con el estándar C11.
El objetivo de esta fase no es demostrar que una página se muestra, sino descubrir ahora qué podría romperse durante la futura migración.
Las pruebas de compatibilidad también pueden servir para estudiar las posibilidades que ofrece PHP 8.6. Varias evoluciones afectan a la escritura del código, los objetos inmutables y la manipulación de URI.
La aplicación parcial de funciones permite fijar algunos argumentos y dejar otros pendientes de completar. Una expresión como $replaceHello = str_replace('hello', 'bonjour', ?); produce una Closure que espera el valor que falta.
PHP 8.6 también permite un valor predeterminado en determinadas propiedades de instancia readonly. La API URI avanza con funciones de construcción e identificación, una mejor gestión de la codificación porcentual y la clase Uri\Rfc3986\UriBuilder.
Una incompatibilidad puede proceder de una biblioteca y no del código de negocio. El changelog de Composer 2.10.3, publicado el 27 de agosto de 2026, menciona explícitamente correcciones de mensajes de obsolescencia relacionados con PHP 8.6.
Un enfoque razonable consiste en crear una rama específica, instalar PHP 8.6 en un entorno aislado y ejecutar después composer update y composer check-platform-reqs. A continuación deben realizarse las pruebas automatizadas y analizarse las advertencias.
A 24 de septiembre de 2026, la matriz oficial de compatibilidad de WordPress documenta PHP hasta la versión 8.5. PHP 8.6 todavía no figura en ella, lo que es coherente con la fase actual de su desarrollo.
El trabajo de compatibilidad con las nuevas versiones de PHP suele comenzar después del feature freeze y de las versiones beta. Por tanto, el simple acceso al panel de administración no permite concluir que un sitio esté listo para producción.
WordPress Core, el tema activo, el tema hijo, cada extensión, el código personalizado, las posibles dependencias de Composer, las tareas programadas y los servicios externos deben validarse por separado.
Indica el nivel de compatibilidad de WordPress Core, pero no cubre automáticamente los temas, las extensiones y los desarrollos propios del sitio.
Depende del conjunto realmente instalado y configurado, incluidas las integraciones externas, las tareas programadas y los recorridos editoriales o comerciales.
El nivel de prioridad depende de la arquitectura del proyecto. No obstante, las sesiones y los flujos multidominio merecen una atención especial debido a los nuevos valores predeterminados.
| Área | Controles | Riesgo que se busca |
|---|---|---|
| Sesiones | Inicio de sesión, cierre de sesión, SSO, POST entre sitios y retornos externos | Cookie ausente o inaccesible |
| Código y dependencias | Pruebas, obsolescencias, tipos y parámetros no válidos | Excepciones o comportamientos modificados |
| Datos | Importaciones, exportaciones, archivos, archivos comprimidos y generación de documentos | Rutas poco probadas que se vuelven bloqueantes |
| Infraestructura | Extensiones, Docker, compilación, MySQL o MariaDB | Requisitos previos no satisfechos |
| CMS | Núcleo, tema, extensiones, tareas programadas y código personalizado | Compatibilidad parcial del sitio |
| Rendimiento | Tiempo de respuesta, memoria, procesos y carga SQL | Regresión propia del proyecto |
Las notas de PHP 8.6 señalan optimizaciones relacionadas, entre otras cosas, con printf(), determinadas llamadas a constructores, array_map(), JSON, DOM y las compilaciones ZTS. Estas evoluciones deben medirse en la aplicación real en lugar de extrapolarse desde un microbenchmark.
El tiempo de respuesta, el consumo de memoria, la duración de los procesos en segundo plano y la carga de la base de datos proporcionan indicadores más útiles para decidir una migración.
La preparación puede comenzar antes de la versión estable, siempre que se proteja producción y se documente cada resultado. El objetivo es obtener una imagen fiable de los bloqueos, las obsolescencias y los trabajos necesarios.
El lanzamiento estable de PHP 8.6 está previsto actualmente para el 19 de noviembre de 2026, pero eso no obliga a cambiar de versión de inmediato. PHP 8.5, lanzado el 20 de noviembre de 2025, seguirá contando con soporte activo hasta finales de 2027 y después deberá recibir correcciones de seguridad hasta finales de 2029. PHP 8.4 también sigue siendo una rama con soporte.
Por tanto, una aplicación estable puede esperar hasta que sus dependencias y su infraestructura estén preparadas. En cambio, posponer las primeras pruebas durante varios años convierte una migración planificable en deuda técnica.
El periodo de los Release Candidates ofrece tiempo a los equipos, los mantenedores de bibliotecas y los editores de extensiones para identificar incompatibilidades. Así, las correcciones pueden prepararse antes de que la nueva versión se convierta en un objetivo de producción.
El cambio efectivo debe realizarse después de validar el entorno completo, la copia de seguridad, el plan de reversión y los componentes de terceros.
PHP 8.6 aporta nuevas API y varias mejoras, pero su valor en producción dependerá primero de la calidad de la preparación. Los cambios de sesión, la validación más estricta de los parámetros y los requisitos técnicos constituyen las prioridades de prueba.
Tanto para WordPress como para una aplicación PHP a medida, el método es el mismo: poner a prueba una copia representativa, observar los registros, probar los recorridos reales y modificar el servidor principal solo después de la validación.
El calendario de las versiones preliminares todavía puede cambiar. Por tanto, el estado de los Release Candidates y de la versión estable debe confirmarse en las publicaciones oficiales antes de tomar cualquier decisión operativa.
Calendario oficial del proyecto PHP 8.6 y documento de migración UPGRADING, que deben consultarse en los espacios oficiales del proyecto PHP para confirmar el estado de las versiones preliminares y los cambios técnicos.
Matriz oficial de compatibilidad de PHP de WordPress y changelog de Composer 2.10.3, citados para situar el estado de compatibilidad y las herramientas a 24 de septiembre de 2026.
Desarrollo web
Migración de PHP, actualización de un CMS o cambio de framework: identifique los problemas de compatibilidad y pruebe los recorridos esenciales antes de publicar.
Introduce al menos 2 caracteres para iniciar la búsqueda.