PHP Version wechseln: Test, Umschaltung und Rückweg

Das Ziel vor dem Schalter festlegen

Eine neue PHP Version kann Fehler beheben und den Zeitraum für Herstellerupdates verlängern. Sie kann aber auch alten Code anders ausführen. Deshalb ist der Wechsel keine rein optische Auswahl in Plesk. Definieren Sie zunächst, welche Version aus welchem Grund gebraucht wird und welche Anwendung auf ihr laufen soll. Eine bloße Empfehlung aus einem Forum reicht dafür nicht. Prüfen Sie den Supportstatus beim PHP Projekt, die Anforderungen der Anwendung und die im eigenen Abo tatsächlich angebotenen Versionen. Diese drei Listen können voneinander abweichen. Was vom Hersteller unterstützt wird, muss auf einem konkreten Host noch nicht installiert oder für Ihren Kunden freigegeben sein.

Die offizielle PHP Supporttabelle nennt am Recherchetag 7. Oktober 2026 die Zweige 8.2 bis 8.5 als unterstützt, mit verschiedenen Phasen. Für 8.2 endet der dort genannte Sicherheitszeitraum am 31. Dezember 2026. Das macht den verbleibenden Planungsbedarf sichtbar, bestimmt aber nicht automatisch das passende Ziel für jede Website. Ein Projekt mit einer älteren Erweiterung braucht unter Umständen zunächst eine Codeänderung. Halten Sie in Ihrer Planung sowohl den Herstellerstatus als auch den Termin der eigenen Migration fest. Prüfen Sie diese Quelle vor einem späteren Wechsel erneut, weil Supportdaten und verfügbare Patchversionen zum laufenden Betrieb gehören.

Den aktuellen Stand vollständig aufnehmen

Notieren Sie die aktive PHP Version, den Handler und alle bewusst gesetzten Werte. Dazu zählen Speicherlimit, Zeitgrenzen, Uploadgrenzen sowie besondere Erweiterungen. Sammeln Sie außerdem die Versionen von Anwendung, Theme und Plugins. Eine Liste dieser Bestandteile zeigt, welche Aussagen der Hersteller relevant sind und welche Teile eigens entwickelt wurden. Eigenes PHP in einem Theme oder einem kleinen Plugin wird leicht übersehen, obwohl es bei einer Migration genauso wichtig ist wie ein großes Zusatzpaket. Wenn Sie den Ursprung einer Datei nicht kennen, sollten Sie sie nicht einfach durch eine frische Standarddatei ersetzen. Ermitteln Sie zuerst, welche Funktion sie im Projekt erfüllt.

Erfassen Sie neben dem Webpfad die geplanten Jobs und Werkzeuge auf der Kommandozeile. Eine Website kann mit PHP 8.4 arbeiten, während ein Import weiterhin ein anders benanntes Programm startet. Für jeden Job brauchen Sie den vollständigen Weg zur Laufzeit, den Benutzer und das Arbeitsverzeichnis. Bei eingeschränkter Shell kann ein Weg außerdem anders sichtbar sein als im normalen Terminal. Die Plesk Beschreibung der Shell für geplante Aufgaben hilft, diese Umgebung einzuordnen. Die späteren Prüfungen müssen denselben Weg nutzen wie der echte Job, sonst testen Sie nur eine ähnliche Umgebung.

Kompatibilität in brauchbare Fragen übersetzen

Lesen Sie den Migrationsleitfaden für den tatsächlich geplanten Sprung. Der Leitfaden für PHP 8.4 unterscheidet beispielsweise neue Funktionen, Änderungen und veraltete Merkmale. Für Betreiber ist weniger die Vollständigkeit einer Sprachliste entscheidend als deren Bezug zur Anwendung. Fragen Sie bei einem betreuten Plugin nach einer konkreten unterstützten Version und nach bekannten Grenzen. Prüfen Sie eigene Bibliotheken und fest eingebundene Pakete separat. Ein grünes Ergebnis eines Syntaxchecks ist hilfreich, aber es sagt noch nichts darüber aus, ob Daten richtig verarbeitet werden oder ob eine externe Schnittstelle im neuen Stand wie erwartet antwortet.

Aus dieser Prüfung entsteht eine Funktionsliste. Sie sollte den Wert der Website abbilden: Bei einer Redaktion sind Schreiben, Vorschau, Veröffentlichung und Medien wichtig. Bei einem Portal zählen Anmeldung, Rechte, Suche und Datenexport. Bei einem Shop gehören Preisberechnung, Warenkorb und Bestellablauf dazu, wobei Tests in einer getrennten Umgebung keine echten Bestellungen oder Nachrichten auslösen sollten. Stellen Sie für jeden Test fest, wie Erfolg aussieht. Eine Seite mit Status 200 kann ein leeres Suchergebnis liefern oder eine Fehlermeldung im Inhalt verstecken. Prüfen Sie daher auch das Ergebnis, den erwarteten Datenstand und die zugehörigen Logs.

Eine Vorschau mit kontrollierten Nebenwirkungen

Erstellen Sie eine getrennte Testumgebung mit einem passenden Datenstand. Kopieren Sie dabei nur die Daten, die für den Test nötig sind, und schützen Sie den Zugriff. Deaktivieren oder ersetzen Sie Nachrichten, externe Schreibzugriffe und produktive Zahlungswege. Auch ein nächtlicher Job kann nach einer Kopie doppelt aktiv sein und echte Dienste ansprechen. Deshalb genügt es nicht, die Testdomain mit einem anderen Namen zu versehen. Prüfen Sie die gesamte Wirkung der Anwendung. Bei sensiblen Daten kann ein bereinigter Testbestand sinnvoll sein. Die Umgebung soll die relevante Technik abbilden, ohne vertrauliche Inhalte unnötig zu vervielfachen oder den laufenden Betrieb zu beeinflussen.

Ändern Sie in der Vorschau zunächst nur die PHP Version. Wenn gleichzeitig Plugins, Theme und Webserverpfad gewechselt werden, wird ein Fehler schwer zuzuordnen. Lassen Sie die Tests unter dem alten und neuen Stand laufen und vergleichen Sie die Ergebnisse. Eine vorhandene Warnung darf nicht als neuer Migrationsfehler gelten, sollte aber im Bericht erhalten bleiben. Ebenso ist ein Erfolg in der Vorschau keine pauschale Garantie für die Produktion: Last, Rechte und bestimmte Jobs können dort anders sein. Halten Sie diese Abweichungen fest und planen Sie gezielte Prüfungen nach der produktiven Umschaltung. So bleibt der Beleg ehrlich und trotzdem handlungsfähig.

Den Rückweg vor der Umschaltung bauen

Der wichtigste Rückweg ist der bereits bekannte laufende Stand. Prüfen Sie vor dem Wechsel, ob die alte Laufzeit und der alte Handler weiterhin auswählbar sind. Bewahren Sie die vorherigen domainspezifischen Einstellungen auf. Ein Backup sollte Dateien und Datenbank zusammen abdecken und vor der Änderung abgeschlossen sein. Testen Sie, wie ein Restore in einer eigenen Umgebung funktioniert. Der Ratgeber zum Restore Test beschreibt, welche Belege dabei helfen. Wenn die neue Anwendung bereits Datenformate verändert, kann die Rückkehr zur alten PHP Version allein nicht mehr ausreichen. Solche Änderungen brauchen einen abgestimmten Wiederherstellungspunkt und eine klare Grenze für neue Eingaben.

Legen Sie fest, wann die Änderung abgebrochen wird. Geeignete Kriterien sind ein gescheiterter Login, ein nicht funktionierender Kernablauf oder neue schwerwiegende Fehler im relevanten Log. Eine kleine Darstellungsabweichung kann dagegen getrennt beurteilt werden, wenn die wichtigen Funktionen intakt bleiben. Diese Grenze muss zur Website passen und vor dem Wartungsfenster bekannt sein. Halten Sie auch die zuständige Person und deren Erreichbarkeit fest. Falls nur der Anbieter den alten Handler zurückstellen darf, ist dessen Weg Teil des Plans. Ein Rückweg, für den nachts niemand Zugriff hat, ist im entscheidenden Moment praktisch kein verfügbarer Rückweg.

In Plesk Version und Handler getrennt bewerten

Die Auswahl einer PHP Version und die Wahl ihres Handlers sind unterschiedliche Entscheidungen. Wenn Sie den Versionswechsel zum Anlass nehmen, von Apache auf direkte Verarbeitung durch nginx umzusteigen, verändern Sie zusätzlich den Umgang mit Apache Regeln. Die Plesk Handler Dokumentation erläutert diesen Unterschied. Prüfen Sie Weiterleitungen, Zugriffsschutz und URLs daher erneut, wenn ein solcher Umbau erforderlich ist. Für einen normalen Versionswechsel ist es meist leichter, den bisher geprüften Anfrageweg beizubehalten und eine mögliche Änderung des Webservers in einem eigenen Schritt zu behandeln.

Nach dem Speichern folgt die praktische Abnahme. Öffnen Sie die Website über die reguläre HTTPS Adresse, testen Sie mehrere Seitentypen und melden Sie sich mit einem geeigneten Testkonto an. Prüfen Sie dann den Hintergrundweg mit dem tatsächlich eingestellten PHP Programm. Leeren Sie nur die nötigen Caches in einem bewusst begrenzten Umfang. Ein vollständiges Löschen aller Caches auf dem Host kann andere Websites belasten und den Test verfälschen. Falls Inhalte zunächst alt erscheinen, klären Sie, welche Ebene diese Antwort liefert. Erst dann lässt sich entscheiden, ob die Laufzeit korrekt arbeitet oder eine vorgelagerte Antwort den neuen Stand verdeckt.

Fehler nach dem Wechsel gezielt eingrenzen

Bei einer weißen Seite oder einem Fehlerstatus benötigen Sie den ersten relevanten Fehler im Log, nicht nur den sichtbaren Status. Suchen Sie nach dem Zeitraum des Tests und nach dem richtigen Host. Eine fehlende Erweiterung verlangt eine andere Lösung als eine geänderte Sprachfunktion oder ein nicht erreichbarer FPM Socket. Ändern Sie nicht mehrere Grenzwerte auf Verdacht. Wenn ein Speicherfehler auftritt, prüfen Sie zuerst den betroffenen Ablauf und die bisherige Konfiguration. Unser Leitfaden für FPM Fehler trennt Laufzeit, Kapazität und Verbindung. Er hilft auch, eine Meldung an den Anbieter so einzugrenzen, dass dieser direkt am passenden Teil ansetzen kann.

Dokumentieren Sie neben dem Fehler auch die Umgebung, in der er auftrat. Lief derselbe Ablauf in der Vorschau erfolgreich, vergleichen Sie Rechte, Erweiterungen, Datenumfang und die Werte des Handlers. Prüfen Sie beim Webpfad zudem, ob die neue Auswahl tatsächlich aktiv ist. Eine abgesicherte kurze Diagnose ist besser als eine öffentlich zurückgelassene Datei mit umfassenden Systemdaten. Entfernen Sie Hilfsdateien nach dem Test und prüfen Sie deren Nichterreichbarkeit. In der Übergabe bleiben die benötigten Fakten erhalten, jedoch keine Zugangsdaten oder vollständigen Konfigurationen. Das ist besonders wichtig, wenn mehrere Personen oder ein externer Support den Bericht lesen sollen.

Testdaten nach der Wirkung des Codes wählen

Gute Testdaten decken unterschiedliche Eingaben ab. Nutzen Sie einen kurzen und einen langen Text, einen Dateinamen mit Umlaut, einen leeren optionalen Wert und eine typische umfangreiche Suche. Diese Fälle prüfen andere Stellen als ein bloßer Aufruf der Startseite. Bei eigenen Formularen gehören auch erwartete Fehlermeldungen dazu: Eine ungültige Eingabe soll kontrolliert abgewiesen werden und nicht zu einem technischen Fehler führen. Wenn die Website Datumswerte oder Zahlen verarbeitet, wählen Sie Beispiele, die im echten Betrieb vorkommen. Halten Sie erwartetes und beobachtetes Ergebnis nebeneinander fest. Diese kleine Auswahl macht die Abnahme konkreter, ohne beliebige Sonderfälle zu sammeln, die für das Projekt keine Rolle spielen.

Bei einem eigenen Import prüfen Sie nicht nur, ob er startet. Vergleichen Sie die Anzahl und einige bekannte Inhalte der übernommenen Datensätze. Kontrollieren Sie, ob fehlende Werte, Zeichen und vorhandene Duplikate wie vorgesehen behandelt werden. Ein Job kann ohne technischen Fehler enden und trotzdem fachlich falsche Ergebnisse liefern. Dasselbe gilt für einen Export: Öffnen Sie die erzeugte Datei mit dem vorgesehenen Werkzeug und prüfen Sie die benötigten Felder. So wird die Migration an der tatsächlichen Arbeit der Anwendung beurteilt. Für einen späteren Wechsel können diese Beispiele wieder genutzt werden, solange ihre erwartete Wirkung noch zum aktuellen Funktionsumfang passt.

Die Migration endet nach der ersten Jobrunde

Eine Abnahme direkt nach dem Wechsel deckt noch nicht alle zeitabhängigen Funktionen ab. Kontrollieren Sie den nächsten fälligen Export, den geplanten Beitrag und weitere wichtige Wartungsaufgaben. Dabei interessieren nicht nur Startzeit und Status, sondern das erwartete Ergebnis. Ein Job kann erfolgreich enden und dennoch keine Datei erzeugen, weil er mit einem anderen Pfad arbeitet. Vereinbaren Sie deshalb einen kurzen Beobachtungszeitraum, der zu den Intervallen der Website passt. Die Betriebsprüfung für WordPress Cron ergänzt diesen Teil. Ihre Wartungsnotiz erhält erst dann einen vollständig geprüften Status, wenn auch diese vereinbarten Wege beobachtet wurden.

Die wichtigste dauerhafte Änderung ist der aktualisierte Bestand. Tragen Sie die neue Version, den Handler, die Jobpfade und den nächsten Supporttermin ein. Vermerken Sie, welche Funktionen geprüft sind und welche Integrationen wegen fehlender Testdaten offen blieben. Eine offene Grenze ist kein Grund, die übrige Arbeit unklar zu beschreiben. Sie sollte jedoch einen konkreten Besitzer und einen nächsten Schritt bekommen. Ein guter PHP Wechsel hinterlässt einen bekannten, getesteten Stand und eine verständliche Historie. Damit wird die nächste Migration leichter: Sie beginnt nicht bei einer Vermutung über die bisherige Laufzeit, sondern bei einem dokumentierten Ausgangspunkt mit tatsächlich genutzten Funktionen.