Ist-Stand und Ziel getrennt notieren
Ermitteln Sie zunächst die tatsächlich verwendete PHP-Version im Hostingkonto. Notieren Sie zusätzlich die vorhandenen WordPress-, Theme- und Pluginversionen. Die aktuelle Unterstützung eines PHP-Zweigs wird bei PHP.net geprüft; Herstelleranforderungen ergänzen die Liste. Eine im Panel auswählbare Version ist nicht automatisch für jede Erweiterung Ihrer Website geeignet. Auch die generelle WordPress-Kompatibilität ersetzt diese Prüfung nicht.
Der aktuelle WordPress-Einstieg zu Hostingvoraussetzungen empfiehlt PHP ab 8.3. Dieser am 7. Oktober 2026 geprüfte Ausgangspunkt ist keine automatische Freigabe Ihrer individuellen Anwendung. Das Ziel wird anhand der vollständigen Installation gewählt und mit der zuständigen technischen Person abgestimmt.
Die häufig übersehenen Teile aufnehmen
Neben aktiven Plugins können eigene Themefunktionen, geplante Aufgaben und Importskripte PHP verwenden. Erfassen Sie diese Bestandteile. Prüfen Sie, ob die Webanwendung und ein kommandozeilenbasierter Job dieselbe Version verwenden sollen und wie das Konto dies tatsächlich umsetzt. Unterschiedliche Ausführungspfade können sonst zu schwer erkennbaren Abweichungen führen. Passwortgeschützte Teststände werden ebenfalls aufgenommen, weil sie später dieselben Änderungen benötigen.
Fachlich wichtige Verbindungen bekommen eigene Testfälle: etwa ein Dokumentexport oder die Übergabe an einen Buchungsdienst. Wenn ein Hersteller eine bestimmte Zusatzanforderung nennt, wird diese am Ziel geprüft. Nicht dokumentierte Module werden nicht als automatisch vorhanden vorausgesetzt.
In einer passenden Kopie testen
Erstellen Sie vor dem Test eine Sicherung und einen geschützten Zielstand. Wechseln Sie dort zunächst nur die PHP-Version. So bleibt eine mögliche Ursache nachvollziehbar. Kontrollieren Sie öffentliche Seiten, Editor, Upload, Suche und wichtige Funktionen. Achten Sie auf sichtbare Fehler sowie passende geschützte Protokolle. Testdaten und ausgehende Mail werden bewusst kontrolliert.
Der Stagingleitfaden beschreibt Quelle, Ziel und Schutz. Eine leere Neuinstallation reicht als Kompatibilitätstest einer gewachsenen Website selten aus. Die Kopie muss die entscheidenden Erweiterungen und Abläufe tatsächlich enthalten.
Fehler gezielt zuordnen
Bei schmaler Ansicht: Tabelle seitlich wischen oder scrollen.
| Beobachtung | Nächster Schritt |
|---|---|
| Ein Plugin verursacht einen Fehler | Herstellerstand und Fehlerstelle prüfen |
| Upload scheitert | Grenzen und Verarbeitung kontrollieren |
| Ein Job funktioniert nicht | Ausführungspfad und Version verifizieren |
| Keine sichtbaren Fehler | Geschäftliche Abläufe trotzdem testen |
Eine fehlende Fehlermeldung bedeutet noch keinen vollständig geprüften Betrieb. Umgekehrt erlaubt ein einzelner Fehler keine pauschale Aussage, dass der gesamte Tarif ungeeignet ist. Dokumentieren Sie den betroffenen Vorgang und lassen Sie die Ursache gezielt beheben. Änderungen am eigenen Code gehören in die dafür vorgesehene Betreuung.
Die Produktionsänderung vorbereiten
Legen Sie das Wartungsfenster und einen passenden aktuellen Sicherungsstand fest. Halten Sie bisherigen Zustand und Rückweg fest. Prüfen Sie, ob andere Änderungen seit dem Test hinzugekommen sind. Direkt nach dem Versionswechsel wird derselbe Funktionsplan im tatsächlichen produktiven Ziel abgearbeitet. Neue Daten und notwendige fachliche Abläufe müssen dabei berücksichtigt werden. Die Wartungsroutine sorgt dafür, dass Ergebnis und Zuständigkeit erhalten bleiben.
Ein periodischer Export als Testfall
Ein Verein erzeugt monatlich einen umfangreicheren Dokumentexport. Vor dem PHP-Wechsel wird genau dieser Vorgang in einer passenden geschützten Kopie getestet. Selten genutzte wichtige Funktionen gehören in die Abnahme. Die Prüfung enthält einen repräsentativen Datenbestand und nicht nur ein leeres Muster. Wenn der Export über einen geplanten Job läuft, wird dessen tatsächlicher Ausführungspfad ebenfalls geprüft. Ergebnis, Version und Konfiguration werden festgehalten. Nach dem Produktionswechsel wird der nächste geplante Lauf bewusst beobachtet. Damit bleibt sichtbar, ob die erfolgreiche Browserprüfung auch den weniger sichtbaren Betrieb abgedeckt hat oder eine weitere gezielte Anpassung nötig ist.
Den Ressourcenrahmen getrennt beurteilen
Ein Versionswechsel kann technische Eigenschaften verändern, ist aber kein Ersatz für eine Ressourcenplanung. PHP-Speicherlimit, Gesamt-RAM und Prozessgrenzen bleiben unterschiedliche Größen. Lesen Sie dazu Ressourcen richtig lesen. Bei Starter, Webhosting Business und Managed Server Startup muss die konkrete verfügbare Umgebung bestätigt werden. Prüfen Sie nach dem Wechsel den Betrieb in einem repräsentativen Zeitraum, bevor die Änderung als abgeschlossen dokumentiert wird.
Quellen und Prüfstand
Primärquellen, zuletzt geprüft am 7. Oktober 2026. Anbieterangaben können sich ändern.