security-manager

Security Manager

Schutz vor Brute-Force-Angriffen

Der Security Manager schützt alle Sites im Netzwerk vor automatisierten Zugriffsversuchen und unerwünschten IPs. Er arbeitet still im Hintergrund und greift ein, bevor WordPress überhaupt reagiert.

IP-Blacklist

Bestimmte IP-Adressen können dauerhaft auf eine Sperrliste gesetzt werden. Anfragen von diesen IPs werden sofort blockiert – noch bevor der WordPress-Login-Prozess startet.

Login-Lockout

Nach einer konfigurierbaren Anzahl fehlgeschlagener Login-Versuche wird die betreffende IP automatisch für einen festgelegten Zeitraum gesperrt. Das stoppt Brute-Force-Angriffe zuverlässig.

Administration & Protokollierung

Im Dashboard unter Weinhold → Security Manager können gesperrte IPs eingesehen, entsperrt oder dauerhaft blockiert werden. Alle Lockout-Ereignisse werden automatisch im Audit-Log protokolliert, sodass verdächtige Aktivitäten nachvollziehbar bleiben.

10. Juni 2026

geraetesicherheit

Gerätesicherheit

Schutz vor unbekannten Geräten

Das Gerätesicherheits-Modul erkennt beim Login, ob ein Gerät zum ersten Mal verwendet wird. Ist das Gerät unbekannt, muss der Nutzer eine Sicherheitsfrage beantworten, bevor der Zugang gewährt wird – eine zusätzliche Schutzschicht, die auch bei kompromittierten Passwörtern greift.

Wie es funktioniert

Beim ersten Login von einem neuen Browser oder Gerät erscheint eine zusätzliche Abfrageseite. Nach erfolgreicher Beantwortung wird das Gerät als vertrauenswürdig gespeichert und beim nächsten Login automatisch erkannt – ohne erneute Abfrage.

In der Praxis

Das Modul wirkt netzwerkweit auf allen Sites gleichzeitig. Wer sich zum ersten Mal auf einer Subsite des Weinhold-Netzwerks einloggt, durchläuft automatisch diese Sicherheitsprüfung – ganz ohne zusätzliche Konfiguration auf Seitenebene.

10. Juni 2026

benutzerverwaltung

Benutzerverwaltung

Das zentrale Login-System

Die Benutzerverwaltung ist das Authentifizierungssystem des Weinhold Frameworks. Sie regelt Registrierung, Login, Profilbearbeitung, Passwort-Reset und Rollenzuweisung – netzwerkweit für alle Sites.

Shortcodes

[weinhold_auth_login] – Login-Formular
[weinhold_auth_register] – Registrierungsformular für neue Nutzer
[weinhold_auth_profile] – Profilansicht und -bearbeitung für eingeloggte Nutzer (Passwort ändern, Avatar hochladen)
[weinhold_auth_lostpassword] – Passwort zurücksetzen
[weinhold_auth_nav] – Navigationsleiste mit Links zu Login, Profil und weiteren Bereichen

In der Praxis – weinify.de

Auf weinify.de und allen Subsites läuft das komplette Login- und Registrierungssystem über dieses Modul. Der [weinhold_auth_nav]-Shortcode ist im Custom Header eingebunden und sorgt für die siteübergreifende Navigation zwischen Login, Profil und weiteren Seiten.

Rollen & Berechtigungen

Administratoren weisen Rollen und Modulberechtigungen zentral im Dashboard unter Weinhold → Nutzerverwaltung → Modulberechtigungen zu. So kann pro Modul konfiguriert werden, welche Rollen Lese- oder Schreibzugriff haben.

10. Juni 2026

audit-log

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.

10. Juni 2026

shortcodes

Shortcodes

Das Herzstück des Frameworks

Das Shortcode-Modul ist das Rückgrat des Weinhold Frameworks. Es stellt eine zentrale Registry bereit, über die alle anderen Module ihre Shortcodes registrieren – inklusive Beschreibung und Parameterdokumentation.

Wie es funktioniert

Jedes Modul ruft beim Laden weinhold_add_shortcode() auf und übergibt Tag, Callback, Beschreibung und optionale Parameter-Dokumentation. Das Modul sammelt alle Einträge und listet sie übersichtlich im Admin-Dashboard unter Weinhold → Shortcodes auf – so hat man immer alle verfügbaren Shortcodes im Blick.

Warum Core?

Dieses Modul wird immer geladen, unabhängig davon ob andere Module aktiv sind. Ohne es würden keine Shortcodes anderer Module registriert. Es ist die stille Grundlage für alles, was auf der Seite sichtbar wird.

10. Juni 2026

Kategorie: Uncategorized