Sélecteur PHP en hébergement mutualisé : utiliser plusieurs versions de PHP en parallèle en toute sécurité

Ce qu'un sélecteur PHP contrôle

A Sélecteur PHP Il s'agit d'une interface d'administration pour les environnements d'exécution PHP mise à disposition par l'hébergeur. Elle te permet, en fonction de la configuration de l'hébergement, de sélectionner une branche PHP ainsi que les extensions ou options associées. L'interface n'installe pas automatiquement chaque version souhaitée et ne garantit pas non plus que chaque sélection s'applique séparément à chaque domaine.

Trois niveaux sont importants pour la planification : sur le serveur, plusieurs versions peuvent installé ; toutefois, dans l'offre tarifaire, le fournisseur ne peut mettre à disposition qu'une partie de celles-ci. La version qui sera effectivement exécutée pour une requête donnée dépend en outre de la configuration du domaine, du serveur web et du gestionnaire PHP concerné. Une entrée de menu visible ne suffit pas à elle seule à répondre à cette dernière question.

CloudLinux propose des environnements d'exécution alternatifs tels que Ancien PHP prêt. Il existe par ailleurs l'environnement PHP natif du serveur ou du panneau de contrôle. Le terme « natif » ne fait ici pas référence à un numéro de version fixe : c'est l'environnement serveur concerné qui détermine la version de PHP et la configuration utilisées. Une application peut donc, lors du passage à l'environnement natif, se retrouver confrontée à des conditions différentes de celles qui prévalent lorsqu'on opte pour une version antérieure de PHP.

Si vous avez besoin d'une version spécifique de PHP pour votre hébergement, vérifiez d'abord la configuration requise par l'application, puis renseignez-vous sur la disponibilité effective de cette version dans la formule choisie. Vérifiez également si les extensions et les paramètres nécessaires peuvent être modifiés. Les fonctionnalités documentées de CloudLinux décrivent les possibilités offertes par le logiciel et ne correspondent pas automatiquement à l'équipement d'un forfait d'hébergement spécifique.

Comptes, domaines et isolation

Imaginez un site web récent et une application métier plus ancienne qui nécessitent des branches PHP différentes. Si elles se trouvent sur des comptes d'hébergement distincts, elles peuvent utiliser des versions différentes, à condition que les deux comptes disposent de leur propre sélection de branches et que l'hébergeur autorise les branches requises. Il s'agit là d'une possibilité d'exploitation en parallèle sur le même serveur, mais cela n'est pas garanti pour toutes les formules.

La situation est différente lorsqu'il s'agit de deux domaines au sein d'un même compte. CloudLinux décrit une sélection de « Selector » qui s'applique à tous les domaines d'un utilisateur gérés par ce « Selector ». Si vous modifiez la version à cet endroit, vous devez donc vous attendre à des répercussions sur les deux applications ; la simple existence du « Selector » n'implique pas une sélection indépendante des domaines.

Le Champ d'application Il convient donc de clarifier ce point avant toute modification. Si le fournisseur ne prend pas en charge une gestion adaptée par domaine, la création de comptes distincts peut constituer une solution. Pour cela, les applications doivent être transférées en conséquence et les conditions tarifaires correspondantes doivent être vérifiées. Un deuxième domaine ou un répertoire supplémentaire ne suffit pas à lui seul à permettre un choix de version indépendant.

Dans l'environnement multi-utilisateurs de CloudLinux, CageFS sert à isoler les environnements des utilisateurs. Ceux-ci Isolation Il convient de distinguer cette question de celle de la version de PHP pouvant être configurée pour un domaine. De même, l'isolation supplémentaire des sites web au sein d'un même compte ne prouve pas en soi l'existence d'un choix indépendant du sélecteur ; pour en savoir plus sur ce concept, consultez l'article consacré à CageFS par site dans l'hébergement mutualisé.

CloudLinux documente également une configuration spéciale de Selector sans CageFS activé pour un serveur ne comportant qu'un seul compte utilisateur. Cela ne signifie pas pour autant qu'il soit recommandé de désactiver CageFS sur un serveur d'hébergement mutualisé classique. L'architecture de sécurité et sa mise en place relèvent de la responsabilité de l'hébergeur ; en tant que client, tu devrais te renseigner sur la séparation proposée et son étendue.

Selector et MultiPHP Manager

CloudLinux PHP Selector et cPanel MultiPHP Manager sont des outils distincts. Selector gère les versions de PHP mises à disposition dans le cadre de son intégration ; MultiPHP Manager permet de gérer les paramètres PHP au niveau de chaque domaine. Cependant, le fait que l'une de ces interfaces prenne en charge les paramètres spécifiques à un domaine ne signifie pas pour autant qu'ils soient disponibles dans votre forfait ou autorisés pour toutes les combinaisons.

Dans la documentation relative à l'interaction avec cPanel, CloudLinux mentionne notamment, pour l'utilisation du sélecteur, les éléments suivants : paramètre par défaut dans MultiPHP Manager et PHP-FPM désactivé pour le domaine concerné. Ces conditions préalables décrivent une intégration spécifique et ne constituent pas un guide pas à pas universel. C'est la manière dont l'hébergeur a configuré les gestionnaires et les interfaces qui détermine quel paramètre est effectif.

Lorsque les deux interfaces sont visibles, vous ne devez pas déterminer leurs responsabilités en procédant par essais et erreurs sur un site web en production. Un paramètre lié au domaine dans MultiPHP Manager et une sélection dans le sélecteur risqueraient sinon de créer des attentes qui ne correspondent pas au gestionnaire réellement utilisé. Demandez à votre hébergeur de vous expliquer quel outil s'applique au domaine concerné et quelles modifications ont une incidence sur d'autres domaines.

Pour prendre une décision concrète, posez-vous les questions suivantes : quelle interface est disponible dans la formule ? Le choix s'applique-t-il par compte ou par domaine, et quelles versions de PHP ainsi que quelles extensions sont autorisées ? Demandez également si SSH et les tâches planifiées sont disponibles, et quel interpréteur les exécute. Cela permet de planifier séparément l'application web et les tâches en arrière-plan, plutôt que de se baser sur un panneau de contrôle pour déduire tous les chemins d'exécution.

Vérifiez enfin si un environnement de test isolé et une sauvegarde sont disponibles, et qui est en mesure de restaurer la configuration actuelle en cas de problème. Ce n'est qu'une fois que les responsabilités relatives à l'interface et au domaine concerné sont clairement définies qu'il est possible de préparer une migration avec un risque maîtrisable. Des options de menu non confirmées ou une solution de configuration prétendument universelle n’apportent aucune aide en la matière.

Choisir le champ d'application approprié

Avant de modifier la version de PHP sur votre hébergement, vérifiez que Champ d'application parmi les options disponibles. Ce qui compte, ce n’est pas seulement le nombre de domaines que vous gérez, mais aussi ceux qui utilisent le même utilisateur et la même sélection de sélecteurs. Le tableau traduit les besoins courants en questions que vous pouvez poser à votre hébergeur.

Le CloudLinux Selector applique ses choix, de manière documentée, aux domaines d'un utilisateur qu'il gère. Si deux applications d'un même compte nécessitent des versions différentes, une séparation entre les comptes peut s'avérer utile, à condition que le forfait et les versions disponibles le permettent. Tu dois te renseigner auprès du fournisseur pour connaître les coûts supplémentaires et les conditions applicables.

Une autre possibilité consiste à utiliser une gestion par domaine explicitement prise en charge, par exemple via le MultiPHP Manager de cPanel. Il n'est pas possible de généraliser quant à sa disponibilité dans une offre spécifique ni à son interaction avec un sélecteur. Une modification via .htaccess tu ne devrais pas compter dessus comme solution de remplacement fiable.

La séparation des versions ne résout d'ailleurs pas toutes les dépendances : une application peut exiger certains modules ou paramètres, tandis qu'une tâche planifiée utilise son propre interpréteur. Note bien ces exigences séparément afin de ne pas te contenter de demander un numéro de version au fournisseur, mais de lui demander le chemin d'exécution complet.

Vérifier la version de PHP et l'assistance

Choisissez une branche PHP prise en charge par votre application spécifique et pour laquelle des correctifs de sécurité sont disponibles. Pour cela, vérifie les exigences de la version du CMS ou de la boutique en ligne utilisée, ainsi que celles des plugins, des thèmes, des bibliothèques et de ton propre code. Une version PHP récente ne suffit pas à elle seule à rendre automatiquement fonctionnelle une application plus ancienne et incompatible.

Le tableau officiel de PHP fait la distinction entre assistance active suivie d'une phase de correctifs de sécurité. D'après une étude datée du 4 novembre 2026, PHP 8.2 et 8.3 ne bénéficient plus que de correctifs de sécurité ; PHP 8.4 et 8.5 sont quant à eux en phase de support actif. Pour PHP 8.2, le support de sécurité officiel prendra fin le 31 décembre 2026. Vérifie à nouveau le statut avant de prendre une décision, car cette classification est susceptible d'évoluer avec le temps.

L'affichage d'une version dans le sélecteur répond à une question différente de celle posée par le tableau de prise en charge : il présente une sélection disponible dans votre environnement, mais ne garantit ni la prise en charge officielle ni la compatibilité de votre application. À l'inverse, le fait qu'une branche soit officiellement prise en charge ne signifie pas pour autant que votre formule d'hébergement la propose.

Un fournisseur peut éventuellement proposer son propre support prolongé pour les paquets plus anciens. Dans ce cas, demande-lui par écrit quels paquets et correctifs de sécurité sont concernés, quelle est la durée de ce support et comment les mises à jour sont fournies. Ceci Assistance fournisseur ne doit pas être assimilé au support officiel du projet PHP et ne remplace en aucun cas un plan de migration pour l'application.

Si vous vous apprêtez à passer à une branche plus récente, vérifiez également les étapes de migration que vous avez sautées et les tâches en arrière-plan. L'article sur PHP 8.5 dans l'hébergement et pour les tests de compatibilité explique quelles dépendances et quels processus peuvent entrer en jeu lors de ce changement de version spécifique.

Préparer la transition de manière contrôlée

Commence par faire le point : de quelle interface disposes-tu, quels domaines gère-t-elle et quelles versions de PHP sont autorisées pour ton compte ? Note les informations dont tu disposes et, en cas de doute, renseigne-toi sur le champ d'application réel. Tu éviteras ainsi de migrer un site web que tu penses être unique, alors que d'autres domaines sont également concernés.

Supposons qu'une application récente et une application plus ancienne fonctionnent en parallèle. Vérifie d'abord si leurs exigences sont compatibles avec une version cible commune. Si ce n'est pas le cas, il peut être utile de faire des choix distincts dans des comptes séparés ; une alternative liée au domaine n'est envisageable que si le fournisseur la prend en charge pour ta configuration.

Avant d'effectuer des modifications en production, vérifie si une version à jour Sauvegarde des fichiers et de la base de données est disponible et que leur restauration est bien définie. Un environnement de test isolé est utile, si vous pouvez en disposer : il vous permet de tester la version cible sans exposer inutilement les visiteurs ou les données de production à des risques. Il appartient au fournisseur de préciser si le forfait inclut un environnement de staging ou des sauvegardes.

Outre la version PHP actuelle et celle souhaitée, documentez également les extensions requises et les options pertinentes. Comparez ces informations avec les exigences de l'application et les paramètres autorisés dans la formule. CloudLinux Manager permet de définir des règles administratives concernant les versions et les extensions ; cela ne signifie pas pour autant que chaque option puisse être modifiée par les clients eux-mêmes.

Dans l'environnement isolé, teste non seulement la page d'accueil, mais aussi les connexions, les formulaires, les importations et d'autres processus importants pour ton projet. Vérifiez séparément les tâches planifiées, car leur exécution ne se limite pas à l'affichage du site web. Notez les anomalies et résolvez les problèmes de compatibilité avant la mise en production.

Pour finir, place un Retour À noter : qui est autorisé à revenir à la version précédente, et quels paramètres doivent être vérifiés par la suite ? Planifiez la migration à un moment opportun et surveillez ensuite les applications concernées. Le simple fait de revenir à la version précédente ne garantit pas que toutes les extensions et options soient rétablies comme auparavant.

Vérifier le Web, l'interface en ligne de commande (CLI) et les tâches Cron

Un site web et ses tâches en arrière-plan ne doivent pas nécessairement utiliser le même interpréteur PHP. Les requêtes HTTP sont traitées par un environnement d'exécution déterminé par le serveur web et son gestionnaire ; en revanche, un appel en ligne de commande lance l'interpréteur que l'environnement concerné parvient à trouver. CloudLinux distingue les chemins d'accès natifs pour les interpréteurs web et CLI. L'affichage dans le PHP Selector ne répond donc pas à lui seul à toutes les questions concernant l'exécution effective.

Si SSH est disponible dans votre forfait, vous pouvez exécuter la commande suivante en lecture seule dans une session de terminal. Elle affiche la version du Interprètes CLI, qui est associé à cet appel précis. Aucune modification des fichiers ou des paramètres n'est nécessaire pour le test.

php -v

Le résultat n'indique ni la version PHP d'une requête HTTP, ni celle d'une tâche cron lancée par un autre moyen. Une tâche planifiée peut utiliser un chemin d'interpréteur explicite ou un autre environnement. Vérifie donc l'appel enregistré et l'environnement d'exécution de la tâche en question, plutôt que de te baser sur la sortie de ta session interactive.

Pour le test Web, utilisez une méthode sécurisée et prise en charge par le fournisseur, et demandez, le cas échéant, quel est le gestionnaire compétent. Un script de diagnostic accessible au public et contenant des informations détaillées sur l'environnement ne constitue pas une solution standard appropriée. Vérifiez également les tâches planifiées via une méthode prise en charge, puis contrôlez si, par exemple, une importation ou une tâche d'envoi fonctionne effectivement comme prévu.

Pour chaque voie d'exécution concernée, note la version attendue et la manière dont elle a été vérifiée. Si le panneau de contrôle, la sortie SSH et le comportement d'une tâche fournissent des indications divergentes, clarifie d'abord avec le fournisseur la responsabilité de l'environnement d'exécution concerné. Tu éviteras ainsi de modifier un paramètre au mauvais endroit.

Identifier la cause d'une erreur après un changement

Si la page d'accueil se charge après la migration, mais qu'un formulaire ou une importation échoue, cela signifie que la migration n'a pas encore été suffisamment testée. Répétez le processus concerné et notez l'heure, la fonction et le message d'erreur observé. Compare ces informations avec les journaux d'application et de serveur disponibles, dans la mesure où ton forfait t'y donne accès ; les données sensibles des journaux ne doivent pas figurer dans des fichiers accessibles au public.

Vérifie ensuite la Compatibilité de l'application concernée et de ses extensions avec la branche PHP sélectionnée. Un formulaire peut, par exemple, dépendre d'un plugin qui n'est pas exécuté sur la page d'accueil. Lors d'une importation, ses dépendances et le chemin d'exécution réel sont également pris en compte : une tâche en arrière-plan peut utiliser un environnement d'exécution différent de celui du site web.

Avant d'effectuer la mise à jour, comparez les extensions PHP disponibles et activées pour la version cible, ainsi que les options requises, avec votre documentation. Le choix d'une branche PHP ne garantit pas automatiquement que tous les modules et paramètres requis soient adaptés. Les modifications que vous êtes autorisé à effectuer dépendent de l'autorisation accordée par l'administrateur.

Vérifie également si le domaine concerné correspond bien à celui attendu manipulateur et la durée d'exécution souhaitée est utilisée. S'il existe plusieurs interfaces d'administration, clarifie leurs responsabilités avec le fournisseur avant de modifier d'autres paramètres. Un affichage dans le Selector n'a pas besoin d'expliquer quel chemin d'exécution traite une requête spécifique.

Avertissement : Ne configurez pas les chemins d'accès de manière générale via PHPRC ou PHP_INI_SCAN_DIR . CloudLinux signale que de telles modifications des chemins de configuration PHP peuvent affecter le Selector. Si un chemin spécifique semble nécessaire, vérifiez-le d'abord auprès de votre hébergeur.

Si l'erreur ne peut pas être résolue rapidement, utilise la procédure de retour à la version précédente définie au préalable. Vérifie ensuite à nouveau la version effectivement en vigueur, les extensions et les options, ainsi que les fonctionnalités concernées. Ne compte pas sur le fait qu’une restauration automatique rétablisse tous les paramètres antérieurs ; note les écarts pour la prochaine tentative.

Planifier l'exploitation des systèmes existants et la migration

Pour un fonctionnement continu, c'est avant tout la quantité nécessaire qui est déterminante Champ d'application: Si une sélection commune convient aux domaines d'un utilisateur gérés par Selector, ce dernier peut constituer une interface adaptée. En revanche, si deux applications nécessitent des versions indépendantes, envisagez une gestion par domaine prise en charge par le fournisseur ou des comptes d'hébergement distincts. La sélection documentée de Selector ne garantit pas à elle seule un paramétrage indépendant pour chaque domaine au sein d'un même compte.

Des comptes distincts permettent de dissocier les décisions relatives aux versions sur le plan organisationnel, à condition que les branches nécessaires soient proposées dans chaque cas. Une solution spécifique au domaine peut également convenir si le fournisseur la propose et si son interopérabilité avec d’autres outils PHP est clarifiée. Avant toute migration, renseignez-vous sur les coûts, les conditions tarifaires et les responsabilités ; la faisabilité technique n’implique pas l’engagement à fournir une offre spécifique.

Une ancienne application ne devrait pas rester indéfiniment sur une ancienne branche simplement parce que celle-ci est sélectionnable dans le menu. Prévoyez la Migration pour une combinaison prise en charge d'application, de dépendances et de PHP : recensez les mises à jour manquantes, les extensions remplaçables et les adaptations nécessaires. Fixez une date pour le prochain contrôle de compatibilité et une date butoir pour le remplacement.

Vérifiez régulièrement le statut officiel de prise en charge de la branche PHP utilisée, tout en surveillant les messages d'erreur et les processus métier critiques. Le fait qu'une ancienne branche soit proposée ne garantit pas un support officiel continu. Il convient de consulter à nouveau le tableau de support du projet PHP avant toute décision à long terme, car le statut évolue avec le temps.

Si un fournisseur propose une assistance étendue, demande-lui de te fournir des preuves concernant les paquets concernés, la nature des correctifs de sécurité et la durée de cette assistance. Cette assistance doit être évaluée indépendamment de l'assistance officielle de PHP et ne remplace ni les mises à jour de l'application ni la migration prévue. Précisez également qui se chargera de traiter les modifications et les dysfonctionnements pendant la période de transition.