Selector de PHP en el alojamiento compartido: cómo ejecutar versiones de PHP en paralelo de forma segura

Qué controla un selector PHP

A Selector de PHP Es una interfaz de administración para entornos de ejecución de PHP que proporciona el administrador del servidor. A través de ella, dependiendo de la configuración del alojamiento, puedes seleccionar una rama de PHP y las extensiones u opciones correspondientes. La interfaz no instala automáticamente todas las versiones deseadas ni garantiza que cada selección se aplique por separado a cada dominio.

Para la planificación hay tres niveles importantes: en el servidor pueden existir varias versiones instalado ; sin embargo, en el plan de tarifas, el proveedor solo puede habilitar una parte de ellas para su selección. Además, la versión que realmente se ejecuta en una solicitud concreta depende de la configuración del dominio, del servidor web y del gestor PHP correspondiente. Una entrada visible en el menú por sí sola no responde a esta última pregunta.

CloudLinux ofrece entornos de ejecución alternativos como PHP antiguo Listo. Además, existe el entorno PHP nativo del servidor o del panel de control. En este contexto, «nativo» no hace referencia a un número de versión concreto: el entorno del servidor en cuestión es el que determina qué versión de PHP y qué configuración se utilizan. Por lo tanto, al cambiar a «nativo», una aplicación puede encontrarse con requisitos diferentes a los que tendría si se seleccionara una versión antigua de PHP.

Si necesitas una versión concreta de PHP para tu alojamiento web, comprueba primero los requisitos de la aplicación y, a continuación, consulta si está realmente disponible en el plan. Aclara también si se pueden modificar las extensiones y configuraciones necesarias. Las funciones documentadas de CloudLinux describen las posibilidades del software, no el equipamiento automático de un paquete de alojamiento concreto.

Cuentas, dominios y aislamiento

Imagina una página web actual y una aplicación empresarial más antigua que requieran ramas de PHP diferentes. Si se encuentran en cuentas de alojamiento separadas, pueden utilizar versiones diferentes, siempre que ambas cuentas dispongan de su propio selector y el proveedor autorice las ramas necesarias. Se trata de una posibilidad de funcionamiento en paralelo en el mismo servidor, pero no es una garantía para todos los planes de tarifa.

La situación es diferente cuando se trata de dos dominios dentro de la misma cuenta. CloudLinux describe una selección de selector que se aplica a todos los dominios de un usuario gestionados por dicho selector. Por lo tanto, si cambias la versión allí, debes tener en cuenta que ello afectará a ambas aplicaciones; la mera existencia del selector no implica una selección independiente de dominios.

El Ámbito de aplicación Por lo tanto, hay que aclararlo antes de realizar cualquier cambio. Si el proveedor no admite un control adecuado por dominio, una solución podría ser utilizar cuentas independientes. Para ello, hay que trasladar las aplicaciones como corresponda y comprobar las condiciones de cada tarifa. Un segundo dominio o un directorio adicional por sí solos no bastan para permitir una elección independiente de la versión.

CageFS sirve, en el entorno multiusuario de CloudLinux, para delimitar los entornos de los usuarios. Estos Aislamiento Hay que distinguirlo de la cuestión de qué versión de PHP se puede configurar para un dominio. Además, el aislamiento adicional de un sitio web dentro de una misma cuenta no demuestra por sí solo una selección independiente del selector; en el artículo sobre... se explica con más detalle este concepto. CageFS por sitio en el alojamiento compartido.

CloudLinux también documenta una configuración especial de Selector sin CageFS activado para un servidor con una sola cuenta de usuario. Esto no implica que se recomiende desactivar CageFS en un servidor de alojamiento compartido habitual. La arquitectura de seguridad y su configuración son responsabilidad del proveedor; como cliente, deberías informarte sobre la segregación que se ofrece y su alcance.

Selector y MultiPHP Manager

CloudLinux PHP Selector y cPanel MultiPHP Manager son herramientas diferentes. Selector gestiona las opciones de PHP proporcionadas como parte de su integración; MultiPHP Manager permite gestionar la configuración de PHP por dominio. Sin embargo, el hecho de que una de estas interfaces permita configurar ajustes por dominio no significa que estén disponibles en tu propio plan de tarifas ni que estén habilitados para todas las combinaciones.

En la documentación sobre la interacción con cPanel, CloudLinux indica, entre otras cosas, que para utilizar el selector se necesita el Configuración predeterminada del sistema en MultiPHP Manager y PHP-FPM desactivado para el dominio en cuestión. Estos requisitos describen una integración concreta, no una guía general paso a paso. La configuración que haya establecido el proveedor de alojamiento para el handler y las interfaces determina qué ajuste es el que se aplica.

Si ambas interfaces están visibles, no debes determinar sus funciones probando en una página web en producción. De lo contrario, una configuración relacionada con el dominio en MultiPHP Manager y una selección en el selector pueden generar expectativas que no se ajusten al handler que se utiliza realmente. Pide al proveedor que te explique qué herramienta es la adecuada para el dominio en cuestión y qué cambios afectan a otros dominios.

Para tomar una decisión concreta, conviene plantearse las siguientes preguntas: ¿Qué interfaz está disponible en el plan? ¿La selección se aplica por cuenta o por dominio, y qué versiones de PHP y extensiones están permitidas? Pregunta también si están disponibles SSH y las tareas programadas, y qué intérprete las ejecuta. De este modo, se pueden planificar por separado la aplicación web y las tareas en segundo plano, en lugar de deducir todas las vías de ejecución a partir de lo que se muestra en el panel de control.

Por último, aclara si se dispone de un entorno de pruebas aislado y de una copia de seguridad, y quién puede restaurar la configuración anterior en caso de error. Solo cuando se conozcan las responsabilidades relativas a la interfaz y el área afectada se podrá preparar un cambio con un riesgo controlable. Las opciones de menú no confirmadas o una solución de configuración supuestamente universal no sirven de ayuda en este sentido.

Seleccionar el ámbito de aplicación adecuado

Antes de cambiar la versión de PHP en el alojamiento, comprueba el Ámbito de aplicación la configuración disponible. Lo decisivo no es solo el número de dominios que gestionas, sino cuáles de ellos utilizan el mismo usuario y la misma selección de selector. La tabla traduce los requisitos habituales en preguntas que puedes aclarar con tu proveedor.

El CloudLinux Selector aplica su selección, tal y como se documenta, a los dominios de un usuario que gestiona. Si dos aplicaciones de la misma cuenta necesitan versiones diferentes, puede ser útil separarlas en cuentas distintas, siempre que el plan y las versiones disponibles lo permitan. Debes consultar con el proveedor los costes adicionales y las condiciones.

Otra posibilidad es una gestión específica por dominio que cuente con soporte explícito, por ejemplo, a través del MultiPHP Manager de cPanel. No se puede dar por sentado de forma generalizada si está disponible en un plan concreto ni cómo interactúa con un selector. También se puede realizar un cambio a través de .htaccess No deberías dar por sentado que sea un sustituto fiable.

Además, la separación de las versiones no resuelve todas las dependencias: una aplicación puede requerir determinados módulos o configuraciones, mientras que una tarea programada utiliza su propio intérprete. Anota estos requisitos por separado para que, al consultar al proveedor, no te limites a pedir un número de versión, sino que solicites la ruta de ejecución completa.

Comprobar la versión de PHP y la compatibilidad

Elige una rama de PHP que sea compatible con tu aplicación concreta y para la que haya parches de seguridad disponibles. Para ello, comprueba los requisitos de la versión del CMS o de la tienda online que utilices, así como de los plugins, temas, bibliotecas y tu propio código. El mero hecho de disponer de una versión actual de PHP no garantiza automáticamente que una aplicación antigua e incompatible funcione.

La tabla oficial de PHP distingue entre asistencia activa y una fase posterior con correcciones de seguridad. Según un estudio del 4 de noviembre de 2026, PHP 8.2 y 8.3 solo recibirán correcciones de seguridad; PHP 8.4 y 8.5 se encuentran en fase de soporte activo. El soporte oficial de seguridad para PHP 8.2 finaliza el 31 de diciembre de 2026. Comprueba de nuevo el estado antes de tomar una decisión, ya que esta clasificación puede cambiar con el tiempo.

La indicación de una versión en el selector responde a una pregunta diferente a la de la tabla de soporte: muestra una selección disponible en tu entorno, pero no garantiza ni el soporte oficial ni la compatibilidad de tu aplicación. Por el contrario, el hecho de que una rama cuente con soporte oficial no implica que tu plan de alojamiento la ofrezca.

Es posible que un proveedor ofrezca su propio servicio de soporte ampliado para paquetes más antiguos. Para ello, aclara por escrito qué paquetes y parches de seguridad incluye, cuál es su duración y cómo se proporcionan las actualizaciones. Esto Asistencia técnica del proveedor No debe equipararse al soporte oficial del proyecto PHP ni sustituye a un plan de migración para la aplicación.

Si vas a cambiar a una rama más reciente, comprueba también los pasos de migración que te hayas saltado y las tareas en segundo plano. El artículo sobre PHP 8.5 en el alojamiento web y para comprobar la compatibilidad explica qué dependencias y procesos pueden ser relevantes en este cambio de versión concreto.

Preparar la transición de forma controlada

Empieza por hacer un balance: ¿de qué interfaz dispones, qué dominios gestiona y qué versiones de PHP están habilitadas para tu cuenta? Anota las opciones disponibles hasta ahora y, en caso de dudas, pregunta cuál es el ámbito de aplicación real. De este modo, evitarás migrar lo que crees que es un único sitio web, cuando en realidad hay otros dominios afectados.

Supongamos que una aplicación actual y otra más antigua se ejecutan simultáneamente. Comprueba primero si sus requisitos son compatibles con una versión de destino común. Si no es así, puede resultar útil realizar una selección propia en cuentas separadas; solo se puede considerar una alternativa basada en el dominio si el proveedor la admite para tu configuración.

Antes de realizar cambios en el entorno de producción, comprueba si hay una versión actualizada Copia de seguridad de los archivos y la base de datos, y que se haya aclarado su recuperación. Es útil disponer de un entorno de pruebas aislado, siempre que puedas proporcionarlo: allí podrás comprobar la versión de destino sin poner en riesgo innecesariamente a los visitantes ni los datos de producción. Depende del proveedor aclarar si el plan ofrece un entorno de staging o copias de seguridad.

Además de la versión actual y la deseada de PHP, documenta también las extensiones necesarias y las opciones relevantes. Compara estos datos con los requisitos de la aplicación y con la configuración autorizada en el plan. CloudLinux Manager permite establecer configuraciones administrativas para versiones y extensiones; esto no significa que los clientes puedan modificar por sí mismos todas las opciones.

En el entorno aislado, no solo comprueba la página de inicio, sino también los inicios de sesión, los formularios, las importaciones y otros procesos importantes para tu proyecto. Comprueba por separado las tareas programadas, ya que su ejecución no se confirma únicamente con la visualización de la página web. Anota cualquier anomalía y soluciona los problemas de compatibilidad antes de la migración a producción.

Por último, coloca un Viaje de vuelta Ten en cuenta lo siguiente: ¿Quién puede volver a seleccionar la versión anterior y qué ajustes hay que comprobar después? Planifica el cambio en un momento adecuado y supervisa posteriormente las aplicaciones afectadas. El simple hecho de volver a la versión anterior no garantiza que todas las ampliaciones y opciones se restablezcan tal y como estaban antes.

Comprobar la web, la CLI y las tareas programadas

Un sitio web y sus tareas en segundo plano no tienen por qué utilizar el mismo intérprete de PHP. Las solicitudes HTTP son procesadas por un intérprete de tiempo de ejecución determinado por el servidor web y su controlador; por el contrario, una llamada desde la línea de comandos inicia el intérprete que encuentra el entorno correspondiente. CloudLinux distingue entre las rutas nativas para los intérpretes web y de la CLI. Por lo tanto, la información que aparece en el PHP Selector por sí sola no responde a todas las preguntas sobre la ejecución real.

Si SSH está disponible en tu tarifa, puedes ejecutar el siguiente comando de lectura en una sesión de terminal. Este comando muestra la versión del Intérpretes de CLI, que se encuentra precisamente para esta llamada. Para la comprobación no es necesario realizar ningún cambio en los archivos ni en la configuración.

php -v

El resultado no indica ni la versión de PHP de una solicitud HTTP ni la de una tarea cron ejecutada de otra forma. Una tarea programada puede utilizar una ruta de intérprete específica u otro entorno. Por lo tanto, comprueba la llamada almacenada y el entorno de ejecución de la tarea concreta, en lugar de extrapolar a ella la salida de tu sesión interactiva.

Para la comprobación web, utiliza un método seguro y compatible con el proveedor y, si es necesario, pregunta por el responsable correspondiente. Un script de diagnóstico accesible públicamente con información detallada sobre el entorno no es una solución estándar adecuada. Comprueba también las tareas programadas a través de un método compatible y, a continuación, verifica si, por ejemplo, una importación o un trabajo de envío funciona realmente según lo previsto.

Anota, para cada vía de ejecución relevante, qué versión se espera y cómo se ha comprobado. Si el panel, la salida de SSH y el comportamiento de un trabajo ofrecen indicaciones diferentes, aclara primero con el proveedor la responsabilidad del entorno de ejecución correspondiente. De este modo, evitarás modificar un ajuste en el lugar equivocado.

Localizar el fallo tras el cambio

Si la página de inicio se carga tras el cambio, pero un formulario o una importación no funcionan, significa que la migración aún no se ha comprobado lo suficiente. Repite el proceso en cuestión y anota la hora, la función y el mensaje de error observado. Compara estos datos con los registros de la aplicación y del servidor disponibles, siempre que tu plan de servicio te permita acceder a ellos; los datos confidenciales de los registros no deben figurar en archivos de acceso público.

A continuación, comprueba la Compatibilidad la aplicación en cuestión y sus extensiones con la rama de PHP seleccionada. Por ejemplo, un formulario puede depender de un plugin que ni siquiera se ejecuta en la página de inicio. En una importación, también son relevantes sus dependencias y la ruta de ejecución real: una tarea en segundo plano puede utilizar un entorno de ejecución diferente al del sitio web.

Antes de realizar el cambio, compara las extensiones de PHP disponibles y activadas para la versión de destino, así como las opciones necesarias, con tu documentación. La selección de una rama de PHP no confirma automáticamente que todos los módulos y ajustes necesarios sean los adecuados. Los cambios que puedas realizar por tu cuenta dependen de la autorización del administrador.

Comprueba además si el dominio en cuestión es realmente el esperado manipulador y se utilice el tiempo de ejecución deseado. Si hay varias interfaces de administración, aclara sus competencias con el proveedor antes de modificar otros ajustes. No es necesario que una visualización en el selector explique qué ruta de ejecución procesa una solicitud concreta.

Advertencia: No dirijas las rutas de configuración de forma generalizada a través de PHPRC o PHP_INI_SCAN_DIR . CloudLinux advierte de que este tipo de cambios en las rutas de configuración de PHP pueden afectar al selector. Si consideras necesario utilizar una ruta específica, consúltalo primero con el proveedor.

Si el error no se puede resolver rápidamente, utiliza el procedimiento de reversión previamente establecido para volver a la versión anterior. A continuación, comprueba de nuevo la versión actualmente vigente, las extensiones y las opciones, así como las funciones afectadas. No des por sentado que al volver a la versión anterior se restablecerán automáticamente todos los ajustes anteriores; documenta las diferencias para el próximo intento.

Planificar el funcionamiento de los sistemas heredados y la migración

Para un funcionamiento continuado, lo primero que hay que tener en cuenta es la Ámbito de aplicación: Si una configuración común es válida para los dominios de un usuario gestionados por Selector, este puede ser una interfaz adecuada. Sin embargo, si dos aplicaciones necesitan versiones independientes, comprueba si el proveedor ofrece una gestión por dominios o cuentas de alojamiento separadas. La opción documentada de Selector por sí sola no garantiza una configuración independiente para cada dominio dentro de la misma cuenta.

Las cuentas independientes pueden desacoplar organizativamente las decisiones sobre versiones, siempre que se ofrezcan las ramas necesarias en cada caso. Una solución específica para cada dominio también puede ser adecuada, siempre que el proveedor la ofrezca y se haya aclarado su compatibilidad con otras herramientas de PHP. Antes de realizar el cambio, infórmate sobre los costes, las condiciones tarifarias y las responsabilidades; la viabilidad técnica no implica el compromiso de ofrecer un paquete concreto.

Una aplicación antigua no debería permanecer de forma permanente en una rama antigua solo porque esta se pueda seleccionar en el menú. Planifica la Migración una combinación compatible de aplicación, dependencias y PHP: identifica las actualizaciones pendientes, las extensiones sustituibles y las adaptaciones necesarias. Establece una fecha para la próxima comprobación de compatibilidad y una fecha límite para la sustitución.

Comprueba periódicamente el estado oficial de soporte de la rama de PHP que utilices y, al mismo tiempo, presta atención a los mensajes de error y a los procesos operativos importantes. El hecho de que se ofrezca una rama más antigua no garantiza que siga existiendo soporte oficial. La tabla de soporte del proyecto PHP debe revisarse de nuevo antes de tomar cualquier decisión a largo plazo, ya que el estado puede cambiar con el tiempo.

Si un proveedor ofrece soporte ampliado, pídele que te facilite pruebas de los paquetes afectados, el tipo de correcciones de seguridad y la duración del servicio. Este soporte debe evaluarse independientemente del soporte oficial de PHP y no sustituye ni a las actualizaciones de la aplicación ni a la migración prevista. Anota también quién se encargará de gestionar los cambios y las incidencias durante el periodo de transición.