WordPress & PHP 8: ABSPATH-Warning und »cannot decode raw data«-Error beheben

Lang, lang hab ichs hinausgeschoben, das Upgrade auf PHP 8 bzw. PHP 8.1. Beim ersten schnellen Versuch vor ein paar Monaten ging nämlich gar nichts mehr: Einerseits erschien – wenn überhaupt – für ABSPATH ein »Already defined«-Warning, meistens lud der Browser aber die Seite erst gar nicht und lieferte einen »cannot decode raw data«-Error. So behebt ihr das Problem.

Nach der Umstellung auf PHP 8 geht zunächst nichts mehr.

Letzteres sollte ich vielleicht präzisieren: Rief ich meine Seiten mit einem Parameter hinter dem Trailing-Slash auf, also z.B. mit /?blabla, wurde die Seite gerendert – mit besagtem ABSPATH-Warning:

Warning: Constant ABSPATH already defined in wp-config.php […]

Die Warnung gab es auch schon in PHP 7.4, konnte man aber mittels error_reporting(0); ohne weitere Konsequenzen ausblenden (ich weiß, keine schöne Lösung).

Cannot decode raw data + NSURLErrorDomain 1015

Die Warnung wäre mir auch noch egal gewesen, dass Seiten beim direkten Aufruf aber gar nicht mehr angezeigt werden und Safari eine graue Seite mit »›cannot decode raw data‹ NSURLErrorDomain:-1015« wirft (siehe Screenshot oben) war ein No-go und so schob ich das Problem erst einmal auf die lange Bank.

Da der Support für PHP 7.4 aber offiziell mit Ende November 2022 ausläuft, wollte ich die Sache noch einmal angehen. Und siehe da, die beiden Probleme hängen zusammen!

Man findet nämlich zwar einige Support-Threads zu beiden Problemen, unter anderem:

• Dass es an der Sprachdatei liegt,
• am Encoding der wp-config.php
• oder auch an Cookies bzw. gzip-Einstellungen etc.

All das war bei mir aber nicht der Fall.

Den entscheidenden Hinweis fand ich in einem Thread, der von Encoding-Problemen ausgeht. Daran lag es in meinem Fall zwar wie gesagt nicht, aber User bscu schreibt bzgl. der wp-config.php:

Da sollte eigentlich u.a. sowas drin stehen:

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

Da klingelte es bei mir. Die letzten Zeilen der wp-config.php sahen bei mir nämlich seit Jahren so aus:

define('ABSPATH', dirname(__FILE__).'/');
require_once(ABSPATH.'wp-settings.php');

Sprich, vor der Definition von ABSPATH wurde nicht geprüft, ob die Konstante schon definiert wurde. Also dachte ich, bevor ich mich um das schwerwiegendere »Cannot decode raw data«-Problem kümmere, behebe ich zuerst das leidige Warning.

Stattdessen sollte also korrekt folgender Code stehen:

/* That's all, stop editing! Happy blogging. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', dirname( __FILE__ ) . '/' );
}
/** Sets up WordPress vars and included files. */
require_once( ABSPATH . 'wp-settings.php' );
?>

Und siehe da, der Fehler mit »Cannot decode raw data« verschwand dadurch auch!

Ich vermute, dass die Ausgabe der Fehlermeldung durch PHP 8 (im Gegensatz zu PHP 7) irgendwas beim HTML-Rendering durcheinander bringt und so der Fehler entsteht. Warum das nicht der Fall ist, sobald man irgendeinen Parameter an die URL hängt … keine Ahnung. 🤷‍♂️

WordPress’ Aktualisierungsproblem

Das ist leider ein grundsätzliches Problem von WordPress, das mich – wenn ich mich richtig erinnere – auch früher schon einmal betroffen hat: Die automatische Aktualisierung updated zwar brav alle WordPress-Dateien, lässt die wp-config.php aber unverändert.

Ändert sich da drin aber einmal was Grundlegendes, so wie zum Beispiel, dass ABSPATH bereits vor Aufruf der wp-config.php definiert werden kann (evtl. durch Plugins?), funktioniert die ganze WordPress-Installation nicht mehr.

Da die wp-config.php die eigenen Credentials enthält, ist ein Update durch WordPress zwar nicht immer leicht möglich. Bei grundsätzlichen Änderungen einen Hinweis im WP-Admin-Interface zu liefern, sollte aber drin sein.

Tipp: Immer mit wp-config-sample.php vergleichen

Daher wichtig: Nach jedem WordPress-Update prüfen, ob in der wp-config-sample.php neuer Code dazugekommen ist, den ihr bei eurer produktiven wp-config.php nachziehen müsst!