Die PHP-Version ist ein Auswahlkriterium für Hosting, das direkt zur Anwendung passen muss. Eine verfügbare neuere Version ist hilfreich, wenn Ihr Code damit funktioniert; eine alte gewohnte Version kann ihren offiziellen Support bereits verloren haben. Der richtige Weg verbindet Supportstatus, Herstelleranforderungen und einen praktischen Test der eigenen Installation. Dieser Artikel zeigt, welche Informationen Sie dafür sammeln und wie eine Umstellung kontrolliert abläuft.

Supportstatus und Funktionsfähigkeit unterscheiden

Eine Anwendung kann auf einer Laufzeit starten, die offiziell nicht mehr unterstützt wird. Umgekehrt kann eine offiziell unterstützte Laufzeit einzelne ältere Erweiterungen vor Probleme stellen. Prüfen Sie daher beide Fragen getrennt. „Unsere Seite funktioniert noch“ ist kein vollständiges Wartungskonzept. Ebenso ersetzt die Aussage „aktuellste PHP-Version“ keinen Kompatibilitätsnachweis für Ihren individuellen Bestand. Für die Produktauswahl benötigen Sie eine unterstützte und praktisch geeignete Kombination.

Die offizielle PHP-Supporttabelle nennt am Recherchestand 7. Oktober 2026 die Zweige 8.2, 8.3, 8.4 und 8.5. Sie unterscheidet aktive Unterstützung und reine Sicherheitsunterstützung. Ein Zweig erhält regulär zunächst zwei Jahre aktive und danach zwei Jahre Sicherheitsunterstützung. Die folgende Tabelle hält den recherchierten Stand fest; überprüfen Sie ihn erneut, wenn Sie später eine Laufzeitentscheidung treffen.

Offizieller PHP-Supportstand am 7. Oktober 2026
Zweig Aktive Unterstützung bis Sicherheitsunterstützung bis Einordnung zum Recherchestand
PHP 8.2 31. Dezember 2024 31. Dezember 2026 Nur Sicherheitsunterstützung; nahes planbares Ende
PHP 8.3 31. Dezember 2025 31. Dezember 2027 Nur Sicherheitsunterstützung
PHP 8.4 31. Dezember 2026 31. Dezember 2028 Aktive Unterstützung
PHP 8.5 31. Dezember 2027 31. Dezember 2029 Aktive Unterstützung

Die Anforderungen der vollständigen Anwendung erfassen

Notieren Sie WordPress-Core, aktives Theme, Plugins und eigene Anpassungen mit ihren Versionen. Auch selten benutzte Erweiterungen können bei einem Import oder einer Verwaltungsaktion ausgeführt werden. Ein einziges veraltetes Modul kann die zulässige Laufzeit begrenzen. Prüfen Sie Herstellerangaben und Änderungsprotokolle des konkreten Bestands. Eine allgemeine Aussage zum WordPress-Core beantwortet nicht die Kompatibilitätsfrage eines individuellen Shops oder Buchungssystems.

Die WordPress-Anforderungen empfehlen zum recherchierten Stand PHP 8.3 oder neuer sowie bestimmte Datenbankversionen und HTTPS. Diese Empfehlung ist eine Grundlage für die Umgebungsauswahl. Sie ist keine pauschale Freigabe sämtlicher Drittanbieterplugins unter jeder neueren PHP-Version. Dokumentieren Sie die Grenzen der einzelnen Komponenten und klären Sie unbelegte Aussagen mit den jeweiligen Verantwortlichen.

Erfassen Sie außerdem Funktionen, die außerhalb normaler Seitenaufrufe laufen: geplante Aufgaben, Importe, Exporte, Bildverarbeitung und Kommandozeilenwerkzeuge. Wenn eine Website im Browser eine Laufzeit verwendet und ein Hintergrundjob eine andere, kann der sichtbare Test erfolgreich sein, während die Aufgabe scheitert. Prüfen Sie daher die tatsächlich verwendeten ausführbaren Programme und Konfigurationen. Ein zufälliger Versionsaufruf im Terminal beschreibt nicht zwangsläufig die Website.

Verfügbarkeit im Tarif wirklich feststellen

Fragen Sie, welche PHP-Versionen im gewünschten Paket für Ihre Domain wählbar sind und wer die Auswahl ändern darf. Plattformunterstützung und konkrete Tarifberechtigung sind unterschiedliche Informationen. Die Plesk-Dokumentation zu PHP-Einstellungen erklärt die Verwaltungsfunktion, doch der Serverbestand und die vergebenen Rechte bestimmen die tatsächliche Auswahl. Eine Herstellerfunktion darf deshalb nicht als automatisch enthaltene Leistung jedes Hostingpakets beschrieben werden.

Prüfen Sie erforderliche Erweiterungen und Einstellungen zusätzlich zur Versionsnummer. Eine Anwendung kann beispielsweise eine bestimmte Bild- oder Zeichensatzfunktion benötigen. Ebenso relevant sind verfügbare Speichergrenzen und zulässige Ausführungszeiten. Halten Sie Bedarf und verfügbare Werte getrennt fest. Erhöhen Sie keine Grenzen pauschal, wenn die Ursache eines Fehlers noch unklar ist. Die Hosting-Checkliste ordnet solche Anforderungen als Mussbedingungen ein.

Den Test mit einem gesicherten Stand vorbereiten

Erstellen Sie vor der Laufzeitänderung eine brauchbare Sicherung und dokumentieren Sie die aktuelle Konfiguration. Eine reine Kopie einzelner Dateien kann für eine spätere Wiederherstellung unzureichend sein. Prüfen Sie auch Datenbank und notwendige Einstellungen. Der Ratgeber Backup und Wiederherstellung erläutert die Abnahme eines Sicherungsstands. Für die PHP-Prüfung ist eine geschützte Testkopie sinnvoll, die den relevanten Anwendungsbestand tatsächlich enthält.

Die Testkopie sollte passende Daten für fachliche Abläufe besitzen, ohne unnötig echte personenbezogene Informationen zu vervielfältigen. Verhindern Sie reale Zahlungen und Benachrichtigungen. Ordnen Sie Testzugänge und externe Verbindungen eindeutig zu. Der Artikel Staging und Produktivbetrieb erklärt diesen Rahmen. Eine unbeabsichtigt aktive Integrationskopie kann neue Fehler erzeugen, die nichts mit der PHP-Kompatibilität zu tun haben.

Migration Guides für den konkreten Versionssprung lesen

PHP stellt offizielle Migrationsanleitungen bereit, darunter die Schritte zu PHP 8.4 und PHP 8.5. Sie ordnen neue Funktionen, geändertes Verhalten, Inkompatibilitäten und veraltete Funktionen. Bei einem Sprung über mehrere Zweige sind auch die dazwischenliegenden Änderungen relevant. Eigener Anwendungscode sollte anhand dieser dokumentierten Unterschiede geprüft werden, statt nur auf einen erfolgreichen Start zu vertrauen.

Für ein Team ohne eigene Entwicklung ist die wichtigste Aufgabe, Wartungsverantwortliche und Pluginhersteller einzubeziehen. Bitten Sie um eine konkrete Aussage zur eingesetzten Version und dem geplanten Ziel. „PHP 8 unterstützt“ ist weniger präzise als eine bestätigte Kombination mit dem tatsächlichen Zweig. Liegt keine belastbare Angabe vor, bleibt die praktische Prüfung erforderlich. Bewahren Sie die Antwort mit dem Datum auf, denn später veröffentlichte Softwarestände können die Einordnung ändern.

Funktionen und Protokolle gemeinsam prüfen

Schalten Sie in der Testumgebung auf die vorgesehene Laufzeit und gehen Sie eine vorab definierte Funktionsliste durch. Dazu gehören öffentliche Seiten, Anmeldung, Bearbeitung, Upload und projektspezifische Abläufe. Ein Shop ergänzt Warenkorb und erlaubte Testzahlungen; eine Agenturinstallation möglicherweise Import und Export. Testen Sie mit derselben Liste vor und nach der Änderung, damit Unterschiede erkennbar werden. Behalten Sie die Testergebnisse am betreffenden Softwarestand.

Prüfen Sie Fehlerprotokolle während dieser Aktionen. Warnungen und Hinweise verdienen eine Bewertung, auch wenn der sichtbare Ablauf noch funktioniert. Nicht jede Meldung ist ein sofortiger Ausfall, aber eine neue Meldung kann auf später problematisches Verhalten hinweisen. Die WordPress-Debugging-Dokumentation unterscheidet Protokollierung und sichtbare Fehlerausgabe. Vertrauliche technische Details sollen nicht unkontrolliert in öffentlich gelieferten Seiten stehen.

Halten Sie bei einem Fehler die betroffene Aktion, den Zeitpunkt und die Meldung fest. Ändern Sie danach gezielt eine Komponente und wiederholen Sie denselben Ablauf. Wenn gleichzeitig fünf Plugins, das Theme und die Laufzeit ausgetauscht werden, ist eine Ursachenbewertung wesentlich schwieriger. Eine kleine dokumentierte Änderung erleichtert auch die Abstimmung mit dem Hersteller. Sie können dann zeigen, welcher Schritt unter welchem Stand fehlschlägt.

Eine Rückfalloption mit klarer Grenze

Vor der produktiven Umstellung muss bekannt sein, ob die bisherige Laufzeit noch wählbar ist und wie die alte Konfiguration wiederhergestellt wird. Prüfen Sie diesen Weg am tatsächlichen Hosting. Ein Panelwechsel kann eine einfache Rücknahme erlauben; andere Änderungen an Datenbank oder Anwendung können zusätzliche Wiederherstellungsschritte verlangen. Eine erfolgreiche Testkopie ersetzt die Vorbereitung des produktiven Rückfalls nicht. Definieren Sie deshalb, welcher Fehler die Freigabe verhindert.

Ein Rückfall auf eine nicht mehr unterstützte Version ist keine dauerhafte Lösung. Wenn er für eine kurzfristige Wiederherstellung unvermeidbar wird, braucht es eine verantwortliche Korrektur und einen klaren weiteren Termin. Die Auswahl eines neuen Hostingpakets sollte nicht dazu führen, dass ein ungelöstes Altsoftwareproblem auf einen anderen Server verschoben wird. Gegebenenfalls muss eine Erweiterung aktualisiert oder ersetzt werden, bevor ein sinnvoller langfristiger Betrieb möglich ist.

  1. Bestand erfassen
  2. Zielunterstützung prüfen
  3. Geschützte Kopie testen
  4. Fehler korrigieren
  5. Produktiv umstellen
  6. Nachprüfung dokumentieren

Die Umstellung als Betriebsänderung planen

Wählen Sie einen Zeitpunkt mit erreichbarer technischer und fachlicher Zuständigkeit. Informieren Sie Personen, die gerade Inhalte ändern oder Transaktionen bearbeiten. Notieren Sie Ausgangsversion, Zielversion und relevante Einstellungen. Nach der Umstellung wiederholen Sie die wichtigsten Aktionen auf der echten Installation. Kontrollieren Sie auch Hintergrundaufgaben, deren nächster regulärer Lauf erst später stattfindet. Ein gezielt erlaubter Testlauf kann schneller Klarheit schaffen als tagelanges Abwarten.

Beobachten Sie die Protokolle in der ersten Betriebsphase und halten Sie den Stand der Anwendung fest. Wenn eine spätere Pluginänderung Probleme verursacht, brauchen Sie diese Ausgangsinformation. Die Aufgabe endet mit einer nachvollziehbaren Freigabe und einer aktualisierten Wartungsplanung. Fragen Sie, wer den nächsten Supportwechsel beobachtet und wie rechtzeitig getestet wird. Ein jährlicher Blick allein kann unpassend sein, wenn ein verwendeter Zweig bald sein Sicherheitsende erreicht.

Beispiel einer Agenturentscheidung

Bei eigener Entwicklung gehören außerdem Abhängigkeiten zum Inventar. Ein mitgeliefertes Bibliothekspaket kann andere Anforderungen besitzen als der sichtbare Anwendungscode. Prüfen Sie die dokumentierten Vorgaben der tatsächlich verwendeten Versionen und halten Sie den reproduzierbaren Installationsstand fest. Entwickelnde sollten unterscheiden, ob nur die Serverlaufzeit geändert oder zusätzlich ein neues Abhängigkeitspaket erstellt wird. Diese zwei Änderungen können verschiedene Fehlerquellen haben und sollten in der Prüfung einzeln nachvollziehbar bleiben.

Bewerten Sie Leistungsunterschiede nur anhand passender Messungen. Eine neue Laufzeit kann technisch interessant sein, aber die Geschwindigkeit Ihrer Website hängt auch von Code, Datenbank, Cache und Browserarbeit ab. Veröffentlichen Sie keinen pauschalen Beschleunigungsfaktor für die eigene Installation, solange er nicht unter dokumentierten Bedingungen gemessen wurde. Der Ratgeber Hosting-Performance prüfen beschreibt, wie Vergleichsbedingungen und echte Benutzererfahrung voneinander getrennt werden.

Eine Agentur betreut mehrere Websites mit unterschiedlichen Erweiterungen. Sie erstellt pro Installation ein Inventar und verwendet eine gemeinsame Prüfliste, ergänzt um die jeweiligen fachlichen Funktionen. Ein älteres Importplugin begrenzt die Umstellung einer Website, während andere Projekte erfolgreich getestet werden. Daraus folgt eine separate Korrektur für dieses Projekt, keine pauschale Aussage, die neue PHP-Version sei für alle ungeeignet. Der Einzelfall bleibt eindeutig dokumentiert.

Das Beispiel zeigt eine Entscheidungsmethode und enthält keine hier gemessene Kompatibilitätsquote. Für die Produktauswahl fragt die Agentur nach Versionen je Domain, Verwaltungsrechten und dem unterstützten Wechselverfahren. Sie prüft auch, ob eigene Hintergrundaufgaben denselben Zielstand verwenden können. Dadurch wird aus der abstrakten Versionszahl eine konkrete Betriebsanforderung. Ein Managed-Angebot muss zusätzlich klären, welche Prüfungen und Korrekturen der Anbieter tatsächlich übernimmt.

  • Core, Theme, Plugins und eigener Code sind mit Versionen erfasst.
  • Der Zielzweig ist offiziell unterstützt und im Tarif verfügbar.
  • Benötigte Erweiterungen, Einstellungen und Aufgaben wurden berücksichtigt.
  • Die geschützte Kopie besteht die wichtigen fachlichen Tests.
  • Neue Protokollmeldungen sind bewertet und Fehler nachvollziehbar korrigiert.
  • Produktive Nachprüfung, Rückfallweg und nächste Wartung sind festgelegt.

Nutzen Sie diese Liste vor einer Bestellung und vor jeder späteren Laufzeitänderung. Die Produktübersicht unterstützt den Vergleich belegter Merkmale, während die konkrete Anwendung die technische Eignung bestimmt. Ein passendes Hosting bietet nicht nur eine Versionsauswahl, sondern einen praktikablen Rahmen für Prüfung, Umstellung und fortlaufende Pflege. Welche Arbeit dabei intern verbleibt, sollte ausdrücklich vereinbart werden.