Beiträge von b3317133

Alternativ stelle sicher, das die [FONT=Courier New]debug.log[/FONT] Erstellung nur dann angeschaltet wird, wenn wirklich an der Seite geabeitet wird,was generell so sein sollte. Das löst das eigentliche Problem nicht, aber es flutet dann auch nicht dauerhaft Deine Log Dateien.

Normalerweise kann man die PHP Version beim Provider über den Zugang zum Account dort selbst einstellen. Deine Seite sollte aktuell wie mehrfach beschrieben mit maximal PHP 8.1.x laufen.

Irgendjemand hat die Seite eingerichtet, versuche diese Person ausfindig zu machen.

Ok, dann weisst Du ja Bescheid wie man das dort sieht. Ähnliches wurde Dir offenbar auch schon anderweitig gesagt. Nicht immer sind solche Sichtweisen und/oder Entscheidungen bei den WordPress Entwicklern nachvollziehbar.

Rückwärtskompatiblität wie früher ist offenbar nicht mehr wirklich gewünscht, vielleicht will man die Nutzer auch so irgendwie aus den "Klassischen Themes" bekommen, man weiss es nicht. Das Problem war z.B. auch in allen klassischen Twenty XXX Standard Themes vorhanden und wird daher wohl auch in allen Themes vorhanden sein, die ihren Code und wenn auch nur grob darauf basiert haben.

Würde empfehlen, im vorherigen WordPress Zweig zu bleiben, bis die Probleme seitens der Plugins oder irgendwann doch seitens des Core gelöst werden. Sicherheitsrelevante Updates bekommst Du auch mit WordPres 6.6.x noch viele Monate.

Aus dem Log geht nur hervor, das wohl immer noch eine zu neue PHP Version eingestellt ist, siehe Hinweise dazu oben.

Wie gesagt, in diesem Fall hier wäre es gesamt besser, jemanden lokal bei Dir zu finden, der sich mit WordPress etwas auskennt. Ein Hack ist weiterhin nicht ausgeschlossen.

Man würde nach einem Fatal Error suchen.

Aber zuerst würde man die o.g. PHP Version auf maximal PHP 8.1.x einstellen, vermutlich läuft eine zu neue PHP Version für Dein Theme/Plugins, dann hätte man ein viel kürzeres Error Log.

Lösche das Log, rufe direkt danach den Login auf, lese das neu angelegte Log.

Auch daran kann es liegen, dazu könnte man mehr sagen, wenn man das Error Log zu dem exakten Zeitpunkt wenn die weisse Seite erscheint hätte.

Evtl. wäre es hier am besten, das jemanden vor Ort genauer prüfen zu lassen, der sich mit WordPress etwas auskennt.

Ok, dann wäre es auch möglich, dass die Seite gehackt wurde und der Hack jetzt nicht (mehr) richtig funktioniert und so diverse Dinge schieflaufen.

Wende Dich am besten an die Person, die die Seite ursprünglich eingerichtet hat bzw. technisch betreut und lasse das mal ansehen.

Erstelle ein Bug Report Ticket bei WordPress.org https://core.trac.wordpress.org/tickets/latest

In dem Auszug ist kein Eintrag, der eine weisse Seite erzeugt.

Beachte auch noch den Absatz oben zur PHP Version:

Zitat von b3317133

Und evtl. wurde eine zu neue PHP Version für ggf. veraltete Plugins bzw. Theme eingestellt, auch das kann zu Problemen wie den vielen Deprecated Log Einträgen führen, hier sollte maximal PHP 8.1.x eingestellt und die Kompatibilität aller Plugins und des Themes hierzu geprüft werden, hierzu auch Kontakt mit dem Support von gekauften Komponenten aufnehmen, ob es passende Updates gibt.

Weche PHP Version ist derzeit eingestellt? Werkzeuge > Website-Zustand > Bericht (oben auswählen) > Server > PHP-Version

Was genau erscheint im Error Log zu dem Zeitpunkt wenn die weisse Seite bei Plugins erscheint?

Die Inhalte der alten Webseite werden durch Zurückstellen der Datenbankzugangsdaten auf die alte Datenbank in [FONT=Courier New]wp-config.php[/FONT] wiederhergestellt.

Das übliche Vorgehen bei WordPress ist:

1. Export der Daten aus der alten Datenbank mit phpMyAdmin
2. Import der Daten in die neue Datenbank mit phpMyAdmin
3. Änderung der Datenbankzugangsdaten in [FONT=Courier New]wp-config.php[/FONT]

@KuSin Durch ständige Änderung und Erweiterung von Backend, Blöcken, FSE (Front Site Editing) usw. ist sowas wohl vielen ehem. freiwilligen Blogschreibern, Tutorial Erstellern u.ä. ein zu grosser Aufwand geworden. Zudem sinkt wegen anderweitigen Vorkommnissen (Link enthält eine grobe Übersicht, es gibt noch viele weitere Beiträge dazu) seit einiger Zeit die Motivation einiger Teile der weltweiten Community merklich.

Zitat von b3317133

Vermutlich ist die Links-Anpassung nach dem Entfernen der Inhalte im Unterverzeichnis [FONT=Courier New]wordpress[/FONT] nicht vollständig vorgenommen worden. Siehe ergänzte Fragen 5 und 6 oben.

Beantworte noch die Fragen 5 und 6 oben.

Unabhängig von der eigentlichen Ursache des 403 Fehlers des Servers fehlt noch die Anpassung einiger URLs in der Datenbank wo noch [FONT=Courier New]wordpress[/FONT] vorkommt, das kann man nach dem sicherheitshalber Erstellen eines Backups der Datenbank z.B. so machen:

1. Plugin Better Search Replace installieren und aktivieren
2. Auf der Seite des Plugins im WordPress Backend alle Tabellen anwählen und (ohne [FONT=Courier New]/[/FONT] Zeichen am Ende)
   
   
   Code

   Suchen nach: https://zauberer-kabarettist.de/wordpress
   Ersetzen durch: https://zauberer-kabarettist.de

3. Browser Cache leeren

Eine (zu allgemeine) CSS Regel [FONT=Courier New].menu *[/FONT] stammte lt. Browser Inspector aus einer in der Seite eingebundenen CSS-Datei im Verzeichnis dieses Plugins.

Je nach Hack können Datenbanken auch Schadcode enthalten.

Du kannst die Datenbanken vermutlich auch manuell löschen, nur könnten dann generell noch anderweitige Reste von dieser Assistenten Installation im Hosting vorhanden sein, daher der Hinweis.

Deaktiviere temporär das Plugin caldavlist, behebt das das Problem?

Falls ja, versuche es mit diesem Code in Design > Customizer > Zusätzliches CSS mit wieder aktiviertem Plugin falls es benötigt/verwendet wird.

#access .menu * {
  margin-bottom: inherit;
}

Lt. dem o.g. Pfadteil [FONT=Courier New]clickandbuilds [/FONT]wurden die Seiten und Datenbanken mit einem WordPress Assistenten bei IONOS angelegt, darüber sollet man sie wieder löschen können, dann weden vermutlich die Domainverknüpfung, Dateien und Datenbank entfernt. Im Zweifel den Hosting Support ansprechen.

Inzwischen wurde bekannt, dass die eigentlichen Gründe für die fehlende Aktualität der Wordfence Scan-Listen doch noch andere waren, wie nach vielen Spekulation wegen teils tausender von "false positive" Meldungen pro Installation von den Wordfence Autoren inzwischen (leider erst nach vielen erst unbeantworteten Hinweisen) im Wordfence Support Forum eingeräumt wurde:

Zitat

... What happened on our end is that, due to recent rate limiting on the repository, the process that mirrors new core releases did not complete normally and stopped halfway. Our application servers told the Wordfence plugin that we DID have a complete mirror with associated hashes, but we in fact did not. Once we discovered the issue we ran the process to completion manually which fixed the issue this time around. We’ve also put additional alerting in place to let us know if this happens in future. ...

Die "false positive" Meldungen sollten daher auch ohne sonstige Interaktion beim nächsten Scan nicht mehr erscheinen.

Erstelle eine neue [FONT=Courier New].htaccess[/FONT] Datei im Hauptverzeichnis mit dem folgenden Inhalt, dann sollten die Permalinks im Frontend wie gewohnt funktionieren und Du kannst alle Plugins wieder aktivieren:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>


# END WordPress