Ablauf

Ruft ein Besucher die Login-Seite auf, erscheint zunächst nur die Gate-Seite mit einem einzelnen Button „Jetzt einloggen“. Ein Klick darauf setzt (optional nach erfolgreicher reCAPTCHA-Prüfung im Hintergrund) einen kurzlebigen Cookie und leitet zurück zur Login-Seite – erst jetzt erscheint das eigentliche Formular für Benutzername und Passwort.

Netzwerkweit, zentral gesteuert

Anders als die meisten Module lässt sich das Login Gate nicht pro Site ein- oder ausschalten – es gibt eine einzige, zentrale Einstellung unter Weinhold Netzwerk → Login Gate, die für alle Sites gleichzeitig gilt. Zusätzlich lässt sich einstellen, wie lange der Gate-Cookie nach dem Klick gültig bleibt (1–60 Minuten).

Zusammenspiel mit reCAPTCHA

Ist das reCAPTCHA-Modul aktiv, wird beim Klick auf den Gate-Button zusätzlich ein unsichtbarer reCAPTCHA-Score geprüft, bevor der Cookie gesetzt wird. Ohne aktives reCAPTCHA-Modul funktioniert das Gate trotzdem – dann zählt allein der Button-Klick.

modules/login_gate_core.php – einzige Datei des Moduls (Core-Modul, das _core.php-Suffix lädt es immer): Cookie-/Token-Verwaltung, POST-Handler für den Gate-Klick, Gate-Seiten-Rendering, Admin-Einstellungen, Cleanup.

Einhängepunkt: weinhold_auth_login_override

Login Gate hängt sich mit Priorität 5 in denselben Filter weinhold_auth_login_override ein, über den auch das Gerätesicherheit-Modul seine Challenge-Seite anzeigt. Ist das Gate aktiv und kein gültiger Cookie vorhanden, liefert es HTML für die Vorraum-Seite statt null zurück – das Benutzerverwaltung-Modul zeigt dieses HTML dann anstelle des normalen Login-Formulars.

Cookie & Transient

Nach dem Button-Klick wird ein zufälliger Token erzeugt, als Transient wf_gate_{token} mit der konfigurierten Lebensdauer gespeichert und zusätzlich als HttpOnly-Cookie wf_login_gate (SameSite=Strict, Secure bei SSL) im Browser abgelegt. weinhold_login_gate_has_valid_cookie() prüft bei jedem Login-Seitenaufruf, ob Cookie-Wert und Transient noch zusammenpassen.

Schutz vor direkten POST-Angriffen

Das Security-Manager-Modul liest denselben Cookie-Namen (wf_login_gate) und denselben Transient-Präfix in seiner eigenen Funktion weinhold_security_block_gateless_post() – ein POST direkt auf die Login-Verarbeitung ohne gültigen Gate-Cookie wird dort blockiert, unabhängig vom Gate-Rendering selbst. Die beiden Module sind also bewusst über den Cookie-Namen gekoppelt, nicht über einen direkten Funktionsaufruf.

Keine Per-Site-Steuerung: Bewusste Design-Entscheidung, weil ein Bot-Schutz nur netzwerkweit konsistent wirksam ist – eine einzelne ungeschützte Subsite würde sonst weiterhin direkte Angriffe erlauben.

reCAPTCHA-Prüfung passiert zweimal im vollen Flow: einmal beim Gate-Klick (dieses Modul) und ein zweites Mal beim eigentlichen Login-Submit (Benutzerverwaltung-Modul, sofern dort ebenfalls aktiviert) – zwei unabhängige Kontrollpunkte statt einem.

Fehlermeldungen (ungültiger Nonce, fehlgeschlagene reCAPTCHA-Prüfung) werden IP-basiert als kurzlebiger Transient zwischengespeichert und beim nächsten Aufruf der Gate-Seite einmalig angezeigt – kein Session- oder Cookie-basierter Mechanismus dafür nötig.

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.

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.

Einstellungen (Option weinhold_security_settings)

Login-Flow (Hooks)

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.

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.

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.

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.

Datenbank

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)

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

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.

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.

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.

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.

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

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}/).

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.

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.

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.

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

Datenstruktur eines Log-Eintrags

So sieht ein gespeicherter Eintrag in der Datenbank aus:

Daten lesen

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

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.

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.

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.

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.

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.