Skip to main content

​
Was macht das Error-Tracking?

JTL speichert Core- und DB-Fehler im Systemlog (tjtllog) oft nur als Halb-Log: die SQL-Query, aber ohne Stacktrace und ohne den Hinweis, welcher Code den Fehler ausgelöst hat. Das DZM-Logsystem schreibt strukturiert nach tDZMLogEntries (Level, Kontext, Stacktrace, Request-ID) und zeigt die Einträge unter Logs an.
Übersicht Error-Tracking

Zwei Bausteine erweitern das gezielt:
  • Core-Log-Mirror (in dzm_resources): spiegelt JTLs eigene Fehler angereichert um einen rekonstruierten Aufrufer-Stack ins DZM-Log. Das ist der einzige Weg, an die gefangenen DB-Fehler heranzukommen.
  • Plugin-freies Snippet (ohne dzm_resources): fängt Fatals/OOM/weißen Screen und uncaught Exceptions mit vollem Stack in eine Log-Datei – als frühes Netz oder für Shops ganz ohne DZM-Plugins.
Bound-Params und der strukturierte MySQL-Fehler bleiben weg (JTL wirft sie vor dem Logger weg). Geliefert werden SQL + MySQL-Message + Stack. Das plugin-freie Snippet sieht die gefangenen DB-Fehler gar nicht – dafür den Core-Log-Mirror aktivieren.

​
Core-Log-Mirror aktivieren

Ein Einzeiler in der config.JTL-Shop.ini.php. Danach landen JTLs Core-/DB-Fehler zusätzlich als Plugin “jtl_core” in den Logs – inklusive Stack.
Core-Log-Mirror aktivieren
Ans Ende der includes/config.JTL-Shop.ini.php. Voraussetzung: JTL loggt den Fehler überhaupt (DB-Fehler-Logging hängt an ES_DB_LOGGING). Nur Error-Level wird gespiegelt.

​
Logger-Konfiguration

Aktuelle Werte der DZM_LOGGER_*-Konstanten. Gesetzt in config.JTL-Shop.ini.php; ohne defined() gilt der Default.
Logger-Konfiguration
​
boolean
default:"true"
Master-Switch. false → log() kehrt sofort ohne Aktion zurück.
​
select
default:"db"
Speicher-Ziel. db = nur DB (mit File-Fallback bei DB-Fehler), file = nur Datei, both = beides.Möglich: db | file | both
​
select
default:"warning"
PSR-3-Mindestlevel. Einträge unterhalb werden verworfen (Performance-Guard, ohne Context-Serialisierung).Möglich: emergency | alert | critical | error | warning | notice | info | debug
​
number
default:"14"
Aufbewahrungsdauer in Tagen für DB-Einträge und Log-Files. Cleanup mit Wahrscheinlichkeit 1/500 pro Write.
​
number
default:"10"
Rotation-Schwelle pro Log-Datei in MB. Bei Überschreitung wird -1, -2 … angehängt.
​
string
Zielverzeichnis für Log-Files (Trailing-Slash). Wird beim ersten File-Write angelegt inkl. .htaccess.
​
boolean
default:"false"
CrashHandler aktivieren: uncaught Throwables + Fatal Errors via set_exception_handler/shutdown_function erfassen.
​
boolean
default:"false"
Zusätzlich set_error_handler für Warnings/Notices/Deprecated registrieren (respektiert @-Suppression).
​
boolean
default:"false"
JTL-Core-Systemlog (tjtllog, z.B. “Error executing query …”) zusätzlich als Plugin “jtl_core” in tDZMLogEntries spiegeln – angereichert um einen rekonstruierten Aufrufer-Stack. Nur Error-Level.

​
Plugin-freies Error-Tracking (ohne dzm_resources)

Für Shops ohne DZM-Plugins oder als frühes Netz. Fängt Fatals/OOM + uncaught Exceptions mit Stack, schreibt nach jtllogs/dzm-selfcheck/.
Plugin-freies Snippet
Ans Ende der includes/config.JTL-Shop.ini.php einfügen.
Erfasst genau die Fehler, die JTL selbst verschluckt oder nur als Halb-Log speichert:
  1. Fatal Errors / Out-of-Memory / weißer Screen (Shutdown, zuverlässig)
  2. uncaught Exceptions mit vollem Stacktrace (chained)
Schreibt nach shop_root/jtllogs/dzm-selfcheck/ (JTLs jtllogs-Ordner ist per .htaccess vor Web-Zugriff geschützt; zusätzlich legt der Block ein eigenes Deny-.htaccess an).
Grenzen (bewusst): Gefangene DB-Fehler (JTLs “Error executing query …”) tauchen hier NICHT auf – die fängt JTL intern ab, kein globaler Handler sieht sie. Dafür braucht es den Core-Log-Mirror (DZM_LOGGER_MIRROR_CORE) in dzm_resources.
Deaktivieren: define('DZM_ERRORLOG_ENABLED', false); oder diesen Block löschen. Eigener Pfad: define('DZM_ERRORLOG_DIR', '/absoluter/pfad/'); (vor diesem Block setzen)