Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Hay un momento en el que XAMPP configurar múltiples versiones PHP deja de ser un trámite de cinco minutos y se convierte en un problema real: cuando dos proyectos en la misma máquina exigen versiones incompatibles y ninguno de los dos puede actualizarse. El atajo habitual —cambiar la carpeta de PHP en httpd.conf y reiniciar Apache— funciona para un cambio puntual, pero se cae cuando necesitas alternar entre PHP 7.4 y PHP 8.2 varias veces al día, o cuando el equipo comparte configuraciones y nadie recuerda qué versión estaba activa.
Lo he visto en un escenario muy concreto: un legacy con dependencias ancladas a PHP 7.4 (una librería de facturación electrónica que nunca se actualizó) conviviendo con un Laravel moderno que exige PHP 8.1 o superior. El reflejo de muchos tutoriales es instalar dos XAMPP completos en carpetas distintas. Funciona, sí, pero duplica el espacio, duplica los servicios y obliga a detener Apache en un panel antes de arrancarlo en el otro.
El escenario donde el atajo se rompe
El caso límite no es tener dos versiones de PHP instaladas: es necesitar que ambas respondan simultáneamente en el mismo Apache, bajo distintos VirtualHosts. Ahí es donde la solución «obvia» —editar la línea LoadModule php_module y reiniciar— deja de servir. Cada reinicio interrumpe la otra aplicación, y si estás probando un webhook o una integración con un servicio externo, el ciclo de parar y arrancar introduce ruido que dificulta aislar fallos.
En ese punto, la configuración de Apache con múltiples versiones de PHP pasa por FastCGI o PHP-FPM. La idea es que Apache no cargue el módulo PHP como módulo interno, sino que delegue en procesos independientes: uno por versión. Cada VirtualHost apunta a un socket distinto y el servidor web resuelve la versión por dominio o por puerto local.
Cómo se traduce en XAMPP
XAMPP trae Apache con mod_fcgid disponible en algunas distribuciones, y también puedes añadir mod_proxy_fcgi. La vía más limpia en Windows es usar PHP-FPM, aunque XAMPP no lo activa por defecto: hay que descargar el binario de PHP correspondiente (no el que viene integrado) y lanzarlo como servicio en un puerto propio. Con dos versiones, tendrías dos procesos escuchando en puertos distintos.
Un ejemplo de bloque funcional para el VirtualHost del proyecto legacy:
<VirtualHost *:80> ServerName legacy.local DocumentRoot «C:/xampp/htdocs/legacy» <FilesMatch .php$> SetHandler «proxy:fcgi://127.0.0.1:9000» </FilesMatch> </VirtualHost>Y en el otro VirtualHost, el puerto 9001. La configuración de XAMPP con distintas versiones de PHP queda así separada por proyecto, sin reiniciar Apache cada vez que cambias de contexto. El coste: gestionar dos procesos FPM a mano o con un script de arranque.
Limitaciones que conviene asumir
Esto no funciona igual de bien en todos los entornos. En Windows, PHP-FPM no es el modo natural de XAMPP y requiere pasos extra; en macOS y Linux es más directo, pero también más propenso a conflictos de permisos en los sockets. Tampoco resuelve el problema de las extensiones: si el legacy necesita una extensión que ya no compila en PHP 8, tendrás que mantenerla compilada para 7.4 y configurarla en su propio php.ini, porque FPM lee su archivo de configuración desde la ruta que le indiques al arrancar.
Otro límite real: las herramientas que dependen de la ruta del ejecutable PHP (Composer, PHPUnit, Xdebug) no saben qué versión usar por sí solas. Tendrás que invocarlas con la ruta completa o gestionar alias por consola. Esto no es un fallo de XAMPP: es la consecuencia de tener varias versiones conviviendo.
Alternativas que no siempre se consideran
Si el objetivo es solo alternar versiones para pruebas puntuales, un contenedor Docker con la imagen oficial de PHP por proyecto suele ser menos frágil que pelear con módulos de Apache. La configuración multi-versión dentro de XAMPP tiene sentido cuando el resto del stack (MySQL, phpMyAdmin, rutas) ya está montado y migrar implicaría rehacer el entorno del equipo.
Para equipos pequeños, otra opción es mantener una sola versión activa y cambiar el VirtualHost antes de cada sesión de trabajo, aceptando el reinicio. No es elegante, pero es honesto: no todas las configuraciones multi-PHP en XAMPP aportan tanto como prometen si el uso real es esporádico.
Qué comprobar antes de complicarte
Antes de montar FPM, verifica si tus proyectos realmente necesitan coexistir o si basta con cambiar la versión en el panel de control. La documentación de Apache sobre mod_proxy_fcgi y la de PHP sobre FPM son las fuentes que deberías consultar; no hay una receta única que cubra todas las combinaciones de sistema operativo y extensiones.
La configuración de múltiples versiones de PHP en XAMPP es viable y resuelve un escenario límite concreto, pero no es un botón mágico. Si tu caso es el del legacy y el proyecto moderno conviviendo, merece la pena; si solo quieres probar una versión nueva un rato, el atajo de siempre sigue siendo suficiente.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
