Strato stellt PHP um - Wordpress nicht mehr erreichbar

[Foos]

Hey Leute,

ich habe heute folgende Mail von Strato erhalten. (Dort habe ich alle meine Worpress Seiten laufen)

Wenn ich nun auf 8.0 oder 8.1 einstelle dann erscheint bei meinen Wordpress-Installtionen nur noch eine weiße Seite mit "kritischem Fehler". Aber Version 7.x lassen für diesen monatlichen Betrag find ich irgendwie ziemlich crazy.

Könnt ihr mir helfen? Was muss man tun oder kommt da ein Wordpress Update?

PHP Extended Support: PHP 7.4 wird kostenpflichtig Sie setzen mit Ihren Websites auf die Skriptsprache PHP in der Version 7.4. Die PHP Community entwickelt PHP ständig weiter und kümmert sich bei aktuellen Versionen auch um die Sicherheit. Seit Dezember 2022 ist PHP 7.4 veraltet und die PHP Community stellt keine Sicherheitsupdates mehr zur Verfügung. Um Ihre Websites vor Angriffen zu schützen, kümmert sich STRATO aktuell um die Sicherheit von PHP 7.4. Da durch die Pflege einer veralteten PHP-Version jedoch zusätzlicher Wartungsaufwand entsteht, wird die Nutzung von PHP 7.4 ab dem 07.02.2023 kostenpflichtig. ​ ► Wechseln Sie bei allen aufgeführten Aufträgen auf eine aktuelle PHP-Version oder aktivieren Sie den PHP Extended Support, um PHP 7.4 weiterhin zu verwenden. ► Option 1: Auf eine aktuelle, kostenfreie PHP-Version wechseln Wählen Sie bis zum 06.02.2023 eine aktuelle PHP-Version (PHP 8.0 oder höher) für Ihre Pakete aus. Prüfen Sie Ihre Websites nach einem Wechsel der PHP-Version auf Funktionalität. Möglicherweise müssen Ihre Web-Anwendungen aktualisiert werden, damit sie mit einer aktuellen PHP-Version funktionieren. ​ ► Option 2: PHP 7.4 kostenpflichtig weiter nutzen Aktivieren Sie bis zum 06.02.2023 den PHP Extended Support für Ihre Aufträge. Ab dem 07.02.2023 werden wir Ihnen die Nutzung von PHP 7.4 mit 7,81 Euro pro Auftrag pro Monat in Rechnung stellen. ​

 

[Mr_Quick]

Hallo

Das Problem hat mein Kunde im Moment ebenfalls.
Da muss ich auch mal schauen wie man das lösen kann.

Welche Wordpress Version hast Du bitte?

thx

 

[Foos]

Hallo

Das Problem hat mein Kunde im Moment ebenfalls.
Da muss ich auch mal schauen wie man das lösen kann.

Welche Wordpress Version hast Du bitte?

thx

6.1

 

[Mr_Quick]

OK, mein Kunde hat 6.1.1

 

[Foos]

OK, mein Kunde hat 6.1.1

ok, ich auch

Aber was hilft uns das nun?

 

[Mr_Quick]

Zitat aus einer Webseite:

PHP 8.0 gibt es seit November 2020, das war etwa einen Monat vor dem Erscheinen von WordPress 5.6. PHP 8.1 wurde im November 2021 veröffentlicht, zwei Monate vor dem Erscheinen von WordPress 5.9. In der Zwischenzeit wurden noch WordPress 6.0 und 6.1 veröffentlicht. Schon allein deswegen kannst du recht sicher sein, dass es zwischen den aktuellen Versionen von WordPress und PHP keine nennenswerten Probleme geben sollte. Zumindest sind uns aus der Praxis keine bekannt.

Wo allerdings Probleme auftreten können, sind bei Themes und Plugins. Vor bei den älteren Exemplaren, was an sich logisch ist. Wenn ich ein Theme oder Plugin entwickelt habe, als PHP 8.0 noch in der Planung war und seitdem keine Aktualisierung nachgereicht habe, dann ist die Gefahr hoch, dass es Probleme mit den neuen PHP-Versionen geben könnte.

 

[TPHeinz]

Moin,
Strato, WP 6.1.1 Theme Academica
bei der Seite half es in der wp-config.php
define(‘WP_POST_REVISIONS’,0);
zu entfernen.

 

[Stefan]

Probiere mal den Debug-Modus in der wp-config.php zu aktivieren, dann siehst du auch, was da wirklich los ist!

 

[EdKraim]

Moin,...
Kann ich auch bestätigen, dass die Probleme von Theme oder von älteren Plugins kommen.
Abhilfe schafft normalerweise die Aktualisierung der Themes und Plugins, sofern verfügbar. Wenn möglich, alle Plugins deaktivieren, anderes Theme aktivieren und schauen ob es läuft. Dann kann man nacheinander die Plugins aktivieren.
Das grenzt den Übeltäter schon mal ein, wenn man nicht programmieren kann

 

[oonykrowoo]

Leider habe ich genau das selbe Problem...
Wordpress und alle Plugins sind auf dem neusten Stand.
Ich habe vor der Umstellung sogar alle Plugins deaktiviert und auf ein Standart-Theme umgestellt. Weder auf PHP 8.0 noch auf 8.1 oder 8.2 funktioniert das Frontend. Ins Backend komme ich und bekomme dort auch immer folgendes angezeigt:
REST-API-Endpunkt: https://xy.de/wp-json/wp/v2/types/post?context=edit
REST-API-Antwort: (500) Internal Server Error

Den Debug-Modus habe ich an, dort gibt mir das Log bei PHP 8.0 nichts aus - bei PHP 8.1 oder 8.2 steht folgendes drin:

[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Cookie_Jar:ffsetExists($key) should either be compatible with ArrayAccess:ffsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Cookie/Jar.php on line 63
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Cookie_Jar:ffsetGet($key) should either be compatible with ArrayAccess:ffsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Cookie/Jar.php on line 73
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Cookie_Jar:ffsetSet($key, $value) should either be compatible with ArrayAccess:ffsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Cookie/Jar.php on line 89
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Cookie_Jar:ffsetUnset($key) should either be compatible with ArrayAccess:ffsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Cookie/Jar.php on line 102
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Cookie_Jar::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Cookie/Jar.php on line 111
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary:ffsetExists($key) should either be compatible with ArrayAccess:ffsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 40
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary:ffsetGet($key) should either be compatible with ArrayAccess:ffsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 51
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary:ffsetSet($key, $value) should either be compatible with ArrayAccess:ffsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 68
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary:ffsetUnset($key) should either be compatible with ArrayAccess:ffsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 82
[12-Jan-2023 18:38:31 UTC] PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /mnt/web224/e0/57/58227557/htdocs/WordPress_01/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 91

 

[oonykrowoo]

sorry doppelpost...

 

[webmaus]

Ganz easy! Wir sind Webentwickler, für Drupal, und dort haben uns diverse Kunden und Leute der Community angeschrieben.
Lösung: Provider wechseln. Mit all-inkl oder Webhostone gibt es das Problem nicht, die haben Alternativen. Strato ist für uns eh schon seit vielen Jahren out. Sorry, aber das muß ich aus diesem Anlaß hier mal ganz deutlich sagen.

 

[hassijun]

Ganz easy! Wir sind Webentwickler, für Drupal, und dort haben uns diverse Kunden und Leute der Community angeschrieben.
Lösung: Provider wechseln. Mit all-inkl oder Webhostone gibt es das Problem nicht, die haben Alternativen. Strato ist für uns eh schon seit vielen Jahren out. Sorry, aber das muß ich aus diesem Anlaß hier mal ganz deutlich sagen.

Ich schließe mich meinem Vorredner an... ich führe ebenfalls eine Werbeagentur und arbeite mit IONOS. Dort kann ich zumindest im Falle des Falles kurzfristig (geht auch nur einen Monat) die alte PHP Version lassen, damit ich genügend Zeit habe das in Ruhe umzustellen und zu überprüfen, welches Plugin oder Theme Probleme macht. Wer hier Hilfe benötigt, darf sich gerne bei mir melden.

Werbeagentur www.hassijun.com

 

[fritzeken]

Guten Abend,
ich benutze die WP aktuelle Version 6.1.1, die ich nach Umstellung auf PHP 8.0 aktualisiert habe: vorher Störung (keine Bilder, keine Funktion), nachher störungsfreier Betrieb inkl. aller Plugins, Theme Twenty Fourty.
FvS

​

 

[TPHeinz]

naja, die Termine zum Umstellen stehen lange vorher fest, die verliert man nur leicht aus den Augen.
Bei Strato ist die Übergangszeit wohl auch vom 28.11.2022 bis jetzt noch 31. Jan kostenfrei.

Der PHP Extended Support: Das bringt er Ihnen | STRATO

In diesem Artikel erklären wir Ihnen, was der STRATO PHP Extended Support ist, wie er funktioniert und welche Vorteile er Ihnen bietet.

www.strato.de

Ionos berechnet den extended Support wie so vieles andere auch gerne extra.

 

[Mr_Quick]

Ich und viele anderen mögen Strato nicht.
Leider hilft dies keinem weiter.

Bitte helft dem TE doch

 

[TPHeinz]

Foos war am Dienstagabend zum letzten Mal hier aktiv und die Seite von oonykrowoo (xy de) konnte ich schon am nächsten vormittag problemlos aufrufen.

 

[oonykrowoo]

Hi - ja weil ich die Seite wieder auf 7.4 gestellt habe damit sie wenigstens erreichbar ist.
Stelle ich auf 8.x um, dann ist sie wieder down

 

[pixelmaker]

Hallo
ver nix bezahlt ist dem Provider ausgeliefert.
Auf meinen Servern laufen auch alte PHP Versionen noch weiter. Technisch ist das kein Problem. Mit dem weiter laufen lassen von PHP 7.4 Geld zu schneiden, auf die Idee bin ich noch gar nicht gekommen.
Es ist ja auch nicht so das PHP 7.4 nun schlagartig nicht mehr funktioniert, nur der Community Support ist zu Ende.

Was ich von Plesk kenne ist eine Sicherheitswarnung: "WordPress <= 6.1.1 - Unauth. Blind SSRF vulnerability".
Das Problem ist aktuell in WP nicht behoben, die Gefahr wird als niedrig eingestuft.

Um die Schwachstelle zu beheben gibt es zwei empfohlene Möglichkeiten.
1. Den Zugriff auf xmlrpc.php auf der Ebene des Webservers zu blockieren.
Das kann ich in Plesk für jede Domain im Wordpress-Toolkit abschalten.

2. Als vorübergehenden Workaround empfehlen wir Systemadministratoren, den Handler pingback.ping des XMLRPC-Endpunkts zu entfernen. Eine Möglichkeit, dies zu tun, besteht darin, die functions.php des verwendeten Themes zu aktualisieren und den folgenden Aufruf einzuführen:

add_filter('xmlrpc_methods', function($methods) {
  unset($methods['pingback.ping']);
  return $methods;
});

Soweit ich weiß gibt Plesk trotz Deaktivierung von Pingback / xmlrpc.php die Warnung weiter aus, obwohl die Gefahr damit gebannt ist. Ich käme aber nie auf die Idee bei so einer schwachen Warnung direkt die ganze Seite zu blockieren.
Es gibt auch jeweils immer nur eine Sicherheitswarnung per Mail nach Neuinstallation eines WP Systems.

Ob das den "kritischen Fehler" bei Euch auslöst kann ich nicht sagen. Ich finde es seltsam das hier keine Aussage von Strato dazu zu lesen ist.
Ansonsten laufen bei mir alle Wordpress-Systeme die einigermaßen aktuell gehalten sind sauber bis PHP 8.1.14.
8.2 ist in Plesk noch nicht

grüße
ralfg

 

[oonykrowoo]

Hallo Zusammen,
da ich den Fehler nun beheben konnte, hier eventuell als Hilfe für andere mit ähnlichen Problemen:
Ich habe die Webseite komplett bei einem anderen Hoster gespiegelt und hatte unter PHP 8.1 weiterhin das gleiche Problem. Ich habe daraufhin alle Plugins gelöscht, sowie das Hello Elementor Theme gelöscht. Per FTP habe ich unter Plugins die Überreste der gelöschten Plugins händisch entfernt.
Unter Aktualisierungen habe ich Wordpress 6.1.1 dann nochmal neu drüber installiert, die htaccess im root-Ordner gelöscht und unter Permalinks ohne Änderungen vorzunehmen die Änderungen nochmals gespeichert, wodurch eine neue htaccess automatisch erstellt wurde.
Danach hat die Webseite unter PHP 8.1 funktioniert und läuft weiterhin auch nachdem wieder alle notwendigen Plugins und das Theme erneut installiert wurden.
Vielen Dank für die vielen konstruktiven Vorschläge!