Fehler oder weisse Seite nach der PHP-Umstellung des Hosters: So bringst du deine Webapplikation wieder zum Laufen

Warum zeigt die Anwendung nach dem PHP-Wechsel nichts mehr an?

Jede neue PHP-Version entfernt alte Funktionen. Ruft deine Anwendung eine davon auf, bricht PHP mit einem schweren Fehler ab. Auf einem Live-Server ist die Anzeige von Fehlern zu Recht ausgeschaltet, die PHP-Dokumentation rät davon ab, sie auf Systemen am Internet einzuschalten. Deshalb siehst du im Browser oft nur eine weisse Seite oder eine allgemeine Fehlermeldung. Die eigentliche Ursache steht im Fehlerlog.

Häufig trifft es nicht die ganze Anwendung: Die Startseite läuft, aber das Login, der Warenkorb oder der nächtliche Export bricht ab. Bei manchen Hostern gilt die Umstellung zudem getrennt für Website und Kommandozeile, Cronjobs laufen dann mit einer anderen Version als die Website. Ob dafür dein Hoster, dein früherer Entwickler oder du zuständig bist, klärt der Artikel Wer ist zuständig: Hoster, Entwickler oder du?

Was ist noch vorhanden?

Bevor du etwas reparierst, kläre drei Fragen in dieser Reihenfolge. Jede Antwort führt zu einem ersten Schritt.

1. Hast du Zugang zum Hosting-Konto?
   • Ja: weiter mit Frage 2.
   • Nein: Hol zuerst den Zugang zurück. Läuft der Hosting-Vertrag auf deine Firma, stellt der Hoster ihn wieder her. Läuft er auf deinen früheren Entwickler oder die Agentur, kann nur diese Vertragspartei handeln. Wie du dann vorgehst, steht in den Sofortmassnahmen, wenn der Entwickler nicht erreichbar ist.
2. Lässt sich die bisherige PHP-Version zurückstellen?
   • Ja: Stell sie im Hosting-Panel für die betroffene Website zurück und prüf, ob die Anwendung wieder läuft. Das verschafft dir Zeit, aber nur so lange, wie der Hoster die alte Version anbietet. Plan das PHP-Upgrade gleich danach.
   • Nein: weiter mit Frage 3. Der Rückweg ist dann zu oder kostet extra, Beispiele stehen weiter unten.
3. Gibt es ein aktuelles Backup von Code, Datenbank und hochgeladenen Dateien?
   • Ja: Leg eine Kopie ausserhalb des Servers ab. Mit Backup und Fehlerlog lässt sich die Anwendung auf einer Kopie reparieren, ohne den Live-Stand zu gefährden. Steht dein Geschäft still, ist das ein Fall für den Notfall-Eingriff.
   • Nein: Zieh jetzt eines, auch wenn die Anwendung gerade nicht läuft. Eine PHP-Umstellung löscht keine Dateien: Code und Datenbank liegen noch auf dem Server, nur führt PHP den Code nicht mehr aus.

Die ersten 24 Stunden

1. Zustand festhalten. Seit wann, welche Seiten, welche Meldung? Mach Screenshots und bewahr die Mail des Hosters auf.
2. PHP-Version prüfen. Im Hosting-Panel steht, welche Version jetzt läuft und welche vorher lief. Prüf Website und Kommandozeile getrennt.
3. Zurückstellen, wenn möglich. Das ist meist der schnellste Weg zurück in den Betrieb. Notier dir, bis wann der Hoster die alte Version noch anbietet.
4. Fehlerlog lesen. Im Hosting-Panel und im Log-Ordner der Anwendung, bei Laravel storage/logs, bei Symfony und Shopware var/log, bei TYPO3 var/log oder typo3temp/var/log. Die erste Meldung mit «Fatal error» ist meist die entscheidende.
5. Backup sichern. Code, Datenbank, hochgeladene Dateien und Konfiguration, gespeichert ausserhalb des Servers. Ein Backup, das nur auf demselben Server liegt, ist keins.
6. Zugänge prüfen. Hosting, Domain und DNS, Datenbank, Code-Repository, Mailversand: Wer hat welchen Zugang, und läuft etwas davon auf eine Person, die nicht mehr da ist?
7. Betroffene informieren. Lass dein Team und, wo nötig, deine Kunden wissen, dass Bestellungen oder Anfragen gerade nicht ankommen.
8. Erst dann reparieren. Auf einer Kopie, mit der Meldung aus dem Log als Wegweiser, nicht durch Ausprobieren auf dem Live-Server. Eine Prüfung abzuschalten, die einen Fehler meldet, behebt ihn nicht.

Typische Fehlermeldungen nach dem PHP-Wechsel

Die Tabelle zeigt Meldungen, wie PHP und Composer sie wörtlich ausgeben, wenn Code oder Pakete nicht zur laufenden PHP-Version passen. Im Log steht davor meist «PHP Fatal error: Uncaught Error:», dahinter Datei und Zeile.

Meldung	Ursache	Erster Schritt
Call to undefined function mysql_connect()	Die Erweiterung mysql ist seit PHP 7.0 entfernt, mit allen mysql_*-Funktionen.	Die bisherige Version zurückstellen, falls der Hoster sie noch anbietet. Der Umbau auf mysqli oder PDO betrifft meist jeden Datenbankzugriff, er gehört geplant, nicht geflickt.
Call to undefined function each()	each() ist seit PHP 8.0 entfernt.	Die betroffene Schleife auf foreach umschreiben, wie es die PHP-Dokumentation empfiehlt. Steckt die Stelle in einer fremden Bibliothek, ist deren Update der bessere Weg.
Call to undefined function create_function()	create_function() ist seit PHP 8.0 entfernt.	Durch eine anonyme Funktion ersetzen. Bei Bibliotheken zuerst nach einer neueren Version suchen.
Call to undefined function get_magic_quotes_gpc()	Seit PHP 8.0 entfernt. Die Funktion lieferte ohnehin immer false.	Den Aufruf entfernen oder durch false ersetzen, am Verhalten ändert das nichts.
Call to undefined function mcrypt_encrypt()	Die Erweiterung mcrypt gehört seit PHP 7.2 nicht mehr zu PHP.	Vor jedem Umbau klären, welche Daten damit verschlüsselt sind. Sie müssen mit dem Ersatz, OpenSSL oder Sodium, lesbar bleiben.
Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.2.0".	Die installierten Pakete verlangen eine neuere PHP-Version als die, die gerade läuft. Die Versionsnummer hängt von deinen Paketen ab. Typisch, wenn die Version zurückgestellt wurde, nachdem jemand die Pakete mit einer neueren Version installiert hat, oder wenn Website und Kommandozeile verschiedene Versionen nutzen.	Die PHP-Version auf die verlangte Version stellen. Die Prüfung abzuschalten (platform-check), versteckt den Fehler nur.
Keine Meldung, nur eine weisse Seite	Die Fehleranzeige ist auf dem Live-Server ausgeschaltet, wie es die PHP-Dokumentation empfiehlt.	Das Fehlerlog lesen, statt die Anzeige live einzuschalten. Dort steht eine der Meldungen oben oder eine andere, mit Datei und Zeile.

Andere Fehler nach dem Wechsel auf PHP 8, etwa zu Typen und Argumenten, hängen stärker vom einzelnen Code ab. Auch sie stehen mit Datei und Zeile im Log, und die Migrationsanleitungen auf php.net erklären, was sich je Version geändert hat.

Rückweg beim Hoster

Ob und wie lange du zur alten Version zurückkannst, regelt jeder Hoster anders. Drei Beispiele aus der Hoster-Tabelle (Stand 27. Oktober 2026):

Hoster	Was bei der Umstellung passiert	Rückweg
Onlime	Bei PHP 8.1: Ankündigung, E-Mail mit einer Woche Frist, dann automatische Umstellung auf 8.2	Zwei Wochen Rückweg
Kreativmedia	Automatisch die nächsthöhere Standardversion, eine nicht kompatible Website kann ausfallen	Option «Webhosting Custom» mit PHP 7.4 bis 8.3 auf separatem System, CHF 4.– pro Monat
HOSTFACTORY	Ohne Reaktion automatisch auf das kostenpflichtige LegacyPHP, die Website läuft weiter	Kein Ausfall, aber zusätzliche Lizenzen zu CHF 1.45 je Domain-Account und Monat

Die Regeln der übrigen Schweizer Hoster stehen im Artikel PHP End of Life. Verbindlich ist, was dein Hoster dir mitteilt. Ein Rückweg ist immer befristet: Er verschafft Zeit für das Upgrade, ersetzt es aber nicht.

Nur noch ein Backup: wieder in Betrieb?

Manchmal läuft gar nichts mehr: Das Hosting ist gekündigt, die Anwendung abgeschaltet, übrig ist ein Backup. Wieder in Betrieb nehmen lässt sie sich, wenn das Backup vollständig ist, also Code, Datenbank, hochgeladene Dateien und Konfiguration enthält. Dazu braucht es einen Server mit einer PHP-Version, auf der der Code läuft. Ist das eine Version ohne Sicherheitsupdates, taugt das nur als Übergang bis zum Upgrade.

Ein Backup nach Vertragsende kann nur die Vertragspartei beim Hoster anfordern. Lief das Hosting auf deinen früheren Entwickler oder die Agentur, muss diese es anfordern; wie du sie dazu bringst, steht in den Sofortmassnahmen, wenn der Entwickler nicht erreichbar ist. Frag so früh wie möglich nach, denn Hoster bewahren Backups nur begrenzte Zeit auf. Ob das Backup reicht und was für den Neustart fehlt, zeigt das Übernahme-Assessment. Eilt es, hilft der Notfall-Eingriff.

Ein Notfall muss nicht an PHP liegen

Fällt deine Anwendung aus, während die Hoster reihenweise PHP-Versionen umstellen, liegt der Verdacht auf PHP nahe. Ein Beispiel aus meiner Praxis zeigt, warum zuerst das Log zählt: Bei einer grossen TYPO3-Website mit etlichen Eigenentwicklungen war das Login kaputt, und der bisherige Dienstleister bekam die Probleme nicht in den Griff. Die erste Analyse lag innert einer Stunde nach dem Anruf vor. Die Ursache war das Login selbst, das über das ERP des Kunden läuft, kein Hack und kein PHP-Update. Sobald die Zugänge da waren, folgte eine erste Reparatur, und am selben Nachmittag lief die Website wieder. Danach kam das überfällige Upgrade von TYPO3 8 auf 12, in rund vier Monaten.

Daraus folgt zweierlei: Such die Ursache im Fehlerlog, statt auf Verdacht die PHP-Version zu ändern. Und schnelle Hilfe hängt an den Zugängen, deshalb gehören sie geordnet und griffbereit zu deiner Firma.

Wie geht es nach dem Notfall weiter?

Läuft die Anwendung wieder, läuft die Frist deines Hosters trotzdem weiter. Wie gross der Schritt auf eine unterstützte Version ist, steht im Artikel PHP-Upgrade, welche Termine als Nächstes anstehen, im End-of-Life-Kalender. Kennt niemand mehr die Anwendung, zeigt das Übernahme-Assessment, was das Upgrade braucht, mit einem Fixpreis für die Umsetzung. Danach hält die laufende Wartung PHP und Pakete im festen Rhythmus aktuell, damit die nächste Umstellung keine weisse Seite mehr bringt.