PHP 8.6 RC3: qué probar hoy en WordPress sin arriesgar producción

El 6 de octubre de 2026 el equipo de PHP etiquetó PHP 8.6.0 RC3 junto con PHP 8.5.12 RC1 y PHP 8.4.27 RC1. Según la cobertura publicada, son versiones de corrección de errores y de seguridad de memoria, sin funciones nuevas y sin CVE asociados. Son candidatas a lanzamiento: sirven para probar, no para producción. Acá va qué significa esto para tu WordPress.

Qué se publicó exactamente

• PHP 8.6.0 RC3: la rama de desarrollo ya pasó el congelamiento de funciones; el RC3 corrige problemas pendientes antes de la versión final.
• PHP 8.5.12 RC1 y 8.4.27 RC1: próximas versiones de mantenimiento de las ramas activas.
• Fechas: el anuncio habla de versiones finales "en las próximas semanas" si no aparecen errores críticos. No hay fecha cerrada, así que no la des por segura.

Antes de esto, el 24 de septiembre salieron las versiones de seguridad PHP 8.5.11, 8.4.26, 8.3.35 y 8.2.34. Si todavía no actualizaste a esas, ese es el pendiente real; el RC no lo reemplaza. Las novedades oficiales están en el archivo de noticias de php.net.

Qué NO deberías hacer

No instales un release candidate en un sitio en producción. Un RC puede traer regresiones, y WordPress depende de plugins y temas que no siempre se prueban contra versiones nuevas de PHP. Si tu hosting te ofrece "la última versión" automáticamente, revisá que no incluya versiones de prueba.

Qué SÍ conviene hacer: un entorno de pruebas

Si querés adelantarte a PHP 8.6, hacelo en una copia de tu sitio (staging), nunca en el sitio vivo:

1. Cloná el sitio a un entorno aparte con la misma configuración que producción.
2. Activá el modo de depuración y revisá el log de errores buscando avisos de funciones obsoletas (deprecated) y errores fatales.
3. Probá las rutas críticas: portada, entradas, formulario de contacto, buscador y, si tenés tienda, carrito y checkout.
4. Anotá qué plugin o tema falla y consultá si su autor declara compatibilidad.

Hacer esto ahora te da margen: cuando la versión final salga, ya sabrás qué falta resolver y no tendrás que improvisar.

Cómo encaja la caché en una migración de PHP

Una caché de página que sirve HTML estático reduce cuánto PHP se ejecuta en cada visita: el visitante recibe un archivo ya generado en vez de pasar por WordPress. Eso no te exime de actualizar PHP (el panel de administración, el login, el checkout y la regeneración de páginas siguen usando PHP), pero sí hace que una visita típica dependa menos del intérprete. Podés leer cómo lo hace cache.lat en la página de funcionamiento y revisar los detalles en datos técnicos.

Después de cambiar de versión de PHP

• Purgá la caché completa para que las páginas se regeneren con la versión nueva y no queden copias viejas con errores.
• Verificá la portada y un par de entradas, comparando contra la versión anterior.
• Comprobá que las páginas sigan saliendo como archivo estático y no estén evitando la caché.

Plan sugerido para esta semana

• Hoy: confirmá que tu servidor corre una versión con los parches de seguridad de septiembre (8.5.11, 8.4.26, 8.3.35 u 8.2.34, según tu rama).
• Esta semana: creá o actualizá tu entorno de pruebas.
• Cuando salga la versión final: probá en staging, esperá a que tus plugins clave confirmen compatibilidad y recién ahí planificá la migración.

Si tenés dudas sobre cómo configurar la caché durante una migración, la documentación de cache.lat es el mejor punto de partida.

Fuentes: php.net y la cobertura de warp2search del 7 de octubre de 2026.