Schlagwort: weinhold-framework

cookie-consent

Cookie Consent

Das Cookie-Consent-Modul stellt einen DSGVO-konformen Cookie-Banner bereit. Auch auf weinify.de ist dieses Modul aktiv – der Banner, der beim ersten Besuch erscheint, kommt direkt aus diesem Modul.

Allgemein

Einwilligungskategorien

Die Einwilligung wird in vier Kategorien unterteilt: Notwendig (immer aktiv, nicht abwählbar), Funktional, Statistik und Marketing. Banner-Titel, Text und alle Schaltflächenbeschriftungen lassen sich pro Subsite individuell anpassen.

Seitenspezifische Texte

Für einzelne Seiten lässt sich der Standard-Bannertext überschreiben – etwa um auf einer speziellen Landingpage einen abweichenden Hinweistext zu zeigen. Ist keine Überschreibung hinterlegt, gilt der allgemeine Text der Subsite.

Datenschutz- & Impressum-Links

Der Banner kann Links zu Datenschutzerklärung und Impressum anzeigen. Beide Quellen sind pro Subsite frei wählbar: eine lokale WordPress-Seite, eine manuell eingetragene URL, oder – im Multisite-Netzwerk – eine netzwerkweit zentral hinterlegte URL (unter Weinhold Netzwerk → Cookie Consent), die sich alle Subsites teilen können.

Erneut öffnen

Ein dauerhaft sichtbarer Button (optional nur als Icon) sowie der Shortcode weinhold_cookie_settings erlauben es Besuchern, ihre Cookie-Einstellungen jederzeit nachträglich zu ändern – ideal platziert auf einer Datenschutzseite.

Shortcodes

Shortcode	Beschreibung
weinhold_cookie_settings	Button, der das Cookie-Einstellungspanel erneut öffnet

Dateien

modules/cookie_consent.php – einzige PHP-Datei des Moduls: Einstellungen, Netzwerk-Links, Frontend-Konfiguration, Admin-Oberflächen (Site + Netzwerk), Cleanup. Frontend-Verhalten (Banner ein-/ausblenden, Cookie setzen) läuft über assets/weinhold_cookie_consent_front.js und die zugehörige CSS-Datei.

Für Entwickler

Übergabe an das Frontend

weinhold_cookie_consent_build_frontend_config() stellt ein Konfigurationsobjekt zusammen (Cookie-Name, Lebensdauer in Tagen, Texte, Button-Beschriftungen, aufgelöste Datenschutz-/Impressum-Links) und übergibt es per wp_localize_script() als weinholdCookieConsentConfig an das Frontend-JS. Die eigentliche Banner-Logik (Anzeigen, Speichern der Auswahl als Cookie, Wiederöffnen) läuft vollständig im JS, PHP liefert nur Konfiguration und das leere HTML-Grundgerüst.

Einstellungen (Option weinhold_cookie_consent_settings, pro Site)

Schlüssel	Bedeutung
enabled	Modul auf dieser Site aktiv
consent_lifetime_days	Gültigkeitsdauer der Einwilligung (30–3650 Tage)
banner_title,banner_text_default	Standardtexte des Banners
page_text_overrides	Array Seiten-ID zu Override-Text
privacy_link_source,imprint_link_source	local_page/manual_url/network_global bzw. disabled/manual_url/network_global
button_accept_all,button_necessary_only,button_save_selection,button_customize,manage_button_label	Alle Button-Beschriftungen einzeln konfigurierbar

Netzwerkweite Datenschutz-/Impressum-URLs liegen separat in der Netzwerk-Option weinhold_cookie_consent_network_links.

Besonderheiten

Abwärtskompatibilität beim Impressum: War imprint_link_source früher auf disabled gespeichert, aber inzwischen ist eine netzwerkweite Impressum-URL hinterlegt, wird beim Auslesen automatisch auf network_global umgestellt – ältere Installationen zeigen das Impressum dann ohne manuelles Nachpflegen an.

Cleanup ist zweistufig: weinhold_cookie_consent_cleanup() löscht nur die Einstellungen der aktuellen Site, weinhold_cookie_consent_network_cleanup() räumt zusätzlich die Netzwerk-Links auf UND löscht die Site-Einstellungen aller Subsites im Netzwerk einzeln.

Der Banner wird nie im Admin-Bereich oder bei AJAX-Requests ausgegeben (eigene Prüfung in Enqueue- und Render-Funktion) – verhindert, dass er versehentlich im WordPress-Backend oder in AJAX-Antworten auftaucht.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

Cookie Consent

The Cookie Consent module provides a GDPR-compliant cookie banner. This module is also active on weinify.de — the banner that appears on first visit comes directly from this module.

General

Consent Categories

Consent is divided into four categories: Necessary (always active, not optional), Functional, Statistics, and Marketing. Banner title, text, and every button label can be customized individually per subsite.

Page-Specific Texts

The default banner text can be overridden for individual pages — e.g. to show a different notice on a special landing page. If no override is set, the subsite’s general text applies.

Privacy & Imprint Links

The banner can show links to the privacy policy and imprint. Both sources are freely chosen per subsite: a local WordPress page, a manually entered URL, or — on a Multisite network — a centrally maintained network-wide URL (under Weinhold Network → Cookie Consent) that all subsites can share.

Reopening It

A permanently visible button (optionally icon-only) plus the weinhold_cookie_settings shortcode let visitors change their cookie choices at any time afterward — ideally placed on a privacy page.

Shortcodes

Shortcode	Description
weinhold_cookie_settings	Button that reopens the cookie settings panel

Files

modules/cookie_consent.php – the module’s only PHP file: settings, network links, frontend configuration, admin UIs (site + network), cleanup. Frontend behavior (showing/hiding the banner, setting the cookie) runs via assets/weinhold_cookie_consent_front.js and its matching CSS file.

For Developers

Handoff to the Frontend

weinhold_cookie_consent_build_frontend_config() assembles a config object (cookie name, lifetime in days, texts, button labels, resolved privacy/imprint links) and hands it to the frontend JS as weinholdCookieConsentConfig via wp_localize_script(). The actual banner logic (showing, saving the choice as a cookie, reopening) runs entirely in JS; PHP only supplies configuration and the empty HTML scaffold.

Settings (Option weinhold_cookie_consent_settings, per site)

Key	Meaning
enabled	Module active on this site
consent_lifetime_days	Consent validity period (30–3650 days)
banner_title,banner_text_default	Default banner texts
page_text_overrides	Array of page ID to override text
privacy_link_source,imprint_link_source	local_page/manual_url/network_global or disabled/manual_url/network_global
button_accept_all,button_necessary_only,button_save_selection,button_customize,manage_button_label	Every button label individually configurable

Network-wide privacy/imprint URLs live separately in the network option weinhold_cookie_consent_network_links.

Special Cases

Backwards compatibility for the imprint: if imprint_link_source was previously stored as disabled, but a network-wide imprint URL has since been set, it’s automatically switched to network_global when read — older installations then show the imprint without manual re-configuration.

Cleanup happens in two stages: weinhold_cookie_consent_cleanup() only removes the current site’s settings, while weinhold_cookie_consent_network_cleanup() additionally clears the network links AND removes the site settings of every subsite in the network individually.

The banner is never output in the admin area or during AJAX requests (its own check in both the enqueue and render functions) — prevents it from accidentally showing up in the WordPress backend or in AJAX responses.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

custom-footer

Custom Footer

Das Custom-Footer-Modul funktioniert genauso wie der Custom Header – nur für den unteren Bereich der Seite. Den Footer, den du gerade auf weinify.de siehst, wurde mit diesem Modul gestaltet.

Allgemein

Buttons & Drag and Drop

Buttons werden über den Platzhalter –buttons– in den Footer-Inhalt eingefügt und können per Drag & Drop sortiert werden. Sub-Buttons für verschachtelte Menüs sind ebenfalls möglich, öffnen im Footer aber nach oben statt nach unten. Pro Button lässt sich die Sichtbarkeit festlegen: immer, nur für eingeloggte oder nur für ausgeloggte Besucher.

Freies HTML

Der Footer-Inhalt kann beliebiges HTML enthalten – Texte, Links, Icons, Copyright-Hinweise oder ganze Layout-Strukturen.

Pro Site, kein Shortcode

Wie beim Header ist jede Subsite vollständig unabhängig konfiguriert. Der Footer wird automatisch auf allen Seiten der Subsite ausgegeben, sobald er im Dashboard konfiguriert und aktiviert wurde – ohne Shortcode.

Dateien

modules/custom_footer.php – dünner Modul-Stub (Init, Admin-Seite, Cleanup), delegiert die komplette Logik an das gemeinsam mit Custom Header genutzte includes/weinhold_custom_layout_helpers.php.

Für Entwickler

Gemeinsamer Unterbau mit Custom Header

Header und Footer sind keine zwei getrennten Implementierungen, sondern dieselbe Logik in includes/weinhold_custom_layout_helpers.php, parametrisiert über $layout (‚header‘ oder ‚footer‘). Für den Footer liefert weinhold_custom_layout_get_config(‚footer‘) entsprechend den Hook wp_footer, öffnende Sub-Menüs nach oben statt unten, und keinen –auth—Platzhalter (der ist dem Header vorbehalten).

Speicherung (Optionen pro Site)

Option	Inhalt
weinhold_custom_footer_enabled	Ob der Footer aktiv ausgegeben wird
weinhold_custom_footer_html	Der HTML-Inhalt mit dem Platzhalter –buttons–
weinhold_custom_footer_links	Array der Buttons (Beschriftung, Ziel-URL, übergeordneter Button für Sub-Buttons, Sichtbarkeit)

Wichtige Funktionen

Funktion	Beschreibung
weinhold_custom_layout_init($layout)	Hängt den Render-Callback an wp_footer, baut das Button-HTML inkl. Sub-Buttons zusammen
weinhold_custom_layout_resolve_link_url($value)	Löst Spezial-Tokens in Button-Zielen auf
weinhold_custom_layout_sanitize_html($html)	Bereinigt gespeichertes HTML über eine eigene, erweiterte Erlaubnisliste (weinhold_custom_layout_allowed_html())
weinhold_custom_layout_get_button_visibility_class($link)	Übersetzt die Sichtbarkeitseinstellung eines Buttons in die CSS-Klasse weinhold-show-on-login bzw. weinhold-show-on-logout

Ausführlichere Details zum gemeinsamen Unterbau (inkl. Rückwärtskompatibilität älterer Buttons) siehe der Custom-Header-Beitrag.

Besonderheiten

Wird auf Auth-Seiten (Login, Registrierung, Profil, Passwort-vergessen) automatisch unterdrückt – weinhold_user_management_is_auth_page() prüft das vor jeder Ausgabe.

Freies HTML ohne Whitelisting von Grund auf – erlaubt sind bewusst mehr Tags/Attribute als WordPress‘ Standard-Editor zulässt, damit auch komplexere Layout-Strukturen im Footer möglich sind.

Sub-Button-Menüs öffnen im Footer nach oben (statt wie im Header nach unten) – rein visuell, damit das Dropdown nicht aus dem sichtbaren Bereich am unteren Seitenrand herausragt.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

Custom Footer

The Custom Footer module works exactly like the Custom Header — but for the bottom of the page. The footer you currently see on weinify.de was built with this module.

General

Buttons & Drag and Drop

Buttons are inserted into the footer content via the –buttons– placeholder and can be sorted via drag & drop. Sub-buttons for nested menus are also supported, but in the footer they open upward instead of downward. Each button can also have its own visibility: always, only for logged-in visitors, or only for logged-out visitors.

Free HTML

The footer content can contain any HTML — text, links, icons, copyright notices, or entire layout structures.

Per Site, No Shortcode

Like the header, each subsite is independently configured. The footer is automatically output on all pages of the subsite once configured and enabled in the dashboard — no shortcode needed.

Files

modules/custom_footer.php – thin module stub (init, admin page, cleanup), delegates all the actual logic to includes/weinhold_custom_layout_helpers.php, shared with Custom Header.

For Developers

Shared Foundation with Custom Header

Header and footer aren’t two separate implementations but the same logic in includes/weinhold_custom_layout_helpers.php, parameterized via $layout (‚header‘ or ‚footer‘). For the footer, weinhold_custom_layout_get_config(‚footer‘) provides the wp_footer hook, sub-menus opening upward instead of downward, and no –auth– placeholder (reserved for the header).

Storage (Per-Site Options)

Option	Content
weinhold_custom_footer_enabled	Whether the footer is actively output
weinhold_custom_footer_html	The HTML content with the –buttons– placeholder
weinhold_custom_footer_links	Array of buttons (label, target URL, parent button for sub-buttons, visibility)

Key Functions

Function	Description
weinhold_custom_layout_init($layout)	Hooks the render callback into wp_footer, assembles the button HTML including sub-buttons
weinhold_custom_layout_resolve_link_url($value)	Resolves special tokens in button targets
weinhold_custom_layout_sanitize_html($html)	Cleans stored HTML using its own extended allowlist (weinhold_custom_layout_allowed_html())
weinhold_custom_layout_get_button_visibility_class($link)	Translates a button’s visibility setting into the weinhold-show-on-login or weinhold-show-on-logout CSS class

For more detail on the shared foundation (including backwards compatibility for older buttons), see the Custom Header post.

Special Cases

Automatically suppressed on auth pages (login, registration, profile, lost password) — weinhold_user_management_is_auth_page() checks this before every output.

Free-form HTML without whitelisting from scratch — deliberately allows more tags/attributes than WordPress‘ standard editor, so more complex layout structures are possible in the footer.

Sub-button menus open upward in the footer (instead of downward like in the header) — purely visual, so the dropdown doesn’t extend past the bottom edge of the visible page.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

custom-header

Custom Header

Das Custom-Header-Modul ermöglicht die Erstellung eines vollwertigen Headers mit Navigationsbuttons und frei definierbarem HTML – komplett über das Admin-Dashboard, ohne Theme-Anpassungen. Den Header, den du gerade auf weinify.de siehst, wurde mit diesem Modul gebaut.

Allgemein

Buttons & Drag and Drop

Buttons werden über den Platzhalter –buttons– an einer beliebigen Stelle im Header-Inhalt eingefügt. Die Reihenfolge lässt sich per Drag & Drop anpassen. Buttons können Sub-Buttons enthalten, die beim Hover ein Dropdown-Menü öffnen. Pro Button lässt sich außerdem die Sichtbarkeit festlegen: immer, nur für eingeloggte oder nur für ausgeloggte Besucher.

Login-Navigation per Platzhalter

Zusätzlich zu –buttons– gibt es den Platzhalter –auth–, der an dieser Stelle die Login/Profil-Navigation des Benutzerverwaltung-Moduls einfügt (identisch zum Shortcode weinhold_auth_nav). Nur im Header verfügbar, nicht im Footer.

Pro Site, kein Shortcode

Jede Subsite konfiguriert ihren eigenen Header unabhängig. Inhalt, Buttons und Styling sind vollständig voneinander getrennt – dkj.weinify.de kann einen völlig anderen Header haben als weinify.de. Der Header wird automatisch in jede Seite der jeweiligen Subsite eingebunden, sobald er im Dashboard konfiguriert und aktiviert wurde. Kein Shortcode nötig.

Social-Vorschau

Unter den Header-Einstellungen gibt es einen eigenen Abschnitt „Social-Vorschau“. Er legt fest, welches Bild, welchen Titel und welche Beschreibung Discord, WhatsApp, Signal & Co. anzeigen, wenn ein Link zur Subsite geteilt wird (Open Graph und Twitter Card im Seitenkopf). Das Bild wird aus der Mediathek gewählt, empfohlen sind 1200 × 630 Pixel. Unterseiten verwenden ihren eigenen Titel, ein gesetztes Beitragsbild und einen bewusst geschriebenen Auszug. Ohne eigene Angaben greifen Titel, Untertitel und Website-Icon der Subsite. Optional wird die Beschreibung zusätzlich als Meta-Beschreibung für Suchmaschinen ausgegeben.

Dateien

modules/custom_header.php – Modul-Datei (Init, Admin-Seite, Cleanup) und die komplette Social-Vorschau (nur Header). Die Header-Ausgabe selbst delegiert sie an das gemeinsam mit Custom Footer genutzte includes/weinhold_custom_layout_helpers.php.

Für Entwickler

Gemeinsamer Unterbau mit Custom Footer

Header und Footer sind keine zwei getrennten Implementierungen, sondern dieselbe Logik in includes/weinhold_custom_layout_helpers.php, parametrisiert über $layout (‚header‘ oder ‚footer‘). weinhold_custom_layout_get_config($layout) liefert dazu Hook-Name (wp_head bzw. wp_footer), HTML-Tag, ob der –auth—Platzhalter unterstützt wird (nur Header) und die Öffnungsrichtung der Sub-Button-Menüs.

Speicherung (Optionen pro Site)

Option	Inhalt
weinhold_custom_header_enabled	Ob der Header aktiv ausgegeben wird
weinhold_custom_header_html	Der HTML-Inhalt mit den Platzhaltern –buttons– / –auth–
weinhold_custom_header_links	Array der Buttons (Beschriftung, Ziel-URL, übergeordneter Button für Sub-Buttons, Sichtbarkeit)
weinhold_custom_header_social_settings	Social-Vorschau: enabled, image_id, title, description, prefer_featured, output_description

Beim Footer entsprechend mit dem Präfix weinhold_custom_footer_* (ohne Social-Vorschau).

Wichtige Funktionen

Funktion	Beschreibung
weinhold_custom_layout_init($layout)	Hängt den Render-Callback an wp_head bzw. wp_footer, baut das Button-HTML inkl. Sub-Buttons zusammen
weinhold_custom_layout_resolve_link_url($value)	Löst Spezial-Tokens in Button-Zielen auf (z. B. Links auf Auth-Seiten)
weinhold_custom_layout_sanitize_html($html)	Bereinigt gespeichertes HTML über eine eigene, erweiterte Erlaubnisliste (weinhold_custom_layout_allowed_html())
weinhold_custom_layout_get_button_visibility_class($link)	Übersetzt die Sichtbarkeitseinstellung eines Buttons in die CSS-Klasse weinhold-show-on-login bzw. weinhold-show-on-logout
weinhold_custom_header_render_social_preview()	Gibt die Open-Graph- und Twitter-Card-Angaben an wp_head (Priorität 5) aus
weinhold_custom_header_social_get_meta($settings)	Ermittelt Titel, Beschreibung, URL und Typ der aktuellen Seite
weinhold_custom_header_social_get_image($settings)	Wählt Beitragsbild, Standardbild oder Website-Icon samt Größe

Die Sichtbarkeitsklassen greifen auf dieselbe CSS-Logik zurück, die auch die Shortcodes weinhold_show_on_login/weinhold_show_on_logout des Benutzerverwaltung-Moduls nutzen (weinhold_user_management_render_visibility_css()).

Besonderheiten

Wird auf Auth-Seiten (Login, Registrierung, Profil, Passwort-vergessen) automatisch unterdrückt – weinhold_user_management_is_auth_page() prüft das vor jeder Ausgabe, damit der eigene Header/Footer die dortigen Formulare nicht stört.

Rückwärtskompatibel gespeicherte Buttons: ältere Buttons ohne das neue visibility-Feld werden über das frühere boolesche Feld login_only interpretiert, statt beim Update verloren zu gehen.

Freies HTML ohne Whitelisting von Grund auf – erlaubt sind bewusst mehr Tags/Attribute als WordPress‘ Standard-Editor zulässt (eigene erweiterte Erlaubnisliste), damit auch komplexere Layout-Strukturen im Header/Footer möglich sind.

Die Social-Vorschau hat einen eigenen Schalter (standardmäßig aus) und wirkt unabhängig davon, ob der Header angezeigt wird, auch auf Auth-Seiten. Ist ein SEO-Plugin aktiv (Yoast, Rank Math, AIOSEO, SEOPress, The SEO Framework), gibt sie nichts aus, damit keine doppelten Angaben entstehen. Die Beschreibung von Unterseiten stammt nur aus einem gesetzten Auszug, nie aus dem gekürzten Inhalt, weil der Shortcodes oder geschützte Texte enthalten kann.

Versionshistorie

Version	Datum	Änderung
1.0.1	28.10.2026	Social-Vorschau (Open Graph, Twitter Card) mit Bild aus der Mediathek, Titel und Beschreibung.
1.0.0	22.09.2026	Einführung der Versionierung.

Custom Header

The Custom Header module enables building a full header with navigation buttons and freely definable HTML — entirely through the admin dashboard, without theme modifications. The header you currently see on weinify.de was built with this module.

General

Buttons & Drag and Drop

Buttons are inserted via the –buttons– placeholder at any position in the header content. Order can be adjusted via drag & drop. Buttons can contain sub-buttons that open a dropdown menu on hover. Each button can also have its own visibility: always, only for logged-in visitors, or only for logged-out visitors.

Login Navigation via Placeholder

In addition to –buttons–, there’s the –auth– placeholder, which inserts the User Management module’s login/profile navigation at that spot (identical to the weinhold_auth_nav shortcode). Available only in the header, not the footer.

Per Site, No Shortcode

Each subsite configures its own header independently. Content, buttons and styling are completely separate — dkj.weinify.de can have a completely different header than weinify.de. The header is automatically embedded into every page of the respective subsite once configured and enabled in the dashboard. No shortcode needed.

Social Preview

Below the header settings there is a separate „Social preview“ section. It defines which image, title and description Discord, WhatsApp, Signal & co. show when a link to the subsite is shared (Open Graph and Twitter Card in the page head). The image is picked from the media library, 1200 × 630 pixels are recommended. Subpages use their own title, a set featured image and a deliberately written excerpt. Without custom values, the subsite’s title, tagline and site icon are used. Optionally, the description is also output as a meta description for search engines.

Files

modules/custom_header.php – module file (init, admin page, cleanup) and the complete social preview (header only). The header output itself is delegated to includes/weinhold_custom_layout_helpers.php, shared with Custom Footer.

For Developers

Shared Foundation with Custom Footer

Header and footer aren’t two separate implementations but the same logic in includes/weinhold_custom_layout_helpers.php, parameterized via $layout (‚header‘ or ‚footer‘). weinhold_custom_layout_get_config($layout) provides the hook name (wp_head or wp_footer), the HTML tag, whether the –auth– placeholder is supported (header only), and which direction sub-button menus open.

Storage (Per-Site Options)

Option	Content
weinhold_custom_header_enabled	Whether the header is actively output
weinhold_custom_header_html	The HTML content with the –buttons– / –auth– placeholders
weinhold_custom_header_links	Array of buttons (label, target URL, parent button for sub-buttons, visibility)
weinhold_custom_header_social_settings	Social preview: enabled, image_id, title, description, prefer_featured, output_description

For the footer, the same with the weinhold_custom_footer_* prefix (without social preview).

Key Functions

Function	Description
weinhold_custom_layout_init($layout)	Hooks the render callback into wp_head or wp_footer, assembles the button HTML including sub-buttons
weinhold_custom_layout_resolve_link_url($value)	Resolves special tokens in button targets (e.g. links to auth pages)
weinhold_custom_layout_sanitize_html($html)	Cleans stored HTML using its own extended allowlist (weinhold_custom_layout_allowed_html())
weinhold_custom_layout_get_button_visibility_class($link)	Translates a button’s visibility setting into the weinhold-show-on-login or weinhold-show-on-logout CSS class
weinhold_custom_header_render_social_preview()	Outputs the Open Graph and Twitter Card tags on wp_head (priority 5)
weinhold_custom_header_social_get_meta($settings)	Determines title, description, URL and type of the current page
weinhold_custom_header_social_get_image($settings)	Picks featured image, default image or site icon including its size

The visibility classes rely on the same CSS logic used by the User Management module’s weinhold_show_on_login/weinhold_show_on_logout shortcodes (weinhold_user_management_render_visibility_css()).

Special Cases

Automatically suppressed on auth pages (login, registration, profile, lost password) — weinhold_user_management_is_auth_page() checks this before every output, so the custom header/footer doesn’t interfere with the forms there.

Backwards-compatible stored buttons: older buttons without the newer visibility field are interpreted via the earlier boolean login_only field instead of being lost on update.

Free-form HTML without whitelisting from scratch — deliberately allows more tags/attributes than WordPress‘ standard editor (its own extended allowlist), so more complex layout structures are possible in the header/footer.

The social preview has its own switch (off by default) and works independently of whether the header is shown, including on auth pages. If an SEO plugin is active (Yoast, Rank Math, AIOSEO, SEOPress, The SEO Framework), it outputs nothing to avoid duplicate tags. The description of subpages only comes from a set excerpt, never from shortened content, since that may contain shortcodes or protected text.

Version History

Version	Date	Change
1.0.1	28.10.2026	Social preview (Open Graph, Twitter Card) with image from the media library, title and description.
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

email-versand

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.

Allgemein

Konfiguration

SMTP-Server, Port, Verschlüsselung (TLS/SSL/keine), 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, sofern das netzwerkweit erlaubt ist. Ist kein SMTP konfiguriert, greift automatisch der lokale Mailserver über WordPress‘ Standard-wp_mail().

E-Mail-Templates

Andere 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 – netzwerkweit und zusätzlich pro Subsite überschreibbar. Aktuell nutzen u. a. Gerätesicherheit, Security Manager und Bastard des Monats dieses System für ihre Benachrichtigungs-Mails.

In der Praxis

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

Dateien

modules/email_delivery.php – einzige Datei des Moduls: SMTP-Konfiguration, Passwort-Verschlüsselung, Absender-Filter, komplettes E-Mail-Template-System, Admin-Oberflächen (Netzwerk + Site), Cleanup.

Für Entwickler

Ein eigenes Template registrieren

Beim eigenen Modul-Init über den Filter weinhold_email_templates einen Eintrag mit label, module, description, default_subject, default_body und variables registrieren. Immer verfügbare Platzhalter in jedem Template: {site}, {datetime}, {manage_url} – zusätzlich die selbst in variables gelisteten. Versand dann über weinhold_send_module_mail($template_id, $to, $context, $site_id) statt direktem wp_mail().

Auflösungsreihenfolge

Sowohl Absender als auch Betreff/Text eines Templates werden in der Reihenfolge Site-Override → Netzwerk-Anpassung → Modul-Default aufgelöst (weinhold_email_get_resolved_template()). Templates lassen sich netzwerkweit deaktivieren, dann sendet weinhold_send_module_mail() gar nicht erst.

SMTP-Erkennung & Passwortschutz

weinhold_email_delivery_should_use_smtp() nutzt SMTP nicht nur, wenn die Checkbox aktiv ist, sondern auch dann, wenn ein SMTP-Host UND Zugangsdaten/Auth gesetzt sind – schützt gegen ein versehentlich deaktiviertes SMTP bei sonst vollständig ausgefüllter Konfiguration. Das SMTP-Passwort wird nie im Klartext gespeichert, sondern mit AES-256-CBC verschlüsselt (Schlüssel aus dem WordPress-AUTH_KEY bzw. -Salt abgeleitet); alte Klartext-Werte werden beim Lesen automatisch erkannt und weiterhin akzeptiert (Migrationsfall).

Wichtige Funktionen

Funktion	Beschreibung
weinhold_send_module_mail($template_id,$to,$context,$site_id)	Zentraler Versand für Modul-E-Mails über das Template-System
weinhold_email_get_resolved_template($template_id,$site_id)	Löst Betreff/Text/Absender eines Templates auf
weinhold_email_delivery_get_effective_settings()	Liefert die tatsächlich wirksamen SMTP-/Absender-Einstellungen (inkl. Subsite-Override)
weinhold_email_delivery_send_test_mail($to,$scope)	Versendet eine Test-Mail und fängt Fehler zur Anzeige im Dashboard ab

Besonderheiten

Absender-Override gilt nur temporär pro Mail: weinhold_send_module_mail() hängt bei abweichendem Template-Absender kurzzeitig eigene wp_mail_from/wp_mail_from_name-Filter ein und entfernt sie sofort nach dem Versand wieder – andere, zeitgleich versendete E-Mails bleiben unberührt.

Test-Ergebnisse werden als Transient gespeichert (24 Stunden), nicht dauerhaft in Optionen – nach dem Testen im Dashboard bleibt das Ergebnis eine Weile sichtbar, verschwindet danach automatisch von selbst.

Fällt die Verschlüsselung aus irgendeinem Grund aus (z. B. openssl-Erweiterung fehlt), wird das Passwort unverschlüsselt gespeichert statt den Vorgang abzubrechen – bewusste Entscheidung gegen Datenverlust, auf Kosten geringerer Sicherheit in diesem Randfall.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

Email Delivery

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.

General

Configuration

SMTP server, port, encryption (TLS/SSL/none), 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, if allowed network-wide. If no SMTP is configured, the local mail server is used automatically via WordPress‘ default wp_mail().

Email Templates

Other modules can register their own email templates, customizable in the dashboard under Weinhold → Email Delivery → Templates with an individual subject and body — network-wide, and additionally overridable per subsite. Currently, Device Security, Security Manager, and Bastard of the Month use this system for their notification emails, among others.

In Practice

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

Files

modules/email_delivery.php – the module’s only file: SMTP configuration, password encryption, sender filters, the complete email template system, admin UIs (network + site), cleanup.

For Developers

Registering Your Own Template

In your own module’s init, register an entry with label, module, description, default_subject, default_body, and variables via the weinhold_email_templates filter. Always-available placeholders in every template: {site}, {datetime}, {manage_url} — plus whichever ones you list yourself in variables. Send via weinhold_send_module_mail($template_id, $to, $context, $site_id) instead of calling wp_mail() directly.

Resolution Order

Both the sender and the subject/body of a template are resolved in the order site override → network customization → module default (weinhold_email_get_resolved_template()). Templates can be disabled network-wide, in which case weinhold_send_module_mail() doesn’t send at all.

SMTP Detection & Password Protection

weinhold_email_delivery_should_use_smtp() uses SMTP not only when the checkbox is enabled, but also when an SMTP host AND credentials/auth are set — protects against SMTP being accidentally disabled while the rest of the configuration is otherwise complete. The SMTP password is never stored in plain text; it’s encrypted with AES-256-CBC (key derived from the WordPress AUTH_KEY/salt); old plain-text values are automatically detected on read and still accepted (migration case).

Key Functions

Function	Description
weinhold_send_module_mail($template_id,$to,$context,$site_id)	Central send path for module emails via the template system
weinhold_email_get_resolved_template($template_id,$site_id)	Resolves a template’s subject/body/sender
weinhold_email_delivery_get_effective_settings()	Returns the actually effective SMTP/sender settings (including subsite override)
weinhold_email_delivery_send_test_mail($to,$scope)	Sends a test email and captures errors for display in the dashboard

Special Cases

Sender override is only temporary per email: when a template’s sender differs, weinhold_send_module_mail() briefly hooks its own wp_mail_from/wp_mail_from_name filters and removes them right after sending — other emails sent at the same time are unaffected.

Test results are stored as a transient (24 hours), not permanently in options — after testing in the dashboard, the result stays visible for a while and then disappears on its own.

If encryption fails for any reason (e.g. the openssl extension is missing), the password is stored unencrypted instead of aborting the operation — a deliberate choice against data loss, at the cost of reduced security in that edge case.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

security-manager

Security Manager

Der Security Manager ist ein Core-Modul des Weinhold Frameworks und schützt alle Sites im Netzwerk vor Brute-Force-Angriffen und unerwünschten IPs. Er arbeitet still im Hintergrund und greift so früh wie möglich ein, teils schon bevor WordPress selbst reagiert.

Allgemein

IP-Blacklist

Bestimmte IP-Adressen können dauerhaft auf eine Sperrliste gesetzt werden. Anfragen von diesen IPs werden sofort mit 403 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 (429, Wartezeit in der Fehlermeldung genannt). Besonders geschützte Benutzerkonten (z. B. Administratoren) bekommen zusätzlich eine eigene, strengere Sperre nach Benutzername statt nach IP.

Vertrauenswürdige IPs & Notfall-Zugang

Fest hinterlegte vertrauenswürdige IPs umgehen alle Sperren komplett. Zusätzlich gibt es einen Notfall-Token: ein per URL-Parameter übergebenes Geheimnis, das bei Übereinstimmung sämtliche Sperren für die aktuelle IP sowie alle geschützten Konten aufhebt und eine zehnminütige Vertrauens-Session setzt – gedacht für den Fall, dass man sich selbst ausgesperrt hat.

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.

Dateien

modules/security_manager_core.php – einzige Datei des Moduls (Core-Modul, das _core.php-Suffix lädt es immer): Einstellungen, IP-Sperren, Lockout-Logik, Login-Hooks, Admin-Oberfläche.

Für Entwickler

Einstellungen (Option weinhold_security_settings)

Schlüssel	Bedeutung
lockout_threshold	Fehlversuche bis zur IP-Sperre (Standard 5)
lockout_duration	Sperrdauer in Minuten (Standard 15)
blacklist	Dauerhaft gesperrte IP-Adressen
trusted_ips	IPs, die alle Sperren umgehen
emergency_token	Geheimnis für den Notfall-Zugang per URL-Parameter
protected_users	Zusätzlich geschützte Benutzernamen (Super-Admins sind bei Multisite automatisch geschützt)
protected_threshold,protected_lockout_duration	Strengere Schwelle/Dauer speziell für geschützte Konten
lockout_ip_on_protected_fail	Ob ein Fehlversuch bei einem geschützten Konto zusätzlich die IP sperrt
disable_xmlrpc	XML-RPC komplett deaktivieren (Standard an)

Login-Flow (Hooks)

Hook	Priorität	Zweck
init	0	weinhold_security_handle_emergency_token() – prüft den URL-Parameter wf_emergency und hebt bei Treffer alle Sperren auf
init	1	weinhold_security_check_ip() – blockiert blacklistete/gesperrte IPs auf JEDEM Request, nicht nur beim Login
login_init	1	weinhold_security_block_native_auth() – leitet wp-login.php-Aufrufe auf die eigenen Auth-Seiten des user_management-Moduls um
login_init	2	weinhold_security_block_locked_login() – blockiert Login-POSTs gesperrter IPs, bevor WordPress die Zugangsdaten prüft
login_init	3	weinhold_security_block_gateless_post() – blockiert Login-POSTs ohne gültiges Login-Gate-Cookie, falls das login_gate-Modul aktiv ist
authenticate	30	weinhold_security_authenticate() – liefert WP_Error bei gesperrter IP oder gesperrtem geschütztem Konto
wp_login_failed	10	weinhold_security_login_failed() – zählt Fehlversuche hoch, versendet Benachrichtigungs-Mails

IP-Ermittlung

weinhold_security_get_client_ip() prüft der Reihe nach CF-Connecting-IP, X-Real-IP, X-Forwarded-For und REMOTE_ADDR und nimmt die erste gültige IP-Adresse – wichtig hinter Reverse-Proxy/CDN, damit nicht die Proxy-IP statt der echten Besucher-IP gesperrt wird.

Besonderheiten

Läuft parallel zum user_management-Modul: Beide Module leiten wp-login.php-Aufrufe auf die eigenen Auth-Seiten um (security_manager auf login_init, user_management ebenfalls) – bewusst redundant abgesichert, nicht als Bug zu verstehen.

Blacklist- und Lockout-Prüfung laufen bereits auf init mit Priorität 1, also auf JEDEM Seitenaufruf der ganzen Website, nicht nur beim Login – eine geblacklistete IP kommt gar nicht erst auf normale Seiten.

Der Notfall-Token gibt nie einen Hinweis, ob er falsch war (stiller Fehlschlag) – verhindert, dass jemand per Trial-and-Error herausfindet, ob überhaupt ein Token konfiguriert ist.

E-Mail-Adressen im Login-Feld werden vor der Sperrprüfung auf den echten Benutzernamen aufgelöst, damit Lockout-Zähler für „admin“ und „admin@example.com“ nicht getrennt gezählt werden.

XML-RPC wird standardmäßig komplett deaktiviert (xmlrpc_enabled-Filter auf false) – ein häufiges Ziel für Brute-Force-Bots, das WordPress sonst parallel zum normalen Login offen lässt.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

Security Manager

Security Manager is a core module of the Weinhold Framework and protects all sites in the network from brute-force attacks and unwanted IPs. It works silently in the background and intervenes as early as possible, in some cases before WordPress itself even responds.

General

IP Blacklist

Specific IP addresses can be permanently added to a blocklist. Requests from these IPs are blocked immediately with a 403 — 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 (429, wait time stated in the error message). Specially protected user accounts (e.g. administrators) additionally get their own, stricter lockout by username instead of by IP.

Trusted IPs & Emergency Access

Permanently configured trusted IPs bypass all locks entirely. There’s also an emergency token: a secret passed via a URL parameter that, when it matches, clears all locks for the current IP and all protected accounts and sets a ten-minute trust session — meant for the case where you’ve locked yourself out.

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.

Files

modules/security_manager_core.php – the module’s only file (core module, the _core.php suffix always loads it): settings, IP blocking, lockout logic, login hooks, admin UI.

For Developers

Settings (Option weinhold_security_settings)

Key	Meaning
lockout_threshold	Failed attempts before an IP lock (default 5)
lockout_duration	Lock duration in minutes (default 15)
blacklist	Permanently blocked IP addresses
trusted_ips	IPs that bypass all locks
emergency_token	Secret for emergency access via URL parameter
protected_users	Additionally protected usernames (super admins are automatically protected on Multisite)
protected_threshold,protected_lockout_duration	Stricter threshold/duration specifically for protected accounts
lockout_ip_on_protected_fail	Whether a failed attempt on a protected account also locks the IP
disable_xmlrpc	Disable XML-RPC entirely (default on)

Login Flow (Hooks)

Hook	Priority	Purpose
init	0	weinhold_security_handle_emergency_token() – checks the wf_emergency URL parameter and clears all locks on a match
init	1	weinhold_security_check_ip() – blocks blacklisted/locked IPs on EVERY request, not just login
login_init	1	weinhold_security_block_native_auth() – redirects wp-login.php calls to the user_management module’s own auth pages
login_init	2	weinhold_security_block_locked_login() – blocks login POSTs from locked IPs before WordPress checks the credentials
login_init	3	weinhold_security_block_gateless_post() – blocks login POSTs without a valid login-gate cookie if the login_gate module is active
authenticate	30	weinhold_security_authenticate() – returns a WP_Error for a locked IP or a locked protected account
wp_login_failed	10	weinhold_security_login_failed() – increments failure counters, sends notification emails

IP Detection

weinhold_security_get_client_ip() checks, in order, CF-Connecting-IP, X-Real-IP, X-Forwarded-For and REMOTE_ADDR and takes the first valid IP address — important behind a reverse proxy/CDN, so the proxy’s IP doesn’t get locked instead of the real visitor’s IP.

Special Cases

Runs in parallel with the user_management module: both modules redirect wp-login.php calls to the custom auth pages (security_manager on login_init, user_management as well) — deliberately redundant, not a bug.

Blacklist and lockout checks already run on init at priority 1, i.e. on EVERY page load of the whole site, not just at login — a blacklisted IP never even reaches normal pages.

The emergency token never reveals whether it was wrong (a silent failure) — prevents someone from figuring out by trial and error whether a token is even configured.

Email addresses entered in the login field are resolved to the real username before the lock check, so lockout counters for „admin“ and „admin@example.com“ aren’t counted separately.

XML-RPC is disabled entirely by default (xmlrpc_enabled filter returns false) — a common target for brute-force bots that WordPress otherwise leaves open alongside the normal login.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

geraetesicherheit

Gerätesicherheit

Die Gerätesicherheit ist ein Core-Modul des Weinhold Frameworks – es ist immer geladen (lässt sich aber über eine eigene Einstellung ein-/ausschalten) und wirkt netzwerkweit auf allen Sites. Es erkennt unbekannte Geräte beim Login und verlangt eine Sicherheitsfrage, bevor der Zugang gewährt wird – eine zusätzliche Schutzschicht, die auch bei einem kompromittierten Passwort greift.

Allgemein

Wie es funktioniert

Beim Login prüft das Modul per Cookie, ob das aktuelle Gerät bereits als vertrauenswürdig hinterlegt ist. Ist das Gerät unbekannt und hat der Nutzer Sicherheitsfragen eingerichtet, wird der Login abgefangen und eine zufällig ausgewählte Frage gestellt. Erst nach korrekter Antwort wird der Nutzer eingeloggt; auf Wunsch merkt sich das Modul das Gerät danach für eine konfigurierbare Anzahl Tage.

Hat ein Nutzer noch keine Sicherheitsfragen hinterlegt, wird der Login trotzdem erlaubt – im Profil erscheint dann ein Hinweis, sie einzurichten. So wird niemand ausgesperrt, der die Funktion noch nicht konfiguriert hat.

Sicherheitsfragen (Profil)

Jeder Nutzer richtet im eigenen Profil bis zu drei Sicherheitsfragen ein (die erste ist Pflicht, sobald mindestens eine gespeichert werden soll). Zur Auswahl stehen sechs vorgeschlagene Fragen oder ein freier Text. Die Antworten werden nie im Klartext gespeichert, sondern nur als Hash – beim Bearbeiten muss deshalb jedes Feld neu ausgefüllt werden; ein leer gelassenes Antwortfeld behält die bestehende gespeicherte Antwort.

Vertrauenswürdige Geräte

Im Profil sieht jeder Nutzer eine Liste seiner vertrauenswürdigen Geräte (Browser-/Geräte-Kennung, IP, zuletzt genutzt) und kann einzelne Geräte entfernen. Der Button „Auf allen Geräten ausloggen“ beendet zusätzlich alle aktiven Sitzungen und löscht alle gespeicherten Geräte auf einen Schlag.

Admin-Einstellungen

Unter Weinhold Netzwerk → Gerätesicherheit lässt sich das Modul aktivieren/deaktivieren, die Benachrichtigungs-Mail bei neuem Gerät ein-/ausschalten und die Gültigkeitsdauer eines vertrauenswürdigen Geräts festlegen (1–3650 Tage). Da das Modul netzwerkweit wirkt, gibt es keine Einstellungen pro Site – ein Site-Admin wird beim Aufruf automatisch zum Netzwerk-Admin weitergeleitet.

Dateien

modules/device_security_core.php – einzige Datei des Moduls (Core-Modul, das _core.php-Suffix lädt es immer): Datenbank, Einstellungen, Cookie- und Token-Verwaltung, Sicherheitsfragen, Login-Hooks, Profil- und Admin-Oberfläche.

Für Entwickler

Datenbank

Spalte	Typ	Bedeutung
id	bigint,Auto-Increment	Primärschlüssel
user_id	bigint	Zugehöriger Nutzer
token_hash	varchar(64),unique	SHA-256-Hash des Geräte-Tokens
label	varchar(255)	Kurzbeschreibung, meist der User-Agent
ip	varchar(45)	IP-Adresse bei der Verifizierung
created_at	datetime	Erstellt (UTC)
last_used	datetime	Zuletzt genutzt (UTC)

Tabellenname über weinhold_device_table(), Installation via weinhold_device_maybe_install() (versioniert über die Option weinhold_device_security_db_version auf der Hauptseite).

Login-Flow (Hooks)

Hook	Priorität	Zweck
authenticate	35	weinhold_device_authenticate() – nach erfolgreicher WP-Authentifizierung: bekanntes Gerät durchlassen, unbekanntes Gerät mit vorhandenen Fragen liefert WP_Error(‚weinhold_device_challenge‘, …, $chal_token) statt des Logins
wp_login_failed	5	weinhold_device_handle_login_failed() – fängt den Error-Code weinhold_device_challenge ab und leitet zur Challenge-Seite um
wp_login	10	weinhold_device_on_login_success() – aktualisiert last_used bei bekanntem Gerät

Die Challenge selbst liegt 5 Minuten als Transient (weinhold_dev_chal_{32-Zeichen-Hex-Token}) und enthält Nutzer-ID, „Angemeldet bleiben“-Flag, Redirect-Ziel und den Index der gestellten Frage.

Wichtige Funktionen

Funktion	Beschreibung
weinhold_device_is_trusted($user_id,$raw_token):bool	Prüft ob ein Geräte-Token zu diesem Nutzer gehört
weinhold_device_save_token($user_id,$raw_token,$label,$ip)	Speichert ein neues vertrauenswürdiges Gerät
weinhold_device_revoke_token($device_id,$user_id)	Entfernt ein einzelnes Gerät
weinhold_device_revoke_all($user_id)	Entfernt alle Geräte eines Nutzers
weinhold_device_logout_everywhere($user_id)	Zerstört alle Sessions (WP_Session_Tokens) und alle Geräte-Tokens
weinhold_device_has_questions($user_id):bool	Ob der Nutzer Sicherheitsfragen eingerichtet hat
weinhold_device_verify_answer($user_id,$question_index,$raw_answer):bool	Prüft eine Antwort per hash_equals() gegen den gespeicherten SHA-256-Hash

Integrationspunkte

Filter weinhold_auth_login_override – rendert das Challenge-Formular anstelle des normalen Login-Formulars, wenn der GET-Parameter device_challenge gesetzt ist (genutzt vom user_management-Modul).

Filter weinhold_auth_profile_extra – hängt die Profil-Sektion (Sicherheitsfragen, Geräteliste) an die Profilseite an.

Filter weinhold_email_templates – registriert die zwei modul-eigenen Vorlagen device_new und device_challenge_failed beim E-Mail-Versand-Modul.

Filter weinhold_audit_modules – meldet sich beim Audit-Log mit den Aktionen device_verified, device_revoked, challenge_failed, logout_everywhere an.

Besonderheiten

Netzwerkweit statt pro Site – es gibt bewusst keine Site-Einstellungen; ein Site-Admin, der die Modulseite aufruft, wird automatisch zum Netzwerk-Admin weitergeleitet.

Sicherheitsfragen werden nur als hash(’sha256′, …) der kleingeschriebenen, getrimmten Antwort gespeichert, nie im Klartext – der Abgleich läuft über hash_equals(), um Timing-Angriffe zu vermeiden.

Kein Zwang zur Einrichtung: Ohne gespeicherte Sicherheitsfragen wird der Login trotzdem erlaubt, nur ein Hinweis-Transient (10 Minuten) sorgt für einen Einrichtungs-Hinweis im Profil.

Geräte-Cookie weinhold_device_trust_{COOKIEHASH} ist HttpOnly und SameSite=Strict, bei SSL zusätzlich Secure – auf PHP-Versionen unterhalb von 7.3 übernimmt ein Fallback mit manuell zusammengesetztem Pfad-String dieselbe SameSite-Einstellung.

Eine fehlgeschlagene Sicherheitsfrage löst eine separate Warn-Mail aus (device_challenge_failed) – anders als eine neue erfolgreiche Verifizierung, die nur informiert.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

Device Security

Device Security is a core module of the Weinhold Framework – it is always loaded (though it can be switched on/off via its own setting) and works network-wide across all sites. It detects unknown devices at login and requires a security question before granting access — an additional layer of protection that works even with a compromised password.

General

How It Works

At login, the module checks via cookie whether the current device is already marked as trusted. If the device is unknown and the user has set up security questions, the login is intercepted and a randomly chosen question is asked. Only after answering correctly is the user logged in; on request, the module then remembers the device for a configurable number of days.

If a user hasn’t set up any security questions yet, login is still allowed — a hint to set them up then appears on the profile page. This way nobody gets locked out just because they haven’t configured the feature yet.

Security Questions (Profile)

Every user sets up up to three security questions in their own profile (the first is required as soon as at least one should be saved). Six suggested questions are offered, or free text. Answers are never stored in plain text, only as a hash — editing therefore requires filling in every field again; leaving an answer field empty keeps the existing stored answer.

Trusted Devices

On their profile, every user sees a list of their trusted devices (browser/device label, IP, last used) and can remove individual devices. The „Log out everywhere“ button additionally ends all active sessions and clears all stored devices in one go.

Admin Settings

Under Weinhold Network → Device Security, the module can be enabled/disabled, the new-device notification email toggled, and the trusted-device validity period set (1–3650 days). Since the module works network-wide, there are no per-site settings — a site admin who opens the page is automatically redirected to the network admin.

Files

modules/device_security_core.php – the module’s only file (core module, the _core.php suffix always loads it): database, settings, cookie and token management, security questions, login hooks, profile and admin UI.

For Developers

Database

Column	Type	Meaning
id	bigint,auto-increment	Primary key
user_id	bigint	The associated user
token_hash	varchar(64),unique	SHA-256 hash of the device token
label	varchar(255)	Short description, usually the user agent
ip	varchar(45)	IP address at verification time
created_at	datetime	Created (UTC)
last_used	datetime	Last used (UTC)

Table name via weinhold_device_table(), installed via weinhold_device_maybe_install() (versioned through the weinhold_device_security_db_version option on the main site).

Login Flow (Hooks)

Hook	Priority	Purpose
authenticate	35	weinhold_device_authenticate() – after successful WP authentication: lets known devices through, an unknown device with existing questions returns WP_Error(‚weinhold_device_challenge‘, …, $chal_token) instead of the login
wp_login_failed	5	weinhold_device_handle_login_failed() – catches the weinhold_device_challenge error code and redirects to the challenge page
wp_login	10	weinhold_device_on_login_success() – updates last_used for a known device

The challenge itself lives for 5 minutes as a transient (weinhold_dev_chal_{32-char hex token}) and holds the user ID, the „remember me“ flag, the redirect target and the index of the question asked.

Key Functions

Function	Description
weinhold_device_is_trusted($user_id,$raw_token):bool	Checks whether a device token belongs to this user
weinhold_device_save_token($user_id,$raw_token,$label,$ip)	Stores a new trusted device
weinhold_device_revoke_token($device_id,$user_id)	Removes a single device
weinhold_device_revoke_all($user_id)	Removes all devices of a user
weinhold_device_logout_everywhere($user_id)	Destroys all sessions (WP_Session_Tokens) and all device tokens
weinhold_device_has_questions($user_id):bool	Whether the user has set up security questions
weinhold_device_verify_answer($user_id,$question_index,$raw_answer):bool	Checks an answer via hash_equals() against the stored SHA-256 hash

Integration Points

Filter weinhold_auth_login_override – renders the challenge form instead of the normal login form when the device_challenge GET parameter is set (used by the user_management module).

Filter weinhold_auth_profile_extra – appends the profile section (security questions, device list) to the profile page.

Filter weinhold_email_templates – registers the module’s two own templates, device_new and device_challenge_failed, with the Email Delivery module.

Filter weinhold_audit_modules – registers with the Audit Log, reporting the actions device_verified, device_revoked, challenge_failed, logout_everywhere.

Special Cases

Network-wide instead of per site — there are deliberately no site-level settings; a site admin who opens the module page is automatically redirected to the network admin.

Security question answers are only ever stored as hash(’sha256′, …) of the lowercased, trimmed answer, never in plain text — comparison uses hash_equals() to avoid timing attacks.

No requirement to set them up: without saved security questions, login is still allowed, only a hint transient (10 minutes) triggers a setup reminder on the profile page.

The device cookie weinhold_device_trust_{COOKIEHASH} is HttpOnly and SameSite=Strict, plus Secure over SSL — on PHP versions below 7.3 a fallback with a manually assembled path string applies the same SameSite setting.

A failed security question triggers a separate warning email (device_challenge_failed) — unlike a new successful verification, which only informs.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

benutzerverwaltung

Benutzerverwaltung

Die Benutzerverwaltung ist ein Core-Modul des Weinhold Frameworks und das zentrale Authentifizierungssystem – Registrierung, Login, Profilbearbeitung, Passwort-Reset und Rollenzuweisung laufen netzwerkweit über eigene Shortcode-Seiten statt über die WordPress-Standardseiten.

Allgemein

Eigene Login-Seiten statt wp-login.php

Login, Registrierung, Profil und Passwort-vergessen laufen über eigene, per Shortcode gebaute Seiten (meist auf der Hauptsite, netzwerkweit gültig). Aufrufe von wp-login.php werden automatisch auf die passende eigene Seite umgeleitet – nur der eigentliche Formular-POST für den Login selbst sowie technische Flows (Logout, Postpass, Bestätigungslinks) bleiben unangetastet.

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. Die Rolle eines Nutzers wird dabei immer pro Site einzeln ermittelt (Multisite-Capabilities), nicht netzwerkweit einheitlich.

Profilbild (Avatar)

Nutzer können über das Profil ein eigenes Profilbild hochladen, das Gravatar/Identicon ersetzt – wahlweise netzwerkweit gültig (global) oder nur für die aktuelle Site (lokal, überschreibt global). Fallback-Reihenfolge: Site-spezifisch → Global → WordPress-Standard.

Shortcodes

Shortcode	Beschreibung
weinhold_auth_login	Login-Formular
weinhold_auth_register	Registrierungsformular für neue Benutzer
weinhold_auth_profile	Profilansicht und -bearbeitung für angemeldete Benutzer (Passwort ändern, Avatar hochladen)
weinhold_auth_lostpassword	Formular zum Zurücksetzen des Passworts
weinhold_auth_nav	Navigationsleiste mit Links zu Login, Profil und weiteren Bereichen
weinhold_show_on_login	Umschlossener Inhalt wird nur angemeldeten Besuchern angezeigt
weinhold_show_on_logout	Umschlossener Inhalt wird nur abgemeldeten Besuchern (Gästen) angezeigt

Dateien

modules/user_management_core.php – einzige Datei des Moduls (Core-Modul, das _core.php-Suffix lädt es immer, mit Abstand die größte Moduldatei des Frameworks): Auth-Seiten-Verwaltung, Shortcode-Formulare, Rollen-/Rechte-Auflösung, Redirect-Schutz, Netzwerk- und Site-Admin-Seiten, Avatar-System.

Für Entwickler

Auth-Seiten (zentral konfiguriert)

Die Ziel-Seiten für Login/Registrierung/Profil/Passwort-vergessen werden als Post-IDs in der Netzwerk-Option weinhold_network_auth_settings gespeichert (auth_blog_id plus je eine Page-ID pro Zweck). weinhold_user_management_get_auth_page_url($key) löst daraus die tatsächliche Permalink-URL auf (wechselt bei Multisite kurz auf den konfigurierten auth_blog_id via switch_to_blog()).

Rollen & Capabilities

Funktion	Beschreibung
weinhold_user_management_get_roles_for_site($site_id)	Editierbare Rollen einer Site (get_editable_roles(), pro Site via switch_to_blog())
weinhold_user_management_get_user_role_for_site($user_id,$site_id)	Liest die Rolle eines Nutzers direkt aus dessen Capabilities-Meta der jeweiligen Site
weinhold_user_management_get_default_role($roles)	Vorbelegte Rolle bei der Registrierung (subscriber, falls vorhanden, sonst die erste verfügbare)
weinhold_user_management_sort_roles_for_display($roles)	Sortiert Rollen fuer die Anzeige: WordPress-Systemrollen zuerst in fester Reihenfolge, Rest alphabetisch

Redirect-Validierung

weinhold_user_management_validate_login_redirect_target($redirect_raw) normalisiert und prüft jedes redirect_to-Ziel gegen Open-Redirect-Angriffe: HTML-Entities und mehrfach URL-kodierte Werte werden dekodiert, schema-lose Domains erkannt, und am Ende nur relative Pfade, per wp_validate_redirect() erlaubte Hosts oder (bei Multisite) Domains anderer Netzwerk-Sites akzeptiert – sonst greift ein Fallback auf die Startseite.

Profilbild-Auflösung

Eingehängt über den WordPress-Filter pre_get_avatar_data, wirkt dadurch automatisch überall wo get_avatar_url()/get_avatar() aufgerufen wird. Zwei Speicherebenen: global per update_user_meta($uid,’weinhold_avatar_global‘,$url) (netzwerkweit) und lokal per update_user_option($uid,’weinhold_avatar_local‘,$url,false) (nur aktuelle Site, hat Vorrang). weinhold_um_get_avatar_url($user_id) liefert die aufgelöste URL oder einen leeren String, wenn kein eigenes Bild hinterlegt ist. Upload-Verzeichnis: uploads/weinhold-avatars/ (bei Multisite-Subsites entsprechend unter uploads/sites/{id}/).

Besonderheiten

wp-login.php bleibt technisch erreichbar (WordPress braucht es intern), wird aber bei GET-Aufrufen automatisch auf die konfigurierte eigene Seite umgeleitet – der Login-POST selbst läuft weiterhin über wp-login.php, damit WordPress-Auth-Cookies korrekt gesetzt werden.

Fehlgeschlagene Logins über wp-login.php werden ebenfalls abgefangen (wp_login_failed-Hook), damit Fehlermeldungen auf der eigenen Login-Seite statt auf der WordPress-Standardseite erscheinen.

Angemeldete Nutzer, die eine Auth-Seite (Login/Registrierung) direkt aufrufen, werden per template_redirect automatisch weggeleitet (z. B. zum Profil) – verhindert ein erneutes Login-Formular für bereits eingeloggte Besucher.

Admin-Bar im Frontend ist standardmäßig ausgeblendet (auch für Administratoren, konfigurierbar unter Weinhold → Nutzerverwaltung → UI-Einstellungen) – Ausnahme lässt sich pro Einstellung gezielt wieder aktivieren.

allowed_redirect_hosts wird um alle Domains des Multisite-Netzwerks erweitert, damit wp_safe_redirect() auch netzwerkinterne Ziel-Sites als sicher akzeptiert.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

User Management

User Management is a core module of the Weinhold Framework and the central authentication system – registration, login, profile editing, password resets and role assignment run network-wide through dedicated shortcode pages instead of the default WordPress pages.

General

Custom Login Pages Instead of wp-login.php

Login, registration, profile and lost-password run through dedicated, shortcode-built pages (usually on the main site, valid network-wide). Requests to wp-login.php are automatically redirected to the matching custom page – only the actual login form POST itself and technical flows (logout, postpass, confirmation links) are left untouched.

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. A user’s role is always resolved per site (Multisite capabilities), never uniformly across the whole network.

Profile Picture (Avatar)

Users can upload their own profile picture via the profile page, replacing Gravatar/identicon — either network-wide (global) or only for the current site (local, overrides global). Fallback order: site-specific → global → WordPress default.

Shortcodes

Shortcode	Description
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
weinhold_show_on_login	Wrapped content is shown only to logged-in visitors
weinhold_show_on_logout	Wrapped content is shown only to logged-out visitors (guests)

Files

modules/user_management_core.php – the module’s only file (core module, the _core.php suffix always loads it, by far the largest module file in the framework): auth page management, shortcode forms, role/permission resolution, redirect protection, network and site admin pages, avatar system.

For Developers

Auth Pages (Centrally Configured)

The target pages for login/registration/profile/lost-password are stored as post IDs in the network option weinhold_network_auth_settings (auth_blog_id plus one page ID per purpose). weinhold_user_management_get_auth_page_url($key) resolves the actual permalink URL from that (briefly switches to the configured auth_blog_id via switch_to_blog() on Multisite).

Roles & Capabilities

Function	Description
weinhold_user_management_get_roles_for_site($site_id)	Editable roles of a site (get_editable_roles(), per site via switch_to_blog())
weinhold_user_management_get_user_role_for_site($user_id,$site_id)	Reads a user’s role directly from that site’s capabilities meta
weinhold_user_management_get_default_role($roles)	Default role pre-selected at registration (subscriber if available, otherwise the first one)
weinhold_user_management_sort_roles_for_display($roles)	Sorts roles for display: WordPress system roles first in a fixed order, the rest alphabetically

Redirect Validation

weinhold_user_management_validate_login_redirect_target($redirect_raw) normalizes and checks every redirect_to target against open-redirect attacks: HTML entities and repeatedly URL-encoded values are decoded, schema-less domains are recognized, and in the end only relative paths, hosts allowed via wp_validate_redirect(), or (on Multisite) domains of other network sites are accepted — otherwise it falls back to the homepage.

Avatar Resolution

Hooked in via the WordPress filter pre_get_avatar_data, so it applies automatically wherever get_avatar_url()/get_avatar() is called. Two storage levels: global via update_user_meta($uid,’weinhold_avatar_global‘,$url) (network-wide) and local via update_user_option($uid,’weinhold_avatar_local‘,$url,false) (current site only, takes precedence). weinhold_um_get_avatar_url($user_id) returns the resolved URL, or an empty string if no custom image is set. Upload directory: uploads/weinhold-avatars/ (on Multisite subsites, under uploads/sites/{id}/ accordingly).

Special Cases

wp-login.php remains technically reachable (WordPress needs it internally), but GET requests to it are automatically redirected to the configured custom page — the login POST itself still goes through wp-login.php so WordPress auth cookies are set correctly.

Failed logins via wp-login.php are also intercepted (wp_login_failed hook), so error messages appear on the custom login page instead of the WordPress default page.

Logged-in users who directly open an auth page (login/registration) are automatically redirected away via template_redirect (e.g. to their profile) — prevents showing a login form again to an already logged-in visitor.

The admin bar on the frontend is hidden by default (even for administrators, configurable under Weinhold → User Management → UI Settings) — the exception can be re-enabled per setting.

allowed_redirect_hosts is extended with all domains of the Multisite network, so wp_safe_redirect() also accepts network-internal target sites as safe.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

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.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

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.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

shortcodes

Shortcodes

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

Allgemein

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, ohne den Code der einzelnen Module durchsuchen zu müssen.

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.

Dateien

modules/shortcode_core.php – einzige Datei des Moduls (Core-Modul, das _core.php-Suffix lädt es immer): Registrierungsfunktion, Fehlerbehandlung pro Shortcode, Parameter-Katalog als Fallback, Admin-Übersichtsseite.

Für Entwickler

Registrierung

weinhold_add_shortcode($tag,$callback,$description,$parameters=null) ist die empfohlene Art, einen Shortcode zu registrieren – nutzt intern die normale WordPress-Funktion add_shortcode(), wickelt den Callback dabei aber in einen eigenen try/catch. So kann eine unbehandelte Exception oder ein Fehler in EINEM Modul-Shortcode nicht die ganze Seite mit einem PHP-Fatal-Error zum Absturz bringen.

Parameter-Dokumentation

Wird $parameters beim Aufruf nicht mitgegeben, versucht weinhold_resolve_shortcode_parameters() der Reihe nach: einen fest hinterlegten Eintrag im internen Parameter-Katalog (vor allem für die zahlreichen pnp_book_*-Shortcodes des PnP-Book-Moduls, deren Parameter historisch hier statt im jeweiligen Modul gepflegt werden), einen Treffer per normalisiertem Tag-Namen (Umlaute/Akzente werden dabei vereinheitlicht, z. B. pnp_book_effektivitaeten und pnp_book_effektivitäten gelten als derselbe Eintrag), oder das Auslesen eines „Attribute: …“-Hinweises direkt aus der Beschreibung.

Admin-Übersicht

weinhold_render_core_shortcode_page() rendert unter Weinhold → Shortcodes eine alphabetisch sortierte Tabelle aller registrierten Shortcodes mit Tag, Beschreibung und aufgelösten Parametern.

Besonderheiten

Fehlerbehandlung ist rollenabhängig: Schlägt ein Shortcode fehl, sehen Administratoren (manage_options) die vollständige Fehlermeldung inkl. Datei und Zeile direkt auf der Seite, alle anderen Besucher nur einen neutralen Hinweis ohne technische Details. Der volle Fehler landet zusätzlich immer im PHP-Error-Log.

Nur Module, die tatsächlich weinhold_add_shortcode() statt des nativen add_shortcode() nutzen, profitieren vom Error-Handling und tauchen in der Admin-Übersicht auf – ein Modul kann trotzdem direkt add_shortcode() verwenden, verliert dann aber beides.

Der Parameter-Katalog enthält deutlich mehr Einträge als aktuell aktive Module Shortcodes registrieren (u. a. alle pnp_book_*-Varianten) – bewusst als zentrale Fallback-Dokumentation gepflegt, unabhängig davon, ob das jeweilige Modul gerade aktiv ist.

Versionshistorie

Version Datum Änderung
1.0.0 22.09.2026 Einführung der Versionierung.

Shortcodes

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

General

How It Works

Each module calls weinhold_add_shortcode() on load, passing a tag, callback, description, and optional parameter documentation. The module collects all entries and lists them clearly in the admin dashboard under Weinhold → Shortcodes — giving you a full overview of every available shortcode without having to search through each module’s code.

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.

Files

modules/shortcode_core.php – the module’s only file (core module, the _core.php suffix always loads it): registration function, per-shortcode error handling, parameter catalog as a fallback, admin overview page.

For Developers

Registration

weinhold_add_shortcode($tag,$callback,$description,$parameters=null) is the recommended way to register a shortcode — internally uses the normal WordPress add_shortcode() function, but wraps the callback in its own try/catch. This means an unhandled exception or error in ONE module’s shortcode can’t crash the entire page with a PHP fatal error.

Parameter Documentation

If $parameters isn’t passed in the call, weinhold_resolve_shortcode_parameters() tries, in order: a fixed entry in the internal parameter catalog (mainly for the many pnp_book_*-shortcodes of the PnP Book module, whose parameters are historically maintained here rather than in that module), a match via normalized tag name (umlauts/accents are unified, e.g. pnp_book_effektivitaeten and pnp_book_effektivitäten count as the same entry), or reading an „Attribute: …“ hint directly out of the description.

Admin Overview

weinhold_render_core_shortcode_page() renders an alphabetically sorted table of all registered shortcodes with tag, description and resolved parameters under Weinhold → Shortcodes.

Special Cases

Error handling depends on the user’s role: if a shortcode fails, administrators (manage_options) see the full error message including file and line directly on the page, all other visitors only see a neutral notice with no technical details. The full error is always additionally written to the PHP error log.

Only modules that actually use weinhold_add_shortcode() instead of the native add_shortcode() benefit from the error handling and show up in the admin overview — a module can still use add_shortcode() directly, but then loses both.

The parameter catalog contains noticeably more entries than currently active modules register shortcodes for (including all pnp_book_* variants) — deliberately kept as central fallback documentation, independent of whether the respective module is currently active.

Version History

Version Date Change
1.0.0 22.09.2026 Introduction of versioning.

10. Juni 2026

kalender

Kalender

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.

Allgemein

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) und Öffentlich (jeder kann den Termin sehen, auch ohne Login – erfordert eine eigene, separat vergebene Berechtigung). Jeder Termin kann außerdem einen optionalen externen Link tragen.

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, wahlweise über WP-Cron oder einen externen Server-Cron (Einstellung pro Modul, wie im gesamten Framework üblich).

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.

Navigation

Ein Kalender-Link wird automatisch in die Navigation des Benutzerverwaltung-Moduls (weinhold_auth_nav) eingehängt.

Shortcodes

Shortcode	Beschreibung
weinhold_calendar	Persönlicher Kalender (nur eingeloggte Nutzer): zeigt alle Termine netzwerkweit, die der Nutzer sehen darf. Beim Aktivieren des Moduls wird automatisch eine Seite unter /kalender mit diesem Shortcode erstellt
weinhold_public_calendar	Öffentlicher Kalender der aktuellen Webseite: nicht eingeloggte Besucher sehen nur öffentliche Termine, eingeloggte Nutzer alle Termine dieser Webseite

Dateien

modules/calendar.php – einzige Datei des Moduls: Datenbank inkl. versionierter Migrationen, Termin-/Farbverwaltung, Erinnerungs-Cronjob, Frontend-Formularverarbeitung, beide Shortcodes, Admin-Seite, Cleanup.

Für Entwickler

Datenbank

Tabelle	Spalten	(Auswahl)
weinhold_calendar_events	site_id, creator_user_id, caption, description, event_link, visibility	(0 Netzwerk/1 Privat/2 Öffentlich), event_dt_gmt
weinhold_calendar_event_users	event_id, user_id, wants_reminder, reminder_sent_at_gmt
weinhold_calendar_user_settings	user_id, reminder_days
weinhold_calendar_site_colors	user_id, site_id, color

Versionierte Migration bis DB-Version 3: v2 auf v3 benennt is_private in visibility um (aus bool wird dreiwertig), fügt event_link hinzu und wants_reminder in der Teilnehmer-Tabelle.

Eigene Berechtigung für öffentliche Termine

Über den Filter weinhold_registered_capabilities registriert das Modul die zusätzliche Capability weinhold_calendar_create_public_event – eine eigene, feinere Berechtigung oberhalb der normalen Modul-Edit-Rechte, weil ein öffentlicher Termin auch ohne Login sichtbar ist und damit sensibler ist als ein normaler Netzwerk-Termin.

E-Mail-Template & Cron

Registriert das Template calendar_reminder beim E-Mail-Versand-Modul (Platzhalter display_name, count, when, events) und nutzt es über weinhold_send_module_mail() für den täglichen Erinnerungsversand. Der tägliche Cron-Job wird ausschließlich auf der Hauptsite eingerichtet (Modul-Scope: network) und respektiert den zentralen Cron-Modus-Schalter (weinhold_cron_mode_is_extern(‚calendar‘)) – bei externem Cron übernimmt WP-Cron das Scheduling nicht selbst.

Besonderheiten

Trotz Modul-Scope network sind Termine site_id-getaggt und Farben pro Nutzer UND Site konfigurierbar – „netzwerkweit“ bedeutet hier, dass ein Nutzer die Termine ALLER Sites in einem gemeinsamen persönlichen Kalender sieht, nicht dass es nur einen einzigen, undifferenzierten Termin-Pool ohne Site-Bezug gibt.

Die Migration von is_private (boolesch) zu visibility (dreiwertig) zeigt, dass „Öffentlich“ nachträglich als dritte Sichtbarkeitsstufe hinzugefügt wurde – ältere, per Datenbank-Upgrade migrierte Installationen haben dieselbe Spalte nur unter neuem Namen und mit erweitertem Wertebereich.

Die Berechtigung für öffentliche Termine läuft über eine eigene Capability statt über das generische Modul-Edit-Recht – wer Termine bearbeiten darf, darf noch lange keine öffentlichen, nicht-login-pflichtigen Termine erstellen.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

Calendar

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.

General

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), and Public (everyone can see the event, even without login — requires its own, separately granted permission). Every event can also carry an optional external link.

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 a cron job, either via WP-Cron or an external server cron (a per-module setting, as is standard across the framework).

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.

Navigation

A calendar link is automatically inserted into the User Management module’s navigation (weinhold_auth_nav).

Shortcodes

Shortcode	Description
weinhold_calendar	Personal calendar (logged-in users only): shows all network-wide events the user has access to. When the module is activated, a page at /kalender with this shortcode is created automatically
weinhold_public_calendar	Public calendar of the current website: logged-out visitors only see public events, logged-in users see all events of this website

Files

modules/calendar.php – the module’s only file: database including versioned migrations, event/color management, reminder cron job, frontend form processing, both shortcodes, admin page, cleanup.

For Developers

Database

Table	Columns	(selection)
weinhold_calendar_events	site_id, creator_user_id, caption, description, event_link, visibility	(0 network/1 private/2 public), event_dt_gmt
weinhold_calendar_event_users	event_id, user_id, wants_reminder, reminder_sent_at_gmt
weinhold_calendar_user_settings	user_id, reminder_days
weinhold_calendar_site_colors	user_id, site_id, color

Versioned migration up to DB version 3: v2 to v3 renames is_private to visibility (boolean becomes three-valued), adds event_link, and adds wants_reminder to the participants table.

Dedicated Capability for Public Events

Via the weinhold_registered_capabilities filter, the module registers the additional capability weinhold_calendar_create_public_event — a separate, finer-grained permission above the normal module edit right, since a public event is visible even without login and is therefore more sensitive than a regular network event.

Email Template & Cron

Registers the calendar_reminder template with the Email Delivery module (placeholders display_name, count, when, events) and uses it via weinhold_send_module_mail() for the daily reminder send. The daily cron job is set up exclusively on the main site (module scope: network) and respects the central cron mode switch (weinhold_cron_mode_is_extern(‚calendar‘)) — with external cron enabled, WP-Cron doesn’t handle the scheduling itself.

Special Cases

Despite the module scope being network, events are tagged with site_id and colors are configurable per user AND per site — „network-wide“ here means a user sees events from ALL sites in one shared personal calendar, not that there’s a single, undifferentiated event pool with no site association.

The migration from is_private (boolean) to visibility (three-valued) shows that „Public“ was added later as a third visibility level — older installations migrated via the database upgrade have the same column, just under a new name and with an expanded value range.

Permission for public events runs through a dedicated capability rather than the generic module edit right — being allowed to edit events doesn’t automatically mean being allowed to create public events that don’t require login.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026