PHP Selector im Shared Hosting: PHP-Versionen sicher parallel betreiben

Was ein PHP Selector steuert

Ein PHP Selector ist eine Verwaltungsoberfläche für PHP-Laufzeitumgebungen, die der Serverbetreiber bereitstellt. Über sie kannst du, abhängig von der Hostingkonfiguration, einen PHP-Zweig und zugehörige Erweiterungen oder Optionen auswählen. Die Oberfläche installiert nicht automatisch jede gewünschte Version und garantiert auch nicht, dass jede Auswahl für einzelne Domains getrennt gilt.

Für die Planung sind drei Ebenen wichtig: Auf dem Server können mehrere Versionen installiert sein; im Tarif kann der Anbieter aber nur einen Teil davon zur Auswahl freigeben. Welche Version eine konkrete Anfrage tatsächlich ausführt, hängt darüber hinaus von der Konfiguration der Domain, des Webservers und des zuständigen PHP-Handlers ab. Ein sichtbarer Menüeintrag allein beantwortet diese letzte Frage nicht.

CloudLinux stellt alternative Laufzeiten als Alt-PHP bereit. Daneben gibt es die native PHP-Umgebung des Servers beziehungsweise Control Panels. Native bezeichnet dabei keine feste Versionsnummer: Welche PHP-Version und welche Konfiguration dahinterstehen, entscheidet die jeweilige Serverumgebung. Eine Anwendung kann deshalb bei einer Umstellung auf Native andere Voraussetzungen vorfinden als bei einer Alt-PHP-Auswahl.

Wenn du eine bestimmte PHP-Version für dein Hosting benötigst, prüfe zuerst die Anforderungen der Anwendung und frage anschließend nach der tatsächlichen Verfügbarkeit im Tarif. Kläre auch, ob benötigte Erweiterungen und Einstellungen bearbeitet werden können. Die dokumentierten CloudLinux-Funktionen beschreiben Möglichkeiten der Software, nicht automatisch die Ausstattung eines konkreten Hostingpakets.

Konten, Domains und Isolation

Stell dir eine aktuelle Website und eine ältere Geschäftsanwendung vor, die unterschiedliche PHP-Zweige benötigen. Liegen sie in getrennten Hostingkonten, können sie unterschiedliche Versionen nutzen, sofern beide Konten eine eigene Selector-Auswahl besitzen und der Anbieter die benötigten Zweige freigibt. Das ist ein möglicher Parallelbetrieb auf demselben Server, aber keine Zusage für jeden Tarif.

Anders sieht es bei zwei Domains innerhalb desselben Kontos aus. CloudLinux beschreibt eine Selector-Auswahl, die für alle vom Selector verwalteten Domains eines Benutzers gilt. Wenn du dort die Version änderst, musst du daher mit Auswirkungen auf beide Anwendungen rechnen; eine unabhängige Domain-Auswahl folgt aus der bloßen Existenz des Selectors nicht.

Der Geltungsbereich ist deshalb vor jeder Änderung zu klären. Falls der Anbieter keine geeignete domainweise Steuerung unterstützt, können getrennte Konten eine Lösung sein. Dafür müssen die Anwendungen entsprechend umgezogen und die jeweiligen Tarifbedingungen geprüft werden. Eine zweite Domain oder ein weiteres Verzeichnis allein schafft noch keine unabhängige Versionswahl.

CageFS dient im CloudLinux-Mehrbenutzerumfeld der Abgrenzung von Benutzerumgebungen. Diese Isolation ist von der Frage zu unterscheiden, welche PHP-Version für eine Domain eingestellt werden kann. Auch eine zusätzliche Website-Isolierung innerhalb eines Kontos beweist für sich genommen keine unabhängige Selector-Auswahl; mehr zum Konzept erläutert der Beitrag über Per-Site CageFS im Shared Hosting.

CloudLinux dokumentiert auch eine Selector-Sonderkonfiguration ohne aktiviertes CageFS für einen Server mit nur einem Benutzerkonto. Daraus folgt keine Empfehlung, CageFS auf einem gewöhnlichen Shared-Hosting-Server abzuschalten. Die Sicherheitsarchitektur und ihre Einrichtung liegen dort beim Betreiber; als Kunde solltest du die angebotene Trennung und ihren Umfang erfragen.

Selector und MultiPHP Manager

CloudLinux PHP Selector und cPanel MultiPHP Manager sind unterschiedliche Werkzeuge. Der Selector verwaltet bereitgestellte PHP-Auswahlen im Rahmen seiner Integration; der MultiPHP Manager kann PHP-Einstellungen domainbezogen verwalten. Dass eine dieser Oberflächen domainbezogene Einstellungen kennt, bedeutet aber nicht, dass sie im eigenen Tarif verfügbar oder für jede Kombination freigegeben ist.

Im dokumentierten cPanel-Zusammenspiel nennt CloudLinux für die Nutzung des Selectors unter anderem die Systemvorgabe im MultiPHP Manager und deaktiviertes PHP-FPM für die betreffende Domain. Diese Voraussetzungen beschreiben eine bestimmte Integration, keine allgemeingültige Klickanleitung. Wie der Hoster Handler und Oberflächen eingerichtet hat, entscheidet darüber, welche Einstellung wirksam ist.

Wenn beide Oberflächen sichtbar sind, solltest du ihre Zuständigkeiten nicht durch Ausprobieren an einer produktiven Website ermitteln. Eine domainbezogene Einstellung im MultiPHP Manager und eine Selector-Auswahl können sonst Erwartungen erzeugen, die nicht zum tatsächlich verwendeten Handler passen. Lass dir vom Anbieter erklären, welches Werkzeug für die betroffene Domain maßgeblich ist und welche Änderungen andere Domains berühren.

Für eine konkrete Entscheidung helfen Fragen: Welche Oberfläche steht im Tarif zur Verfügung? Gilt die Auswahl pro Konto oder pro Domain, und welche PHP-Versionen sowie Erweiterungen sind freigegeben? Frage außerdem, ob SSH und geplante Aufgaben verfügbar sind und welcher Interpreter sie ausführt. So lassen sich Webanwendung und Hintergrundaufgaben getrennt einplanen, statt aus einer Panelanzeige auf alle Ausführungswege zu schließen.

Kläre schließlich, ob eine abgeschirmte Testumgebung und eine Sicherung verfügbar sind und wer im Fehlerfall die bisherige Konfiguration wiederherstellen kann. Erst wenn die Zuständigkeit der Oberfläche und der betroffene Bereich bekannt sind, lässt sich ein Wechsel mit überschaubarem Risiko vorbereiten. Unbestätigte Menüpunkte oder eine vermeintlich universelle Konfigurationslösung helfen dabei nicht weiter.

Den passenden Geltungsbereich wählen

Bevor du eine PHP-Version im Hosting änderst, kläre den Geltungsbereich der verfügbaren Einstellung. Entscheidend ist nicht allein, wie viele Domains du betreibst, sondern welche davon denselben Benutzer und dieselbe Selector-Auswahl verwenden. Die Tabelle übersetzt typische Anforderungen in Fragen, die du mit deinem Anbieter klären kannst.

Der CloudLinux Selector wendet seine Auswahl dokumentiert auf die von ihm verwalteten Domains eines Benutzers an. Benötigen zwei Anwendungen im selben Konto unterschiedliche Versionen, kann eine Trennung auf Konten helfen, sofern der Tarif und die freigegebenen Versionen das zulassen. Zusätzliche Kosten und Bedingungen musst du beim Anbieter erfragen.

Eine andere Möglichkeit ist eine ausdrücklich unterstützte domainbezogene Verwaltung, etwa über den cPanel MultiPHP Manager. Ob sie im konkreten Tarif verfügbar ist und wie sie mit einem Selector zusammenspielt, ist keine allgemeingültige Annahme. Auch eine Änderung über .htaccess solltest du nicht als verlässlichen Ersatz voraussetzen.

Die Trennung der Versionen löst außerdem nicht jede Abhängigkeit: Eine Anwendung kann bestimmte Module oder Einstellungen verlangen, während ein geplanter Auftrag einen eigenen Interpreter nutzt. Halte diese Anforderungen getrennt fest, damit du beim Anbieter nicht nur nach einer Versionsnummer, sondern nach dem vollständigen Ausführungsweg fragst.

PHP-Version und Support prüfen

Wähle einen PHP-Zweig, den deine konkrete Anwendung unterstützt und für den Sicherheitskorrekturen verfügbar sind. Prüfe dafür die Anforderungen der eingesetzten CMS- oder Shop-Version sowie von Plugins, Themes, Bibliotheken und eigenem Code. Eine aktuelle PHP-Version allein macht eine ältere, nicht kompatible Anwendung nicht automatisch lauffähig.

Die offizielle PHP-Tabelle unterscheidet aktiven Support und eine anschließende Phase mit Sicherheitskorrekturen. Laut Recherche vom 4. November 2026 erhalten PHP 8.2 und 8.3 nur noch Sicherheitskorrekturen; PHP 8.4 und 8.5 befinden sich im aktiven Support. Für PHP 8.2 endet der offizielle Sicherheitssupport am 31. Dezember 2026. Prüfe den Status vor einer Entscheidung erneut, weil sich diese Einordnung mit der Zeit ändert.

Die Anzeige einer Version im Selector beantwortet eine andere Frage als die Supporttabelle: Sie zeigt eine Auswahl in deiner Umgebung, belegt aber weder offiziellen Support noch die Kompatibilität deiner Anwendung. Umgekehrt folgt aus dem offiziellen Support eines Zweigs nicht, dass dein Hostingtarif ihn anbietet.

Ein Anbieter kann für ältere Pakete möglicherweise einen eigenen verlängerten Support anbieten. Kläre dafür schriftlich, welche Pakete und Sicherheitskorrekturen er umfasst, wie lange er läuft und wie Updates bereitgestellt werden. Dieser Anbietersupport ist nicht mit dem offiziellen Support des PHP-Projekts gleichzusetzen und ersetzt keinen Migrationsplan für die Anwendung.

Steht ein Wechsel auf einen neueren Zweig an, prüfe auch übersprungene Migrationsschritte und Hintergrundaufgaben. Der Beitrag zu PHP 8.5 im Hosting und zur Kompatibilitätsprüfung erläutert, welche Abhängigkeiten und Abläufe bei diesem konkreten Versionswechsel relevant sein können.

Umstellung kontrolliert vorbereiten

Beginne mit einer Bestandsaufnahme: Welche Oberfläche steht dir zur Verfügung, welche Domains verwaltet sie und welche PHP-Versionen sind für dein Konto freigegeben? Notiere die bisherige Auswahl und frage bei Unklarheiten nach dem tatsächlichen Geltungsbereich. So vermeidest du, eine vermeintlich einzelne Website umzustellen, obwohl weitere Domains betroffen sind.

Angenommen, eine aktuelle Anwendung und eine ältere Anwendung laufen nebeneinander. Prüfe zuerst, ob ihre Anforderungen mit einer gemeinsamen Zielversion vereinbar sind. Falls nicht, kann eine eigene Auswahl in getrennten Konten helfen; eine domainbezogene Alternative kommt nur infrage, wenn der Anbieter sie für deine Konfiguration unterstützt.

Prüfe vor produktiven Änderungen, ob eine aktuelle Sicherung von Dateien und Datenbank vorhanden und ihre Wiederherstellung geklärt ist. Eine abgeschirmte Testumgebung ist hilfreich, sofern du sie bereitstellen kannst: Dort prüfst du die Zielversion, ohne Besucher oder produktive Daten unnötig zu gefährden. Ob der Tarif Staging oder Sicherungen bereitstellt, bleibt beim Anbieter zu klären.

Dokumentiere neben der bisherigen und der gewünschten PHP-Version auch benötigte Erweiterungen und relevante Optionen. Vergleiche diese Angaben mit den Anforderungen der Anwendung und den im Tarif freigegebenen Einstellungen. Der CloudLinux Manager erlaubt administrative Vorgaben für Versionen und Erweiterungen; daraus folgt nicht, dass jede Option für Kunden selbst änderbar ist.

Teste in der abgeschirmten Umgebung nicht nur die Startseite, sondern auch Anmeldungen, Formulare, Imports und weitere für dein Projekt wichtige Abläufe. Prüfe geplante Aufgaben gesondert, weil ihre Ausführung nicht allein durch die Anzeige der Website belegt ist. Halte Auffälligkeiten fest und beseitige Kompatibilitätsprobleme vor der produktiven Umstellung.

Lege schließlich einen Rückweg fest: Wer darf die bisherige Version wieder auswählen, und welche Einstellungen müssen danach kontrolliert werden? Plane die Umstellung zu einem geeigneten Zeitpunkt und beobachte die betroffenen Anwendungen anschließend. Ein Rückwechsel der Version allein garantiert nicht, dass alle Erweiterungen und Optionen wieder wie zuvor gesetzt sind.

Web, CLI und Cronjobs prüfen

Eine Website und ihre Hintergrundaufgaben müssen nicht denselben PHP-Interpreter verwenden. HTTP-Anfragen verarbeitet eine vom Webserver und dessen Handler bestimmte Laufzeit; ein Kommandozeilenaufruf startet dagegen den Interpreter, den die jeweilige Umgebung findet. CloudLinux unterscheidet native Pfade für Web- und CLI-Interpreter. Die Anzeige im PHP Selector allein beantwortet daher nicht jede Frage zur tatsächlichen Ausführung.

Ist SSH in deinem Tarif verfügbar, kannst du in einer Terminal-Sitzung den folgenden lesenden Befehl ausführen. Er zeigt die Version des CLI-Interpreters, der für genau diesen Aufruf gefunden wird. Für die Prüfung sind keine Änderungen an Dateien oder Einstellungen nötig.

php -v

Das Ergebnis belegt weder die PHP-Version einer HTTP-Anfrage noch die eines anders aufgerufenen Cronjobs. Ein geplanter Auftrag kann einen ausdrücklichen Interpreterpfad oder eine andere Umgebung verwenden. Prüfe deshalb den hinterlegten Aufruf und die Ausführungsumgebung des konkreten Jobs, statt die Ausgabe deiner interaktiven Sitzung darauf zu übertragen.

Für die Webprüfung nutze eine geschützte, vom Anbieter unterstützte Methode und frage gegebenenfalls nach dem zuständigen Handler. Ein öffentlich erreichbares Diagnoseskript mit ausführlichen Umgebungsinformationen ist keine geeignete Standardlösung. Prüfe auch geplante Aufgaben über einen unterstützten Weg und kontrolliere anschließend, ob beispielsweise ein Import oder ein Versandjob tatsächlich wie vorgesehen arbeitet.

Halte für jeden relevanten Ausführungsweg fest, welche Version erwartet wird und wie sie geprüft wurde. Wenn das Panel, die SSH-Ausgabe und das Verhalten eines Jobs unterschiedliche Hinweise liefern, kläre zuerst die Zuständigkeit der jeweiligen Laufzeit mit dem Anbieter. So vermeidest du, an der falschen Stelle eine Einstellung zu ändern.

Fehler nach dem Wechsel eingrenzen

Lädt die Startseite nach dem Wechsel, aber ein Formular oder Import fällt aus, ist die Umstellung noch nicht ausreichend geprüft. Wiederhole den betroffenen Ablauf und notiere Zeitpunkt, Funktion und beobachtete Fehlermeldung. Vergleiche diese Angaben mit den verfügbaren Anwendungs- und Serverlogs, soweit dein Tarif Zugriff darauf bietet; sensible Logdaten gehören nicht in öffentlich zugängliche Dateien.

Prüfe anschließend die Kompatibilität der betroffenen Anwendung und ihrer Erweiterungen mit dem gewählten PHP-Zweig. Ein Formular kann beispielsweise von einem Plugin abhängen, das auf der Startseite gar nicht ausgeführt wird. Bei einem Import sind zusätzlich dessen Abhängigkeiten und der tatsächliche Ausführungsweg relevant: Ein Hintergrundauftrag kann eine andere Laufzeit verwenden als die Website.

Vergleiche die für die Zielversion verfügbaren und aktivierten PHP-Erweiterungen sowie die benötigten Optionen mit deiner Dokumentation vor dem Wechsel. Die Auswahl eines PHP-Zweigs bestätigt nicht automatisch, dass alle erforderlichen Module und Einstellungen passend sind. Welche Änderungen du selbst vornehmen darfst, hängt von der Freigabe durch den Betreiber ab.

Kontrolliere außerdem, ob die betroffene Domain tatsächlich den erwarteten Handler und die gewünschte Laufzeit verwendet. Falls mehrere Verwaltungsoberflächen vorhanden sind, kläre ihre Zuständigkeiten mit dem Anbieter, bevor du weitere Einstellungen änderst. Eine Anzeige im Selector muss nicht erklären, welcher Ausführungsweg eine konkrete Anfrage verarbeitet.

Warnung: Lenke Konfigurationspfade nicht pauschal über PHPRC oder PHP_INI_SCAN_DIR um. CloudLinux warnt, dass solche Änderungen an PHP-Konfigurationspfaden den Selector beeinträchtigen können. Wenn ein individueller Pfad notwendig erscheint, kläre ihn zuerst mit dem Anbieter.

Falls der Fehler nicht zeitnah lösbar ist, nutze den vorab festgelegten Rückweg zur bisherigen Version. Kontrolliere danach erneut die tatsächlich geltende Version, Erweiterungen und Optionen sowie die betroffenen Funktionen. Verlasse dich nicht darauf, dass ein Rückwechsel sämtliche früheren Einstellungen automatisch wiederherstellt; dokumentiere Abweichungen für den nächsten Versuch.

Legacy-Betrieb und Migration planen

Für den dauerhaften Betrieb entscheidet zuerst der benötigte Geltungsbereich: Passt eine gemeinsame Auswahl für die vom Selector verwalteten Domains eines Benutzers, kann der Selector eine geeignete Oberfläche sein. Benötigen zwei Anwendungen dagegen unabhängige Versionen, prüfe eine vom Anbieter unterstützte domainbezogene Verwaltung oder getrennte Hostingkonten. Die dokumentierte Selector-Auswahl allein verspricht keine unabhängige Einstellung für jede Domain im selben Konto.

Getrennte Konten können die Versionsentscheidungen organisatorisch entkoppeln, sofern die benötigten Zweige jeweils angeboten werden. Eine domainbezogene Lösung kann ebenfalls passen, wenn der Anbieter sie bereitstellt und ihr Zusammenspiel mit anderen PHP-Werkzeugen geklärt ist. Frage vor einer Umstellung nach Kosten, Tarifbedingungen und Zuständigkeiten; aus der technischen Möglichkeit folgt keine Zusage für ein bestimmtes Paket.

Eine ältere Anwendung sollte nicht allein deshalb dauerhaft auf einem alten Zweig bleiben, weil dieser im Menü auswählbar ist. Plane die Migration auf eine unterstützte Kombination aus Anwendung, Abhängigkeiten und PHP: Erfasse fehlende Updates, ersetzbare Erweiterungen und notwendige Anpassungen. Lege einen Termin für die nächste Kompatibilitätsprüfung und einen Zieltermin für die Ablösung fest.

Prüfe regelmäßig den offiziellen Supportstatus des verwendeten PHP-Zweigs und beobachte zugleich Fehlermeldungen und wichtige Geschäftsabläufe. Ein angebotener älterer Zweig ist kein Nachweis für fortlaufenden offiziellen Support. Die Supporttabelle des PHP-Projekts sollte vor jeder langfristigen Entscheidung erneut geprüft werden, weil sich der Status mit der Zeit ändert.

Stellt ein Anbieter erweiterten Support in Aussicht, lasse dir die betroffenen Pakete, die Art der Sicherheitskorrekturen und die Laufzeit belegen. Dieser Support ist gesondert vom offiziellen PHP-Support zu bewerten und ersetzt weder Updates der Anwendung noch die geplante Migration. Halte auch fest, wer Änderungen und Störungen während der Übergangszeit bearbeitet.