WordPress Ausfall nach PHP Upgrade von 7.4 auf 8.2+

PHP 7.4 hat sein End-of-Life erreicht. Ein Upgrade ist Pflicht bzw. bieten viele Hoster die alte PHP Version nur noch in Verbindung mit kostenpflichtigen Extended Support Paketen. Doch der Sprung auf 8.2+ legt regelmäßig WordPress-Seiten lahm. Dieser Artikel zeigt die konkreten Ursachen, die exakten Fehlermeldungen aus dem Error Log und erprobte Lösungen für jedes Problem.

Keine Lust alles selbst zu machen? Ich unterstütze meine Kunden bei der Umstellung von PHP Versionen und bei technischen Problemen aller Art:

Inhaltsverzeichnis

Warum ist der Sprung von PHP 7.4 auf 8.2+ so problematisch?

Das Upgrade von PHP 7.4 auf 8.2 oder 8.3 ist kein gewöhnliches Versionsupdate. Es ist ein Sprung über vier Major-Releases (8.0, 8.1, 8.2, 8.3), die jeweils eigene Breaking Changes mitbringen. Jede dieser Versionen hat Funktionen entfernt, Verhaltensweisen geändert oder neue Regeln eingeführt, die mit älterem Code nicht kompatibel sind.

Das Problem: All diese Änderungen treffen auf einmal, wenn du direkt von 7.4 auf 8.2+ springst. Code, der unter PHP 7.4 jahrelang stabil lief – teilweise mit Funktionen aus der PHP-5-Ära – bricht ohne Vorwarnung zusammen.

Was sich in PHP 8.x technisch geändert hat

Um die Fehlermeldungen zu verstehen, hilft ein kurzer Überblick über die relevanten Änderungen pro PHP-Version:

PHP 8.0

Striktere Typisierung – null wird nicht mehr in String-Funktionen akzeptiert. Entfernung alter Funktionen wie create_function(), each(), get_magic_quotes_gpc(). Geändertes Vergleichsverhalten bei ==.

Gefahr Hoch

PHP 8.1

Deprecation Notices bei null an internen Funktionen. Geändertes Default-Verhalten von htmlspecialchars(). Implicit Float-to-Int Warnings.

Gefahr Mittel

PHP 8.2

Dynamische Objekt-Eigenschaften erzeugen Deprecation Notices. utf8_encode()/utf8_decode() entfernt. Return-Type-Anforderungen für Built-in-Interfaces.

Gefahr Hoch

PHP 8.3

Weitere Deprecations, typisierte Klassenkonstanten – wenig Breaking Changes für WordPress.

Gefahr Gering

Das größte Risiko liegt in PHP 8.0 (Funktionsentfernungen, Typ-Striktheit) und PHP 8.2 (dynamische Eigenschaften). PHP 8.3 selbst ist selten der Auslöser für Ausfälle.

Die 7 häufigsten Fehler nach dem PHP Upgrade

Fatal Error: TypeError – null an String-Funktionen

Das ist der häufigste Grund für einen WordPress-Ausfall nach dem PHP Upgrade. PHP 8.0 hat die Typisierung interner Funktionen wie strlen(), strpos(), trim() oder strtolower() verschärft. Diese Funktionen akzeptieren kein null mehr als Argument. In PHP 7.4 wurde null stillschweigend als leerer String behandelt – in PHP 8.x gibt es einen Fatal Error, der die gesamte Seite zum Absturz bringt.

				
					Fatal error: Uncaught TypeError: strlen(): Argument #1 ($string) must be of type string, null given
in /wp-content/plugins/example-plugin/includes/class-handler.php on line 142
				
			
				
					Fatal error: Uncaught TypeError: trim(): Argument #1 ($string) must be of type string, null given
in /wp-content/themes/starter/functions.php on line 87
				
			
				
					Fatal error: Uncaught TypeError: strtolower(): Argument #1 ($string) must be of type string, null given
in /wp-content/plugins/flavor-seo/classes/meta.php on line 203

Warum das so oft vorkommt: Viele WordPress-Plugins lesen Werte mit get_option() oder get_post_meta() aus der Datenbank. Existiert der Eintrag nicht, kommt null oder false zurück. In PHP 7.4 war das kein Problem. In PHP 8.x ist es ein Totalausfall.

				
					// Vorher – funktioniert unter 7.4, Fatal Error unter 8.x
$title = get_post_meta( $post_id, '_custom_title', true );
echo strtolower( $title );

// Nachher – sicher unter allen PHP-Versionen
$title = get_post_meta( $post_id, '_custom_title', true );
echo strtolower( $title ?? '' );

Fatal Error: Call to Undefined Function

PHP 8.0 hat Funktionen endgültig entfernt, die unter 7.4 lediglich als deprecated markiert waren. Wenn ein Plugin oder Theme eine dieser Funktionen noch verwendet, gibt es einen sofortigen Fatal Error.

				
					Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc()
in /wp-content/plugins/flavor-forms/includes/submission.php on line 31
				
			
				
					Fatal error: Uncaught Error: Call to undefined function create_function()
in /wp-content/themes/starter-theme/functions.php on line 54
				
			
				
					Fatal error: Uncaught Error: Call to undefined function each()
in /wp-content/plugins/flavor-slider/includes/init.php on line 118
				
			
				
					// Alter Code (Fatal Error unter PHP 8.x)
add_action( 'widgets_init', create_function( '', 'register_widget("My_Widget");' ) );

// Korrekter Code
add_action( 'widgets_init', function() {
    register_widget( 'My_Widget' );
});

Deprecation-Flut: Dynamic Properties

Seit PHP 8.2 lösen dynamische Objekt-Eigenschaften eine Deprecation Notice aus. Das führt zwar nicht direkt zum Absturz, kann aber hunderte Einträge im Error Log erzeugen und wird in PHP 9.0 zum Fatal Error.

				
					Deprecated: Creation of dynamic property CustomPlugin\Admin::$settings is deprecated
in /wp-content/plugins/custom-plugin/admin/class-admin.php on line 45
				
			
				
					// Vorher – Deprecation Notice unter PHP 8.2+
class MeinPlugin {
    public function __construct() {
        $this->version = '1.0';   // Nie deklariert
        $this->settings = [];     // Nie deklariert
    }
}

// Nachher – korrekt deklariert
class MeinPlugin {
    public string $version;
    public array $settings;

    public function __construct() {
        $this->version = '1.0';
        $this->settings = [];
    }
}

Return Type Inkompatibilitäten

PHP 8.x verlangt Return Types bei Klassen, die Built-in-Interfaces wie Countable, Iterator oder ArrayAccess implementieren. Ältere Plugins ohne Return Types erzeugen massenhaft Deprecation Notices.

				
					Deprecated: Return type of CustomCollection::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used
in /wp-content/plugins/flavor-toolkit/includes/collection.php on line 56
				
			
				
					// Temporärer Fix – unterdrückt die Notice
#[\ReturnTypeWillChange]
public function count() {
    return count( $this->items );
}

// Dauerhafter Fix – Return Type ergänzen
public function count(): int {
    return count( $this->items );
}

Stille Logik-Fehler: Geändertes Vergleichsverhalten

Dieser Fehler ist besonders tückisch, weil er keine Fehlermeldung erzeugt. PHP 8.0 hat das Verhalten des ==-Operators bei Vergleichen zwischen Strings und Zahlen grundlegend geändert.

				
					Deprecated: Return type of CustomCollection::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used
in /wp-content/plugins/flavor-toolkit/includes/collection.php on line 56
				
			
				
					// PHP 7.4
0 == "foobar"   // true   → String wird zu 0 konvertiert
0 == ""          // true

// PHP 8.x
0 == "foobar"   // false  → kein numerischer String, kein Vergleich
0 == ""          // false
				
			
				
					$role = get_user_meta( $user_id, 'custom_role', true );

switch ( $role ) {
    case 'admin':
        // PHP 7.4: Wenn $role = 0 → matcht auf 'admin' (0 == "admin" war true!)
        // PHP 8.x: Matcht nicht mehr → Nutzer verliert Zugang
        grant_admin_access();
        break;
}

// Fix: Strikten Vergleich === verwenden oder Variable vorher casten

htmlspecialchars() Probleme

Ab PHP 8.1 akzeptiert htmlspecialchars() kein null mehr und das Default-Flag hat sich geändert. Das betrifft viele Themes, die diese Funktion direkt aufrufen.

				
					Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated
in /wp-content/themes/starter-theme/header.php on line 19

Sichtbare Auswirkung: Ungültige UTF-8-Sequenzen werden durch das Unicode-Ersetzungszeichen (�) ersetzt statt als leerer String behandelt. Das kann zu sichtbaren Darstellungsfehlern auf der Website führen – selbst wenn kein Fatal Error auftritt.

Serialisierungsfehler in der Datenbank

PHP 8.x ist strenger bei der Verarbeitung serialisierter Daten. WordPress speichert viele Einstellungen serialisiert in der wp_options-Tabelle – darunter Widget-Konfigurationen, Plugin-Einstellungen und Transients.

				
					Warning: unserialize(): Error at offset 168 of 1894 bytes
in /wp-includes/option.php on line 89

Wenn diese Daten durch fehlerhafte Migrationen oder Suchen-und-Ersetzen-Aktionen (z.B. Domainwechsel) korrupt geworden sind, treten unter PHP 8.x Fehler auf, die unter 7.4 noch toleriert wurden.

Weiße Seite nach dem PHP Upgrade – Erste Hilfe in 5 Minuten

Der WordPress White Screen of Death (WSOD) nach einem PHP Upgrade ist fast immer ein Fatal Error in einem Plugin oder Theme. So findest du die Ursache:

Error Log prüfen

Verbinde dich per FTP oder SSH und prüfe /wp-content/debug.log. Ist der Debug-Modus nicht aktiv, füge in der wp-config.php folgendes ein:

				
					define( 'WP_DEBUG', true ); 
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

PHP zurückschalten

Wenn die Seite dringend wieder online muss: PHP-Version im Hosting-Panel (cPanel, Plesk, etc.) sofort auf 7.4 zurücksetzen. Das ist ein Workaround, keine Lösung – PHP 7.4 bekommt keine Sicherheitsupdates mehr.

Plugins per FTP deaktivieren

Den Ordner /wp-content/plugins/ per FTP in plugins_disabled umbenennen. Wenn die Seite danach funktioniert: Ein Plugin ist schuld. Ordner zurückbenennen und Plugins einzeln deaktivieren. Das kann man auch ganz einfach per FTP erledigen, einfach den Ordnernamen des Plugins mit einem Unterstrich ändern und schon deaktiviert WordPress das betroffene Plugin automatisch.

Theme wechseln

Wenn Plugins nicht das Problem sind: Den aktiven Theme-Ordner unter /wp-content/themes/ umbenennen. WordPress fällt auf ein Default-Theme (Twenty Twenty-Four) zurück.

So gelingt das PHP Upgrade ohne Ausfall

Phase 1 – Vorbereitung

  1. Vollständiges Backup anlegen

    Datenbank (SQL-Export) und gesamter wp-content-Ordner. Beides separat sichern und die Wiederherstellung vorher testen.

  2. Staging-Umgebung aufsetzen

    Eine vollständige Kopie der Live-Website erstellen. Auf der Live-Seite wird niemals direkt getestet.

  3. WordPress Core aktualisieren

    Mindestens Version 6.4 wird für PHP 8.2+ empfohlen. Ältere WordPress-Versionen haben selbst Inkompatibilitäten.

  4. Alle Plugins und Themes aktualisieren

    Vor dem PHP-Switch alles auf den neuesten Stand bringen.

  5. Kompatibilitätsprüfung durchführen

    Per WordPress-Plugin oder über die Kommandozeile mit PHPCompatibility:

    # PHPCompatibility installieren
composer global require phpcompatibility/phpcompatibility-wp

# Plugins prüfen
phpcs --standard=PHPCompatibilityWP \
      --runtime-set testVersion 8.2 \
      wp-content/plugins/

Phase 2 – Der Umstieg

  1. Debug-Modus auf der Staging-Umgebung aktivieren

    PHP – wp-config.php

     
    define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
  2. PHP schrittweise hochziehen

    Wenn möglich: zuerst 8.0, dann 8.1, dann 8.2. Bei jedem Schritt das Error Log prüfen – so lassen sich Fehler der jeweiligen Version zuordnen.

  3. Logs systematisch auswerten

    Die Datei /wp-content/debug.log nach jeder PHP-Version auf diese Schlüsselwörter durchsuchen: Fatal error (Seite ist down), Deprecated (funktioniert noch, bricht aber zukünftig), Warning (potenzielles Problem) und Notice (geringes Risiko).

Phase 3 – Nach dem Umstieg

  1. Kritische Funktionen testen

    Checkout (WooCommerce), Kontaktformulare, Login/Registrierung, Admin-Bereich, REST API, Cron-Jobs.

  2. Performance dokumentieren

    PHP 8.x bringt messbare Performance-Verbesserungen durch den JIT-Compiler. Ein Vorher-Nachher-Vergleich mit Query Monitor oder GTmetrix dokumentiert den Gewinn.

  3. Debug-Modus auf Live deaktivieren

    Error Log in den ersten Tagen nach dem Switch aktiv überwachen.

FAQ: Häufig gestellte Fragen zum PHP Upgrade

Technisch ja, aber der direkte Sprung birgt das höchste Risiko. Empfohlen ist der schrittweise Weg über 8.0 → 8.1 → 8.2 auf einer Staging-Umgebung. So lassen sich Fehler besser isolieren und der jeweiligen PHP-Version zuordnen.

Wenn die Seite bereits down ist: PHP-Version im Hosting-Panel sofort auf 7.4 oder 8.0 zurücksetzen, Backup erstellen und das Upgrade dann auf einer Staging-Umgebung testen. Viele Hoster (z.B. All-Inkl, Ionos, Raidboxes) bieten die PHP-Versionswahl direkt im Kundenbereich an.
In den meisten Fällen nicht dauerhaft. Der White Screen of Death entsteht durch einen Fatal Error in einem Plugin oder Theme. Über FTP kannst du das Problem isolieren, indem du den plugins-Ordner umbenennst und Plugins einzeln reaktivierst.
Meistens reicht ein Plugin-Update allein, sofern der Entwickler PHP 8.x Kompatibilität hergestellt hat. Bei Plugins ohne aktive Wartung – also ohne Update seit 2023 – ist ein Wechsel auf eine Alternative oft die bessere Lösung als ein manueller Patch.
WordPress 6.4 oder höher wird empfohlen. Ältere Versionen haben selbst Kompatibilitätsprobleme mit PHP 8.x. Vor dem PHP-Upgrade sollte immer zuerst der WordPress-Core aktualisiert werden.
Erhebliche. PHP 8.x bringt durch den JIT-Compiler spürbare Performance-Verbesserungen. Dazu kommen aktive Sicherheitsupdates, modernere Sprachfeatures und bessere Fehlerbehandlung. Die Investition lohnt sich langfristig.
Am einfachsten über das Changelog auf wordpress.org. Steht dort nichts zu PHP 8.x und das letzte Update liegt vor 2023, ist das ein Warnsignal. Das CLI-Tool phpcs mit dem PHPCompatibilityWP-Standard kann Plugin-Code automatisiert auf bekannte Probleme scannen.

Fazit

Ein WordPress-Ausfall nach dem PHP Upgrade von 7.4 auf 8.2+ ist kein Zufall und kein Pech – es ist das erwartbare Ergebnis, wenn Legacy-Code auf eine moderne PHP-Version trifft. Die gute Nachricht: Die Probleme sind gut dokumentiert, die Fehlermeldungen sind eindeutig und die Lösungen sind in den meisten Fällen überschaubar.

Die goldene Regel: Staging-Umgebung nutzen, Debug-Log aktivieren, schrittweise testen – und kein Plugin ohne bestätigte PHP 8.2+ Kompatibilität auf der Live-Seite laufen lassen.
 
Keine Lust alles selbst zu machen? Ich unterstütze Kunden bei der Umstellung von PHP Versionen und bei technischen Problemen aller Art:
Kontakt
office@osulzer.at
+43 660 370 3392

Bürozeiten:
Montag – Donnerstag: 9:00 – 17:00 Uhr
Freitag: 9:00 – 14:00 Uhr