Pseudo-Events

Mon, 01 Jan 0001 00:00:00 +0000

Webtrees hat keinen Event-Bus, daher werden Core-Aktionen (Logins, fehlgeschlagene Logins, Logouts, Datensatz-Edits, Fehler, Suchen) durch Polling der webtrees-Log-Tabelle (app/Log.php, Tabelle log) detektiert und pro neuem passenden Log-Eintrag ein Ereignis ausgelöst. Es ist standardmäßig deaktiviert: nichts läuft, bis der angebotene cronjob:pseudo-events-Job aktiviert wird.

Eingebaute Events (ein cj_event pro neuer Log-Zeile, Payload = die Zeile):

Ereignis	Log-Filter (log_type, Nachricht-Präfix)	Feuer bei
`cronjob:log-auth-failed`	`auth`, `Login failed`	ein Login-Versuch fehlgeschlagen (falsches Passwort, unbekannter Benutzer, nicht verifiziert, nicht genehmigt, keine Session-Cookies)
`cronjob:log-auth-login`	`auth`, `Login:`	ein Benutzer eingeloggt
`cronjob:log-auth-logout`	`auth`, `Logout:`	ein Benutzer ausgeloggt
`cronjob:log-error`	`error`, –	eine Ausnahme erfasst und geloggt (die Nachricht ist der Trace)
`cronjob:log-edit-update`	`edit`, `Update:`	ein Datensatz aktualisiert (`GedcomRecord::updateRecord()`)
`cronjob:log-edit-delete`	`edit`, `Delete:`	ein Datensatz gelöscht (`GedcomRecord::deleteRecord()`)
`cronjob:log-search`	`search`, –	eine Suche ausgeführt (eine Log-Zeile pro durchsuchtem Baum)

Payload: log_id, log_time, log_message (auf 250 Zeichen gekürzt, UTF-8-safe) plus gedcom_id / user_id, wenn die Log-Zeile sie trägt. Die Nachrichten-Präfixe sind die hartkodierten englischen Strings des aktuellen Cores; ein Core-Update, das sie ändert, stoppt das passende Ereignis still (kein Fallback per Design) — die Event-Katalog-Beschreibungen und die test-pseudo-events-Suite fixieren die aktuelle Zuordnung.

Route-Events

Mon, 01 Jan 0001 00:00:00 +0000

Ein ergänzender, sofortiger Detektionsmechanismus: anstatt Zustand nach Zeitplan zu pollen, beobachtet das Modul die HTTP-Anfrage selbst. Wenn eine Anfrage an eine abgebildete mutierende Route erfolgreich bearbeitet wurde (2xx/3xx), queue sie das passende Ereignis in dieselbe cj_event-Queue — ein abhörender Event-Job reagiert dann beim nächsten Tick (~60 s), ohne Polling-Latenz.

Welche Routes abgebildet sind — zwei Regeln, beide abgeleitet aus der live webtrees-Routentabelle. Gemeinsame Voraussetzungen: Pfad beginnt mit /tree/{tree}/, der Handler ist im webtrees-Request-Handler-Namespace (RequestHandlers in 2.2.6, Controllers in 2.3), und die Anfrage ist eine POST-Mutation. In 2.2.6 wird dies bei der Abbildung erzwungen (GET-Seiten-Routes werden nicht abgebildet); in 2.3 trägt die Route keine HTTP-Methode, daher erfolgt die POST-Prüfung zur Auslösezeit und das GET-Formular-Load derselben Route wird ignoriert.

Ereignisse on wt-modules

Pseudo-Events

Route-Events