Audit-Log

Der Audit-Log ist ein Core-Modul des Weinhold Frameworks – er ist immer aktiv und kann nicht deaktiviert werden. Er protokolliert alle relevanten Aktionen im gesamten Multisite-Netzwerk in einer gemeinsamen Tabelle, getrennt nach Site-ID.

Allgemein

Was wird protokolliert?

Der Audit-Log ist in drei Kategorien unterteilt:
WordPress-Ereignisse – werden automatisch vom Modul erfasst:
Auth – Login (erfolgreich & fehlgeschlagen), Logout, Passwort-Reset-Anfragen und Resets inkl. IP-Adresse
Benutzer & Rollen – Registrierung, Löschung, Rollenwechsel, Profiländerungen, Zuweisung zu und Entfernung aus einzelnen Sites
E-Mail – Erfolgreicher Versand und fehlgeschlagene E-Mails inkl. Betreff und Empfänger
Content – Erstellung, Aktualisierung und Löschung von Beiträgen, Seiten, Medien, Kommentaren sowie Taxonomie-Begriffen
System – Plugin-Aktivierungen und -Deaktivierungen, Theme-Wechsel, Update-Prozesse
Framework – Änderungen an Weinhold-Framework-Einstellungen (netzwerkweit & pro Site)
Weinhold-Module – registrieren sich selbst über einen Filter (z.B. Kalender, Security Manager, Highlights)
Eigene Plugins – externe Plugins können sich über einen separaten Filter eintragen

Zwei Admin-Ansichten

Pro Site unter Weinhold → Audit-Log – zeigt ausschließlich Einträge der aktuellen Website, blätterbar (25/50/100/200 pro Seite, Sprung zu beliebiger Seite)
Netzwerkweit unter Weinhold Netzwerk → Audit-Log – zeigt Einträge aller Sites im Netzwerk, mit zusätzlichem Filter nach Site

Filtern & Exportieren

Beide Ansichten lassen sich filtern nach: Modul, Aktion, Status (ok / warning / error / info), Benutzer und Freitextsuche in Nachricht und Kontext. Alle gefilterten Einträge können als CSV exportiert werden – der Export selbst wird ebenfalls im Log protokolliert.

Statistiken

Der Tab Statistiken gibt einen grafischen Überblick über die Aktivität im gewählten Zeitraum. Filterbar nach Site, Zeitraum (7 / 14 / 30 / 90 / 180 / 365 Tage) und Modul.
Kacheln – Gesamtanzahl der Ereignisse sowie Aufschlüsselung nach Status (ok, warning, error, info)
Verlauf – Tägliches Balkendiagramm der Ereignisanzahl im gewählten Zeitraum
Ereignisse nach Modul – Horizontale Balken zeigen welche Module am aktivsten sind
Top Aktionen – Die 15 häufigsten Modul-Aktions-Kombinationen

Einstellungen

Die Einstellungen sind in drei Blöcke gegliedert:
WordPress-Ereignisse – Einzelne Kategorien (Auth, Benutzer, E-Mail Erfolg/Fehler, Content, System, Framework) lassen sich netzwerkweit ein- oder ausschalten
Weinhold-Module – Master-Schalter + pro Modul individuell aktivierbar/deaktivierbar
Eigene Plugins – Master-Schalter + pro Plugin individuell aktivierbar/deaktivierbar

Screenshot

Zusätzlich gibt es eine Aufbewahrungsfrist (1–3650 Tage, Standard: 90 Tage).

Pro-Site-Overrides

Jede Untersite kann den Netzwerk-Standard für jede einzelne Kategorie und für jedes einzelne Modul übersteuern – mit drei Optionen: Vererben (Netzwerk-Standard), Aktivieren oder Deaktivieren. So lässt sich z.B. die Gerätesicherheit nur auf einer bestimmten Untersite aktivieren, während sie auf den anderen vererbt-deaktiviert bleibt.

Aufbewahrung

Ein täglicher Cron-Job löscht automatisch alle Einträge die älter als die konfigurierte Aufbewahrungsfrist sind – in Batches von 500 Einträgen um die Datenbank nicht zu belasten.

Dateien

modules/audit_log_core.php – Lade-Stub (nur Modul-Header, wird vom Framework-Core erkannt und geladen)
modules/audit_log/audit_log.php – Daten- und Hook-Logik: Einstellungen, Datenbank-Installation, alle WordPress-Event-Hooks, die öffentliche API (log_event, get_rows, count_rows, get_stats, get_user_history). Wird auf jedem Seitenaufruf geladen, auch im Frontend.
modules/audit_log/admin.php – Die komplette Admin-Oberfläche: Formular-Verarbeitung, CSV-Export sowie das Rendering aller Tabs (Log, Statistiken, Einstellungen, Bereinigung). Wird nur im WordPress-Backend geladen (is_admin()-Prüfung in audit_log.php) – auf normalen Website-Seiten muss PHP diese Datei gar nicht erst einlesen.
Kein eigenes CSS oder JS – das Modul nutzt ausschließlich WordPress-Admin-Standardstile.

Für Entwickler

Alle Funktionen in diesem Abschnitt liegen in modules/audit_log/audit_log.php (siehe „Dateien“ oben) – sie sind unabhängig vom Admin-Bereich nutzbar.
Es gibt zwei separate Registrierungswege – je nachdem ob es sich um ein Weinhold-Modul oder ein externes Plugin handelt:

Weinhold-Module – Schritt 1: Modul registrieren

add_filter( ‚weinhold_audit_modules‘, function( $modules ) {
$modules[‚mein_modul‘] = array(
‚label‘ => ‚Mein Modul‘,
‚description‘ => ‚Kurzbeschreibung für die Einstellungsseite.‘,
‚actions‘ => array(
‚eintrag_erstellt‘ => ‚Eintrag erstellt‘,
‚eintrag_geloescht‘ => ‚Eintrag gelöscht‘,
),
);
return $modules;
} );

Eigene Plugins – Schritt 1: Plugin registrieren

add_filter( ‚weinhold_audit_custom_modules‘, function( $modules ) {
$modules[‚mein_plugin‘] = array(
‚label‘ => ‚Mein Plugin‘,
‚description‘ => ‚Kurzbeschreibung.‘,
‚actions‘ => array(
‚aktion_a‘ => ‚Aktion A‘,
),
);
return $modules;
} );

Schritt 2 – Event auslösen (gleich für beide)

if ( function_exists( ‚weinhold_audit_log_log_event‘ ) ) {
weinhold_audit_log_log_event(
‚mein_modul‘, // module_id (muss mit Registrierung übereinstimmen)
‚eintrag_erstellt‘, // action
‚Neuer Eintrag wurde angelegt.‘,
array(
’status‘ => ‚ok‘,
‚context‘ => array( ‚eintrag_id‘ => 42 ),
)
);
}

Die Funktion prüft selbst ob das Logging für das Modul aktiv ist und ob der jeweilige Master-Schalter gesetzt ist – kein eigenes Checking nötig.

Verfügbare Kontext-Felder

Feld Typ Bedeutung
status string ok, warning, error oder info
context array Beliebige zusätzliche Daten – werden als JSON gespeichert und sind durchsuchbar
actor_user_id int Wer hat die Aktion ausgelöst (Standard: eingeloggter Nutzer)
target_user_id int Wer ist betroffen (optional)
site_id int Für welche Site (Standard: aktuelle Site)

Datenstruktur eines Log-Eintrags

So sieht ein gespeicherter Eintrag in der Datenbank aus:

Spalte Typ Bedeutung
id bigint, Auto-Increment Primärschlüssel
created_at_gmt datetime Zeitstempel in UTC
site_id bigint Welche Site im Netzwerk
actor_user_id bigint, NULL möglich Wer hat die Aktion ausgelöst (NULL = System)
target_user_id bigint, NULL möglich Wen betrifft es (optional)
module varchar(64) Modul-ID, z.B. auth, content, mein_modul
action varchar(100) Aktion, z.B. login, post_updated
status varchar(20) ok / warning / error / info
message text Lesbare Beschreibung
context longtext JSON-String mit Zusatzdaten – durchsuchbar

Daten lesen

Funktion Beschreibung
weinhold_audit_log_get_rows( array $filters, int $limit = 50, int $offset = 0 ): array Gibt gefilterte Log-Einträge zurück. Filter: site_id, module, action, status, user_id, search, date_from, date_to. $limit ist auf 50.000 begrenzt.
weinhold_audit_log_count_rows( array $filters ): int Gesamtanzahl für Pagination – gleiche Filter wie oben.
weinhold_audit_log_get_stats( int $site_id = 0, int $days = 30, string $module_filter = “ ): array Liefert die Daten hinter dem Statistiken-Tab: Gesamtanzahl, Status-Aufschlüsselung, täglicher Verlauf, Ereignisse nach Modul, Top-Aktionen.
weinhold_audit_log_get_user_history( int $user_id, int $site_id = 0, int $limit = 20 ): array Letzte Aktionen eines bestimmten Benutzers.

Registrierte Module abfragen

Funktionen

weinhold_audit_get_weinhold_modules(): array // Nur Weinhold-eigene Module
weinhold_audit_get_custom_modules(): array // Nur externe/eigene Plugins
weinhold_audit_get_registered_modules(): array // Beide kombiniert

Wo die Einstellungen gespeichert werden

Option Speicherort Enthält
weinhold_audit_log_settings Netzwerk-Option Bool-Schalter pro WP-Kategorie, log_weinhold_modules/log_custom_modules (Master-Schalter), weinhold_toggles/custom_toggles (Array pro Modul-ID), retention_days
weinhold_audit_log_site_overrides Pro-Site-Option Gleiche Felder wie oben, aber dreiwertig: inherit / on / off. Modul-Overrides in weinhold_module_overrides / custom_module_overrides

Besonderheiten

Keine IP-Adress-Spalte in der Datenbank – IP-Adressen landen im context-JSON statt in einer eigenen Spalte. Die Freitextsuche durchsucht auch context, eine eigene Spalte war daher nicht nötig.
weinhold_audit_log_get_user_history() existiert, wird aber bewusst nicht im Benutzerprofil angezeigt – die Funktion ist fertig und nutzbar, aber (noch) an keiner Stelle im Admin verlinkt.
Kein doppeltes Logging bei neuen Beiträgen – transition_post_status überspringt Übergänge, bei denen der alte Status new oder auto-draft war, weil die Erstellung bereits über den save_post-Hook erfasst wird.
DB-Migrationen laufen versioniert – Pattern: aktuelle Version aus get_site_option(‚weinhold_audit_log_db_version‘, 0) lesen, dann if ($installed_version < N) { … }-Blöcke nacheinander abarbeiten. So bleiben Updates idempotent, auch wenn jemand mehrere Versionen überspringt.

Audit Log

The Audit Log is a core module of the Weinhold Framework — it is always active and cannot be deactivated. It records all relevant actions across the entire Multisite network in a shared table, separated by site ID.

General

What Gets Logged?

The Audit Log is divided into three categories:
WordPress Events – captured automatically by the module:
Auth – Login (successful & failed), logout, password reset requests and resets including IP address
Users & Roles – Registration, deletion, role changes, profile updates, assignment to and removal from individual sites
Email – Successful sends and failed emails including subject and recipient
Content – Creation, update and deletion of posts, pages, media, comments and taxonomy terms
System – Plugin activations and deactivations, theme switches, update processes
Framework – Changes to Weinhold Framework settings (network-wide & per site)
Weinhold Modules – register themselves via a filter (e.g. Calendar, Security Manager, Highlights)
Custom Plugins – external plugins can register via a separate filter

Two Admin Views

Per site under Weinhold → Audit Log – shows only entries for the current website, paginated (25/50/100/200 per page, jump to any page)
Network-wide under Weinhold Network → Audit Log – shows entries from all sites in the network, with an additional filter by site

Filter & Export

Both views can be filtered by: module, action, status (ok / warning / error / info), user and free-text search in message and context. All filtered entries can be exported as CSV — the export itself is also logged.

Statistics

The Statistics tab provides a graphical overview of activity in the selected period. Filterable by site, time range (7 / 14 / 30 / 90 / 180 / 365 days) and module.
Tiles – Total event count plus breakdown by status (ok, warning, error, info)
Timeline – Daily bar chart of event counts over the selected period
Events by module – Horizontal bars showing which modules are most active
Top actions – The 15 most frequent module-action combinations

Settings

Settings are divided into three blocks:
WordPress Events – Individual categories (Auth, Users, Email success/failure, Content, System, Framework) can be toggled network-wide
Weinhold Modules – Master switch + individual toggle per module
Custom Plugins – Master switch + individual toggle per plugin

Screenshot

There is also a configurable retention period (1–3650 days, default: 90 days).

Per-Site Overrides

Each subsite can override the network default for every individual category and every individual module — with three options: Inherit (network default), Enable or Disable. This allows, for example, enabling Device Security only on one specific subsite while keeping it inherited-disabled everywhere else.

Retention

A daily cron job automatically deletes all entries older than the configured retention period — in batches of 500 entries to avoid database strain.

Files

modules/audit_log_core.php – Loader stub (module header only, detected and loaded by the framework core)
modules/audit_log/audit_log.php – Data and hook logic: settings, database installation, all WordPress event hooks, the public API (log_event, get_rows, count_rows, get_stats, get_user_history). Loaded on every page load, including the frontend.
modules/audit_log/admin.php – The full admin interface: form handling, CSV export, and rendering of all tabs (Log, Statistics, Settings, Cleanup). Only loaded in the WordPress backend (is_admin() check in audit_log.php) — on regular site pages PHP never has to parse this file at all.
No dedicated CSS or JS – the module relies entirely on WordPress’s default admin styling.

For Developers

All functions in this section live in modules/audit_log/audit_log.php (see „Files“ above) – they work independently of the admin area.
There are two separate registration paths — depending on whether it’s a Weinhold module or an external plugin:

Weinhold Modules – Step 1: Register module

add_filter( ‚weinhold_audit_modules‘, function( $modules ) {
$modules[‚my_module‘] = array(
‚label‘ => ‚My Module‘,
‚description‘ => ‚Short description for the settings page.‘,
‚actions‘ => array(
‚entry_created‘ => ‚Entry created‘,
‚entry_deleted‘ => ‚Entry deleted‘,
),
);
return $modules;
} );

Custom Plugins – Step 1: Register plugin

add_filter( ‚weinhold_audit_custom_modules‘, function( $modules ) {
$modules[‚my_plugin‘] = array(
‚label‘ => ‚My Plugin‘,
‚description‘ => ‚Short description.‘,
‚actions‘ => array(
‚action_a‘ => ‚Action A‘,
),
);
return $modules;
} );

Step 2 – Fire an event (same for both)

if ( function_exists( ‚weinhold_audit_log_log_event‘ ) ) {
weinhold_audit_log_log_event(
‚my_module‘, // module_id (must match registration)
‚entry_created‘, // action
‚New entry was created.‘,
array(
’status‘ => ‚ok‘,
‚context‘ => array( ‚entry_id‘ => 42 ),
)
);
}

The function automatically checks whether logging is active for the module and whether the master switch is set — no extra checking needed.

Available Context Fields

Field Type Description
status string ok, warning, error or info
context array Any additional data — stored as JSON and fully searchable
actor_user_id int Who triggered the action (default: logged-in user)
target_user_id int Who is affected (optional)
site_id int Which site (default: current site)

Data Structure of a Log Entry

This is what a stored entry looks like in the database:

Column Type Meaning
id bigint, auto-increment Primary key
created_at_gmt datetime Timestamp in UTC
site_id bigint Which site in the network
actor_user_id bigint, nullable Who triggered the action (NULL = system)
target_user_id bigint, nullable Who is affected (optional)
module varchar(64) Module ID, e.g. auth, content, my_module
action varchar(100) Action, e.g. login, post_updated
status varchar(20) ok / warning / error / info
message text Human-readable description
context longtext JSON string with extra data — searchable

Reading Data

Function Description
weinhold_audit_log_get_rows( array $filters, int $limit = 50, int $offset = 0 ): array Returns filtered log entries. Filters: site_id, module, action, status, user_id, search, date_from, date_to. $limit is capped at 50,000.
weinhold_audit_log_count_rows( array $filters ): int Total count for pagination — same filters as above.
weinhold_audit_log_get_stats( int $site_id = 0, int $days = 30, string $module_filter = “ ): array Provides the data behind the Statistics tab: total count, status breakdown, daily timeline, events by module, top actions.
weinhold_audit_log_get_user_history( int $user_id, int $site_id = 0, int $limit = 20 ): array Most recent actions of a specific user.

Querying Registered Modules

Functions

weinhold_audit_get_weinhold_modules(): array // Weinhold modules only
weinhold_audit_get_custom_modules(): array // External/custom plugins only
weinhold_audit_get_registered_modules(): array // Both combined

Where Settings Are Stored

Option Storage location Contains
weinhold_audit_log_settings Network option Bool toggle per WP category, log_weinhold_modules/log_custom_modules (master switches), weinhold_toggles/custom_toggles (array per module ID), retention_days
weinhold_audit_log_site_overrides Per-site option Same fields as above, but three-valued: inherit / on / off. Module overrides in weinhold_module_overrides / custom_module_overrides

Special Cases

No IP address column in the database — IP addresses go into the context JSON instead of a dedicated column. Free-text search also searches context, so a dedicated column wasn’t necessary.
weinhold_audit_log_get_user_history() exists but is deliberately not shown in the user profile — the function is complete and usable, but isn’t (yet) linked anywhere in the admin.
No duplicate logging for new posts — transition_post_status skips transitions where the old status was new or auto-draft, because creation is already captured via the save_post hook.
DB migrations run versioned — pattern: read the current version from get_site_option(‚weinhold_audit_log_db_version‘, 0), then process if ($installed_version < N) { … } blocks in sequence. This keeps updates idempotent even if someone skips several versions.

audit-log