# PHP 8.6: las pruebas que deben realizarse antes de noviembre > PHP 8.6 se acerca a su lanzamiento previsto para el 19 de noviembre de 2026. Sesiones, Composer, WordPress y MySQL: los puntos que deben probarse antes de la migración. Compatibilidad y migración ## PHP 8.6 entra en fase Release Candidate: ¿qué probar antes de noviembre? 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. ![php 8 6 release candidate migration testing](https://sdx-development.com/media/News/php-8-6-release-candidate-migration-testing.webp?v=1790229923) [Desarrollo web](https://sdx-development.com/es/noticias/desarrollo-web)Publicado el 24 de septiembre de 2026 a las 08:12 **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. Lo esencial ## Preparar en lugar de desplegar 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. ## Un calendario avanzado, pero todavía sujeto a cambios 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. 01 ### 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. 02 ### Entorno representativo 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. 03 ### Aplicación completa El control debe cubrir el código a medida, el framework o CMS, las bibliotecas de Composer, las extensiones y los procesos programados. 04 ### Registros bajo vigilancia 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. ## Los nuevos ajustes de sesión son prioritarios 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. HttpOnly ### JavaScript ya no puede leer la cookie de sesión 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. SameSite=Lax ### Algunos POST entre sitios pueden perder la sesión 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. ### Probar los recorridos reales, no solo las funciones aisladas 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. Punto de atención ## Un cambio más visible en las arquitecturas antiguas 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. ## Un control más estricto de las entradas no válidas 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. ### Cuatro áreas técnicas que deben revisarse 1. **Mbregex:** la parte mbregex de Mbstring está obsoleta, sin que desaparezca toda la extensión ` mbstring `. Deben identificarse las llamadas directas e indirectas a través de Composer. 2. **MySQL y MariaDB:** las conexiones persistentes requieren como mínimo MySQL 5.7.3 o MariaDB 10.2.4, versiones que introdujeron ` COM_RESET_CONNECTION `. 3. **Compilación:** una compilación directa desde el repositorio Git requiere Autoconf 2.71. Los archivos oficiales ya incluyen el script ` configure `. 4. **Herramientas:** Composer, el análisis estático, las imágenes Docker y las pipelines también deben ser compatibles con la nueva rama. ### Conexiones persistentes: no depender de un estado residual ` 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. ### Compilar PHP desde Git 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. ## Novedades que deben evaluarse en paralelo 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 `. ## Empezar por Composer y las dependencias 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. ## WordPress: controlar el sitio, no solo el núcleo 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. ### Dos niveles de compatibilidad distintos Base ### Compatibilidad del núcleo Indica el nivel de compatibilidad de WordPress Core, pero no cubre automáticamente los temas, las extensiones y los desarrollos propios del sitio. Proyecto ### Compatibilidad del sitio completo Depende del conjunto realmente instalado y configurado, incluidas las integraciones externas, las tareas programadas y los recorridos editoriales o comerciales. ## Los principales controles que deben planificarse 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. ## ¿Cómo organizar las pruebas sin riesgo? 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. ## Checklist de preparación para PHP 8.6 1. **Inventariar la versión de PHP, las extensiones, el CMS o framework, Composer, la base de datos, las tareas CRON y los servicios externos.** 2. **Crear una rama específica y un entorno de preproducción suficientemente parecido a producción.** 3. **Actualizar las herramientas y comprobar después las restricciones de plataforma de las dependencias.** 4. **Activar el registro de errores, advertencias y obsolescencias.** 5. **Repetir los recorridos críticos, especialmente la autenticación, los pagos, los webhooks, los archivos y las tareas programadas.** 6. **Medir el rendimiento antes y después en condiciones comparables.** ## No es necesario migrar el primer día 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. ### La decisión correcta depende de los resultados 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. ## Una futura versión que debe prepararse 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. Referencias mencionadas en el brief Mostrar 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 ## Prepare la próxima actualización de su aplicación 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. - Compatibilidad de las dependencias comprobada - Recorridos esenciales probados en preproducción - Despliegue con un plan de reversión [Planificar su actualización](https://sdx-development.com/es/contacto)[Ver nuestras especialidades](https://sdx-development.com/es/servicios) --- [Consultar la página HTML](https://sdx-development.com/es/noticias/desarrollo-web/php-8-6-las-pruebas-que-deben-realizarse-antes-de-noviembre)