Fehlerbehebung und Debugging
- 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.
Fehleranalyse: Whoops und Ooops
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.
Tritt ein Fehler auf, meldet REDAXO sich im Frontend mit einem Ooops und im Backend mit einem Rrrrroar.
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.
Fehleranalyse: Die system.log-Datei
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.
Debugging: Die Funktion dump()
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.
Suchen in einem Dump:
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.
Debugging: Der Debug-Modus
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.
Konsole
Aktivieren
php redaxo/bin/console config:set debug.enabled true --type bool
Deaktivieren
php redaxo/bin/console config:set debug.enabled false --type bool
Debugging: Einstellungen in der config.yml
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.
Debugging: Das debug-AddOn (ab REDAXO 5.11)
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.
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
Debugging: Entwicklertools des Browsers
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.
Fehler: Google indexiert die Seite nicht, alle Seiten werden als noindex markiert
Möglicherweise ist der Debug-Modus aktiviert. Der Debug-Modus sollte ausschließlich nur dann aktiviert werden, wenn die Website nicht öffentlich erreichbar ist.
Fehler: REDAXO funktioniert nach einem Website-Umzug nicht mehr
- 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?
Fehler: Ich kann mich nicht mehr einloggen
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.
Weitere Fehler und Lösungen aus der REDAXO-Community
Fehler: Installer kann keine AddOns abrufen
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.
Fehler: Die Bearbeiten-Ansicht eines Artikels führt zu einem Fehler
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ü
Module
auf Fehler überprüfen oder - Im Zweifel über die Datenbank den betroffenen Block in der Tabelle
rex_article_slice
entfernen und den REDAXO-Cache löschen.
Fehler: Pjax-Formulare im Backend speichern nicht
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.
Troubleshooting CSRF-Token
Hintergrund
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.
Ursachen für CSRF-Fehler in REDAXO (Allgemein)
Ursache 1: Quota überschritten
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.
Lösung für überschrittene Quotas
- Prüfe, ob Quotas existieren und weshalb diese überschritten wurden.
- Lösche ggf. nicht mehr benötigte Dateien.
Ursache 2: Fehlende Schreibrechte
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.
Ursache 3: Session Autostart
Ist in den PHP-Einstellungen "session.auto_start" aktiviert, wird empfohlen, dies zu deaktivieren, um Probleme zu vermeiden. https://github.com/redaxo/redaxo/issues/5733
Lösung für Session Autostart
- Prüfe, ob "session.auto_start" aktiviert ist.
- Deaktiviere ggf. "session.auto_start"
Lösung für fehlende Schreibrechte
- Schreibrechte für REDAXO prüfen und ggf. neu setzen.
Artikel bearbeiten