- Fehleranalyse
- Debugging
- Fehler
- Weitere Fehler und Lösungen aus der REDAXO-Community
- Troubleshooting CSRF-Token
Auch eine REDAXO-Installation kann einmal „Schluckauf“ haben. Im Folgenden werden Möglichkeiten aufgezeigt, deine REDAXO-Installation zu reparieren.
Im Rahmen einer REDAXOHour ist eine Video Einführung entstanden, die viele Punkte dieses Kapitels erklärt.
Hinweis: Wir empfehlen auch vor einem Fehler, regelmäßige Backups zu erstellen. Datenbank-Backups können automatisiert über das Cronjob-AddOn erstellt werden.
Ein Ooops oder Whoops wird ausgegeben, wenn es zu einem kritischen Fehler gekommen ist, z.B. einem E_ERROR. Mit aktiviertem Debug-Modus auch bei E_WARNING, E_NOTICE.
Wenn ein Administrator eingeloggt ist, oder der Administrator den Debug-Modus aktiviert hat, wird anstelle des Ooops ein Whoops mit genauerer Fehlerbeschreibung und Stacktrace ausgegeben, um die Fehlersuche zu vereinfachen.
Allgemeine Ooops-Fehlerseite im Frontend (links) und im Backend (rechts)
Tritt ein Fehler auf, meldet REDAXO sich im Frontend mit einem Ooops und im Backend mit einem Rrrrroar.
Whoops-Fehlerseite mit Debug-Informationen
Die Whoops-Meldung liefert die Codestellen und Fehlermeldungen zum aufgetretnenen Fehler. Die Infos können zudem kopiert werden.
Mit dem 'Report a bug Button' auf der Whoops Fehlerseite kann, falls erforderlich direkt ein Issue im REDAXO GitHub-Repo angelegt werden. Bitte nur verwenden, wenn man sich sicher ist, dass es sich um einen Bug im Core handelt.
In der Datei redaxo/data/core/system.log werden Fehler geloggt - möglicherweise ist der Fehler bereits dabei. Diese wird auch unter System > Logdateien angezeigt.
Ergebnis einer dump()-Ausgabe
Anstelle von var_dump() kann im REDAXO-Kontext die Funktion dump() verwendet werden, um die Ausgabe einer Variablen, eines Objekts oder eines anderen Datentyps im Frontend auszugeben. Der Vorteil besteht darin, dass die Ausgabe HTML-formatiert ist und dadurch schneller erfasst und durchsucht werden kann.
Wenn der ausgewertete Inhalt komplex ist, sollte man das lokale Suchfeld verwenden, um nach bestimmten Variablen oder Werten zu suchen. Hierzu klickt man auf eine beliebige Stelle im Dump-Inhalt und drückt dann Strg. + F oder Cmd. + F, damit das lokale Suchfeld erscheint. Alle gängigen Tastenkombinationen zur Navigation in den Suchergebnissen werden unterstützt (Strg + G oder Cmd + G, F3 usw.) Nach Abschluss der Suche lässt sich das Feld mit Esc wieder ausblenden.
Woran erkennt man, dass der Debug-Modus eingeschaltet ist?
Im Debug-Modus werden zur Laufzeit weitere Informationen gesammelt und im Fehlerfall ausgegeben. Exceptions werden als Whoops ausgegeben und helfen so dem Entwickler, Fehler zu beseitigen und Probleme zu erkennen.
Der Debug-Modus kann über die config.yml verschärft werden: über die Eigenschaft throw_always_exception: true werden auch einfache Notices (E_WARNING, E_NOTICE) als Whoops ausgegeben. Die Vorteile liegen auf der Hand: So wird man bei der Entwicklung von Modulen, Templates oder AddOn-Code u.a. frühzeitig darauf aufmerksam, wenn Methoden und Funktionen in PHP verwendet werden, die bereits als deprecated markiert und bei einem Update der PHP-Version zu Fehler führen werden.
Der Debug-Modus darf unter keinen Umständen aktiviert werden, wenn die Website öffentlich zugänglich ist. Denn der Debug-Modus ist öffentlich und nicht nur eingeloggte Administratoren erhalten eine Fehlermeldung und die darin exponierten Informationen.
Wir empfehlen, die Seite vorher durch einen .htpasswd -Verzeichnisschutz o.ä. zu schützen oder zumindest in einen Wartungsmodus zu versetzen, bspw. durch das AddOn maintenance . Zum Schutz von Entwickler und Betreiber werden im Debug-Modus alle header auf noindex gesetzt, um auch Suchmaschinenen daran zu hindern, sensible Daten durch die Debug-Ausgabe in den Suchmaschinen-Index aufzunehmen.
Aktivieren
php redaxo/bin/console config:set debug.enabled true --type bool
Deaktivieren
php redaxo/bin/console config:set debug.enabled false --type bool
In der Datei redaxo/data/core/config.yml können Parameter zum Debugging aktiviert werden. Der Debug-Modus sollte ausschließlich nur dann aktiviert werden, wenn die Website nicht öffentlich erreichbar ist.
Das Debug-AddOn kann zusätzlich installiert werden kann und anschließend im Frontend und Backend verwendet werden. Es erscheint ein neuer Menüpunkt, in dem Clockwork gestartet wird. Jeder weitere Aufruf im Frontend oder Backend übergibt an Clockwork Debugging-Informationen.
Das Debug-AddOn sollte nicht in Produktivumgebungen eingesetzt werden, weil hierfür der Debug-Modus im System aktiviert sein muss. Bei Multidomain-Umgebungen sollte man sich mit der gewünschten Domain im Backend einloggen, damit es unter der jeweiligen Domain eingesetzt werden kann.
Serverseitige Abläufe visualisiert durch Clockwork
Um eigene Messungen vornehmen zu können, kann die rex_timer-Klasse verwendet werden und den eigenen Code dazwischen einfügen:
rex_timer::measure('Bezeichnung für Clockwork', function() {
// lange und aufwändige Arbeit eines eigenen Code-Abschnittes einfügen und messen lassen.
});Weiterführende Infos zu rex_timer in den API Docs
REDAXOHours Vortrag zum Thema Whoops in REDAXO, und dem Neuen Debug Addon
In Desktop-Browsern befindet sich in den Entwickler-Tools ein "Netzwerk"-Reiter, in welchem REDAXO bei aktiviertem Debug-Modus zusätzliche Performance-Informationen ausgibt, die über rex_timer gemessen werden.
Möglicherweise ist der Debug-Modus aktiviert. Der Debug-Modus sollte ausschließlich nur dann aktiviert werden, wenn die Website nicht öffentlich erreichbar ist.
- Ist sichergestellt, dass alle Dateien erfolgreich kopiert wurden?
- Stimmt die PHP-Version? Siehe Systemanforderungen.
- Wurden die Datenbank-Zugangsdaten angepasst?
- Sind alle Einstellungen am Webspace-Paket und der Domain korrekt, z. B. Domain, A-Record, Verzeichnispfad, etc.?
- Wurde die .htaccess-Datei übernommen oder neu gesetzt oder sind Anpassungen dort nötig?
- Wurde das Setup erneut ausgeführt oder zumindest der Cache gelöscht?
Möglicherweise wurde das Passwort geändert oder der Benutzer existiert nicht mehr. Oder: Möglicherweise wurde ein Backup eingespielt, das die Tabelle rex_user nicht beinhaltet hat oder überschrieben hat.
- Lösung 1: Ggf. das Setup starten, um den Administrator erneut anzulegen.
- Lösung 2: Das Passwort des Administrators zurücksetzen.
- Lösung 3: Über die REDAXO-Konsole einen neuen Benutzer erstellen oder das Passwort eines bestehenden Benutzers zurücksetzen:
console user:set-password <username> <neues-passwort>
Ein Login ist auch nicht mehr möglich, wenn der Speicherplatz des Hosting-Pakets voll ist und die PHP-Session daher nicht gestartet werden kann.
Stelle sicher, dass https://www.redaxo.org/de/ws/ über eine Socket-Verbindung erreichbar ist. Möglicherweise hat der Hoster ausgehende Socket-Verbindungen blockiert, oder verwendet keinen aktuellen Zertifikatsspeicher. Dies kann auch im Zuge einer PHP-Versionsumstellung passieren.
Möglicherweise ist ein Modul oder der Inhalt eines Blocks defekt und löst einen Fehler aus. Mögliche Lösungsansätze:
- Den betroffenen Modulcode im Menü
Moduleauf Fehler überprüfen oder - Im Zweifel über die Datenbank den betroffenen Block in der Tabelle
rex_article_sliceentfernen und den REDAXO-Cache löschen.
Wird beim Speichern in einem Modul oder Template im Backend ein 403-Fehler gemeldet, ist evtl. mod_security oder fail2ban beim Webspace aktiviert.
Für mod_security testweise nur auf "Erkennung und protokollieren" einstellen.
CSRF steht für Cross-Site Request Forgery. Es handelt sich dabei um eine Art von Angriff, bei dem ein Angreifer eine Anfrage an eine Website sendet, die der Benutzer bereits authentifiziert hat. Dadurch kann der Angreifer Aktionen im Namen des Benutzers ausführen, ohne dass dieser davon Kenntnis hat.
Um sich vor CSRF-Angriffen zu schützen, verwenden viele Websites Anti-CSRF-Token, die in Formularen eingebettet sind und bei jeder Anfrage überprüft werden.
Grundsätzlich ist das Deaktivieren des CSRF-Schutzes nicht empfehlenswert, da es die Sicherheit des Systems gefährdet.
Einzelne Webhosting-Anbeiter haben auch heute noch Quotas für die Anzahl der Dateien und den Gesamtspeicherplatz, die ein Benutzer in seinem Webspace speichern darf. Wenn diese Quota überschritten wird, kann es zu Problemen kommen, da auch das Schreiben temporärer Dateien (z.B. für die Session und damit das CSRF-Token) nicht mehr möglich ist.
- Prüfe, ob Quotas existieren und weshalb diese überschritten wurden.
- Lösche ggf. nicht mehr benötigte Dateien.
Wenn REDAXO nicht die nötigen Schreibrechte hat, um temporäre Dateien zu erstellen, kann es zu Problemen kommen, da auch das Schreiben temporärer Dateien (z.B. für die Session und damit das CSRF-Token) nicht mehr möglich ist.
Ist in den PHP-Einstellungen "session.auto_start" aktiviert, wird empfohlen, dies zu deaktivieren, um Probleme zu vermeiden. redaxo/redaxo#5733
- Prüfe, ob "session.auto_start" aktiviert ist.
- Deaktiviere ggf. "session.auto_start"
- Schreibrechte für REDAXO prüfen und ggf. neu setzen.