Schlagwort: 🌍

email-versand

E-Mail Versand

Zentraler E-Mail-Versand

Das E-Mail-Versand-Modul konfiguriert den SMTP-Versand für das gesamte Netzwerk. Alle ausgehenden E-Mails des Weinhold Frameworks – von Kalender-Erinnerungen bis zu Passwort-Reset-Mails – laufen über diese eine zentrale Konfiguration.

Konfiguration

SMTP-Server, Port, Verschlüsselung (TLS/SSL), Benutzername und Passwort werden einmalig unter Weinhold → E-Mail Versand für das gesamte Netzwerk eingetragen. Einzelne Subsites können optional einen abweichenden Absendernamen und eine eigene Absenderadresse festlegen.

E-Mail-Templates

Module können eigene E-Mail-Templates registrieren, die im Dashboard unter Weinhold → E-Mail Versand → Templates mit individuellem Betreff und Nachrichtentext angepasst werden können. Das Kalender-Modul nutzt dies z.B. für Termin-Erinnerungen.

In der Praxis

Auf weinify.de läuft der gesamte transaktionale E-Mail-Versand – Passwort zurücksetzen, Kalender-Erinnerungen, Bestellbenachrichtigungen – über dieses Modul. Kein Plugin-Wirrwarr, eine zentrale Stelle.

Email Delivery

Centralized Email Sending

The Email Delivery module configures SMTP sending for the entire network. All outgoing emails from the Weinhold Framework — from calendar reminders to password reset emails — run through this single central configuration.

Configuration

SMTP server, port, encryption (TLS/SSL), username, and password are entered once under Weinhold → Email Delivery for the entire network. Individual subsites can optionally set a different sender name and address.

Email Templates

Modules can register their own email templates, customizable in the dashboard under Weinhold → Email Delivery → Templates with individual subject and body text. The Calendar module uses this for appointment reminders, for example.

In Practice

On weinify.de, all transactional email sending — password resets, calendar reminders, order notifications — runs through this module. No plugin clutter, one central place.

10. Juni 2026
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.

Security Manager

Protection Against Brute-Force Attacks

The Security Manager protects all sites in the network from automated access attempts and unwanted IPs. It works silently in the background and intervenes before WordPress even responds.

IP Blacklist

Specific IP addresses can be permanently added to a blocklist. Requests from these IPs are blocked immediately — before the WordPress login process even starts.

Login Lockout

After a configurable number of failed login attempts, the IP in question is automatically blocked for a set period. This reliably stops brute-force attacks.

Administration & Logging

In the dashboard under Weinhold → Security Manager, blocked IPs can be viewed, unblocked, or permanently banned. All lockout events are automatically logged in the Audit Log, keeping suspicious activity traceable.

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.

Device Security

Protection Against Unknown Devices

The Device Security module detects during login whether a device is being used for the first time. If the device is unknown, the user must answer a security question before access is granted — an additional layer of protection that works even with compromised passwords.

How it works

On first login from a new browser or device, an additional verification page appears. After successfully answering, the device is stored as trusted and automatically recognized on future logins — no repeated prompts.

In Practice

The module works network-wide across all sites simultaneously. Anyone logging into a subsite of the Weinhold network for the first time automatically goes through this security check — no additional page-level configuration required.

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.
User Management

The Central Login System

User Management is the authentication system of the Weinhold Framework. It handles registration, login, profile editing, password resets, and role assignment — network-wide across all sites.

Shortcodes
- [weinhold_auth_login] – Login form
- [weinhold_auth_register] – Registration form for new users
- [weinhold_auth_profile] – Profile view and editing for logged-in users (change password, upload avatar)
- [weinhold_auth_lostpassword] – Password reset form
- [weinhold_auth_nav] – Navigation bar with links to login, profile, and other areas
In Practice – weinify.de

On weinify.de and all subsites, the complete login and registration system runs through this module. The [weinhold_auth_nav] shortcode is embedded in the Custom Header, providing cross-site navigation between login, profile, and other pages.

Roles & Permissions

Administrators assign roles and module permissions centrally in the dashboard under Weinhold → User Management → Module Permissions. This allows read or write access to be configured per module for each role.
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.

Shortcodes

The Backbone of the Framework

The Shortcode module is the backbone of the Weinhold Framework. It provides a central registry through which all other modules register their shortcodes — including descriptions and parameter documentation.

How it works

Each module calls weinhold_add_shortcode() on load, passing a tag, callback, description, and optional parameter docs. The module collects all entries and lists them in the admin dashboard under Weinhold → Shortcodes — always giving you a full overview of all available shortcodes.

Why Core?

This module is always loaded regardless of which other modules are active. Without it, no shortcodes from other modules would be registered. It is the silent foundation for everything visible on the site.

10. Juni 2026
kalender
Kalender

Termine für das gesamte Netzwerk

Das Kalender-Modul bringt einen netzwerkweiten Terminplaner ins Weinhold Framework. Termine werden zentral gespeichert und können von eingeloggten Nutzern erstellt, bearbeitet und geteilt werden – optional auch öffentlich für alle Besucher. Auf weinify.de/kalender ist das Modul live im Einsatz.

Shortcodes
- [weinhold_calendar] – Persönlicher Kalender: Zeigt alle Termine netzwerkweit, die der eingeloggte Nutzer sehen darf. Beim Aktivieren des Moduls wird automatisch eine Seite unter /kalender mit diesem Shortcode erstellt.
- [weinhold_public_calendar] – Öffentlicher Kalender: Zeigt die Termine der aktuellen Webseite. Nicht eingeloggte Besucher sehen nur öffentliche Termine.
Sichtbarkeit von Terminen

Beim Erstellen wählt man zwischen drei Stufen:
- 🌍 Netzwerk – Alle eingeloggten Nutzer können den Termin sehen
- 🔒 Privat – Nur Ersteller und eingeladene Nutzer haben Zugriff
- 🌐 Öffentlich – Jeder kann den Termin sehen, auch ohne Login (erfordert besondere Berechtigung)
E-Mail-Erinnerungen

Pro Termin kann eine E-Mail-Erinnerung aktiviert werden. In den persönlichen Einstellungen legt jeder Nutzer fest, wie viele Tage vorher die Erinnerung gesendet werden soll (0 = am selben Tag, -1 = deaktiviert). Der Versand läuft täglich automatisch per Cronjob.

Farbkodierung & Herkunft

Jeder Nutzer kann pro Webseite eine eigene Farbe für die Terminanzeige konfigurieren. Bei der Termin-Erstellung wird außerdem die Herkunft (welche Subsite) zugeordnet – so behalten Mitglieder mehrerer Sites den Überblick.
Calendar

Events for the Entire Network

The Calendar module brings a network-wide event planner to the Weinhold Framework. Events are stored centrally and can be created, managed, and shared by logged-in users — optionally also publicly. The module is live at weinify.de/kalender.

Shortcodes
- [weinhold_calendar] – Personal calendar: shows all network-wide events the logged-in user has access to. When the module is activated, a page at /kalender with this shortcode is automatically created.
- [weinhold_public_calendar] – Public calendar: shows events for the current website. Guests not logged in only see public events.
Event Visibility

Three visibility levels are available when creating an event:
- 🌍 Network – All logged-in users can see the event
- 🔒 Private – Only the creator and invited users have access
- 🌐 Public – Everyone can see the event, even without login (requires special permission)
Email Reminders

An email reminder can be activated per event. In personal settings, each user sets how many days in advance the reminder should be sent (0 = same day, -1 = disabled). Sending runs automatically daily via cron job.

Color Coding & Origin

Each user can configure a custom color per website for the event display. When creating an event, the origin (which subsite) is also assigned — helping members of multiple sites keep track.
10. Juni 2026

Schlagwort: 🌍

email-versand

E-Mail Versand

Zentraler E-Mail-Versand

Konfiguration

E-Mail-Templates

In der Praxis

Email Delivery

Centralized Email Sending

Configuration

Email Templates

In Practice

security-manager

Security Manager

Schutz vor Brute-Force-Angriffen

IP-Blacklist

Login-Lockout

Administration & Protokollierung

Security Manager

Protection Against Brute-Force Attacks

IP Blacklist

Login Lockout

Administration & Logging

geraetesicherheit

Gerätesicherheit

Schutz vor unbekannten Geräten

Wie es funktioniert

In der Praxis

Device Security

Protection Against Unknown Devices

How it works

In Practice

benutzerverwaltung

Benutzerverwaltung

Das zentrale Login-System

Shortcodes

In der Praxis – weinify.de

Rollen & Berechtigungen

User Management

The Central Login System

Shortcodes

In Practice – weinify.de

Roles & Permissions

audit-log

Audit-Log

Was wird protokolliert?

Zwei Admin-Ansichten

Filtern & Exportieren

Statistiken

Einstellungen

Pro-Site-Overrides

Aufbewahrung

Verfügbare Kontext-Felder

Datenstruktur eines Log-Eintrags

Daten lesen

Registrierte Module abfragen

Wo die Einstellungen gespeichert werden

Audit Log

What Gets Logged?

Two Admin Views

Filter & Export

Statistics

Settings

Per-Site Overrides

Retention

Available Context Fields

Data Structure of a Log Entry

Reading Data

Querying Registered Modules

Where Settings Are Stored

shortcodes

Shortcodes

Das Herzstück des Frameworks

Wie es funktioniert

Warum Core?

Shortcodes

The Backbone of the Framework

How it works

Why Core?

kalender