Schlagwort: weinhold-framework

jeopardy-auth

Jeopardy – Login-Brücke

🏠

Das Modul meldet Nutzer mit ihrem WordPress-Konto bei der separaten Jeopardy-App auf jeopardy.weinify.de an. Statt eines eigenen Logins in der App stellt WordPress ein kurzlebiges, signiertes JWT aus, das die App einmal prüft und gegen ein eigenes Session-Cookie tauscht. Login, Registrierung und Logout laufen über die normalen Seiten der Benutzerverwaltung.

Allgemein

Anmelden aus der App heraus

Das Konto-Menü oben rechts in der Jeopardy-App verlinkt auf diese Site mit dem Parameter weinhold_jeopardy_auth (login, register oder logout) und einem Rücksprungpfad. Wer noch nicht eingeloggt ist, landet auf der Login- bzw. Registrierungsseite der Benutzerverwaltung und kommt danach automatisch zurück. Eingeloggte Nutzer werden sofort mit einem frisch signierten Token zur App weitergeleitet und sind dort angemeldet.

Was die Anmeldung in der App erlaubt

Jeder angemeldete Nutzer darf in der App eigene Boards anlegen, sie öffentlich schalten, als Vorlage einreichen und seine eigenen sowie alle öffentlichen Boards hosten. Mitspielen per Handy und die Board-Ansicht am Beamer gehen weiterhin ohne Konto. Administratoren dieser Site (Recht manage_options) bekommen zusätzlich ein Admin-Kennzeichen im Token und dürfen in der App alle Boards und Vorlagen sehen und pflegen.

Abmelden

Logout in der App löscht das Session-Cookie der App und meldet anschließend auch bei WordPress ab (über die Logout-URL mit Nonce), danach geht es zurück zur App.

Dateien

modules/jeopardy_auth.php – einzige Datei des Moduls: Einstieg über den Query-Parameter, Rücksprung-Prüfung, JWT-Signierung, Erweiterung der erlaubten Redirect-Hosts und Admin-Statusseite.

Gegenstück in der App (Repo VPS-Addons, Ordner Jeopardy): backend/src/routes/auth.ts (Token prüfen, Session-Cookie jeopardy_session) und backend/src/shared/access.ts (Rechte für Boards).

Für Entwickler

Kein eigener Datenbank-State

Das Modul hat weder Tabelle noch Optionen noch Capabilities und deshalb auch kein maybe_install() und kein cleanup(). Es signiert bei jedem Aufruf nur ein Token aus vorhandenen Nutzerdaten. Ein eigenes Recht zum Hosten gibt es bewusst nicht: jeder eingeloggte Nutzer darf sich anmelden, die feineren Regeln (Ersteller, öffentlich, Admin) entscheidet die App.

Ablauf und Einstieg

weinhold_jeopardy_auth_handle_request() hängt mit Priorität 1 an template_redirect und reagiert nur, wenn weinhold_jeopardy_auth gesetzt ist. Nicht eingeloggte Nutzer werden zur Auth-Seite der Benutzerverwaltung geschickt (weinhold_user_management_get_auth_page_url), mit redirect_to auf genau diese Einstiegs-URL, damit sie danach eingeloggt hier landen. Der Rücksprungpfad wird von weinhold_jeopardy_auth_sanitize_return() geprüft: nur Pfade mit genau einem führenden Schrägstrich, sonst die Startseite der App.

Parameter	Beschreibung
weinhold_jeopardy_auth	login, register oder logout
return	Pfad in der App, auf den nach der Anmeldung zurückgesprungen wird (Standard /)

Token

weinhold_jeopardy_auth_sign_token() baut ein HS256-JWT von Hand (Base64url und hash_hmac(), keine Composer-Bibliothek). Das Token läuft nach 120 Sekunden ab und wird im URL-Fragment an {App}/auth/callback übergeben, damit es nicht in Server-Logs landet. Die App tauscht es sofort gegen ihr eigenes httpOnly-Session-Cookie (30 Tage).

Claim	Inhalt
sub	WordPress-Nutzer-ID
name	Anzeigename
avatar	URL des Profilbilds
profile_url	Profilseite der Benutzerverwaltung
admin	true, wenn der Nutzer auf dieser Site manage_options hat
iat	Ausstellungszeitpunkt
exp	Ablauf (Ausstellung plus 120 Sekunden)

Konfiguration

Konstante	Beschreibung
JEOPARDY_JWT_SECRET	Pflicht, in wp-config.php. Muss exakt mit JEOPARDY_JWT_SECRET in der .env der App übereinstimmen
JEOPARDY_APP_URL	Optional, Standard https://jeopardy.weinify.de (zusätzlich per Filter weinhold_jeopardy_auth_app_url änderbar)

Besonderheiten

Vorbild ist das Modul PPNP Game – Login-Brücke. Anders als dort gibt es keinen Button-Shortcode und keinen AJAX-Endpunkt: die App verlinkt direkt auf die Einstiegs-URL, und der Rücksprung zur App ist ein normaler Redirect.

Die App liegt nicht im Multisite-Netzwerk. Damit der Rücksprung nach dem Logout über wp_safe_redirect() funktioniert, ergänzt das Modul den Host der App-URL über den Filter allowed_redirect_hosts.

Die Hilfsfunktion weinhold_user_management_add_redirect_to_url() wird absichtlich nicht verwendet: sie dekodiert das Ziel mehrfach und hängt es unkodiert an, wodurch der return-Parameter verloren ginge. Stattdessen wird redirect_to selbst mit rawurlencode() angehängt.

Rechte-Änderungen (z. B. jemand wird Administrator) greifen in der App erst nach einer neuen Anmeldung, weil das Admin-Kennzeichen im Session-Cookie der App gespeichert ist.

Versionshistorie

Version	Datum	Änderung
1.0.0	05.10.2026	Erste Veröffentlichung: Login, Registrierung und Logout für die Jeopardy-App per kurzlebigem JWT.
1.1.0	05.10.2026	Token trägt das Admin-Kennzeichen (manage_options), Grundlage für Board-Besitz, öffentliche Boards und Vorlagen in der App.

Jeopardy – Login Bridge

🏠

The module signs users in to the separate Jeopardy app on jeopardy.weinify.de with their WordPress account. Instead of a login of its own inside the app, WordPress issues a short-lived, signed JWT that the app verifies once and exchanges for its own session cookie. Login, registration and logout run through the regular pages of the user management.

General

Signing In from the App

The account menu in the top right of the Jeopardy app links to this site with the parameter weinhold_jeopardy_auth (login, register or logout) and a return path. Users who are not logged in yet land on the login or registration page of the user management and are sent back automatically afterwards. Logged-in users are redirected to the app right away with a freshly signed token and are signed in there.

What Signing In Allows in the App

Every signed-in user may create their own boards in the app, make them public, submit them as templates, and host their own boards as well as all public ones. Playing along on a phone and the board view on the projector still work without an account. Administrators of this site (capability manage_options) additionally get an admin flag in the token and may see and manage all boards and templates in the app.

Signing Out

Logging out in the app deletes the app’s session cookie and then also logs out of WordPress (via the logout URL with nonce), after which the user returns to the app.

Files

modules/jeopardy_auth.php – the module’s only file: entry via the query parameter, return path check, JWT signing, extension of the allowed redirect hosts, and the admin status page.

Counterpart in the app (repo VPS-Addons, folder Jeopardy): backend/src/routes/auth.ts (token verification, session cookie jeopardy_session) and backend/src/shared/access.ts (board permissions).

For Developers

No Database State of Its Own

The module has no table, no options and no capabilities, and therefore no maybe_install() and no cleanup(). It simply signs a token from existing user data on every call. There is deliberately no separate hosting permission: every logged-in user may sign in, and the finer rules (owner, public, admin) are decided by the app.

Flow and Entry Point

weinhold_jeopardy_auth_handle_request() hooks into template_redirect with priority 1 and only reacts when weinhold_jeopardy_auth is set. Users who are not logged in are sent to the auth page of the user management (weinhold_user_management_get_auth_page_url), with redirect_to pointing back to exactly this entry URL so they end up here again once logged in. The return path is checked by weinhold_jeopardy_auth_sanitize_return(): only paths starting with exactly one slash, otherwise the app’s start page.

Parameter	Description
weinhold_jeopardy_auth	login, register or logout
return	Path in the app to return to after signing in (default /)

Token

weinhold_jeopardy_auth_sign_token() builds an HS256 JWT by hand (base64url and hash_hmac(), no Composer library). The token expires after 120 seconds and is passed to {App}/auth/callback in the URL fragment so it never ends up in server logs. The app immediately exchanges it for its own httpOnly session cookie (30 days).

Claim	Content
sub	WordPress user ID
name	Display name
avatar	URL of the profile picture
profile_url	Profile page of the user management
admin	true if the user has manage_options on this site
iat	Issued-at time
exp	Expiry (issued plus 120 seconds)

Configuration

Constant	Description
JEOPARDY_JWT_SECRET	Required, in wp-config.php. Must match JEOPARDY_JWT_SECRET in the app’s .env exactly
JEOPARDY_APP_URL	Optional, default https://jeopardy.weinify.de (can also be changed via the filter weinhold_jeopardy_auth_app_url)

Special Cases

The template is the PPNP Game – Login Bridge module. Unlike there, there is no button shortcode and no AJAX endpoint: the app links directly to the entry URL, and the return to the app is a plain redirect.

The app is not part of the multisite network. So that the return after logout works via wp_safe_redirect(), the module adds the host of the app URL through the allowed_redirect_hosts filter.

The helper weinhold_user_management_add_redirect_to_url() is deliberately not used: it decodes the target several times and appends it unencoded, which would lose the return parameter. Instead, redirect_to is appended manually with rawurlencode().

Permission changes (e.g. someone becomes an administrator) only take effect in the app after signing in again, because the admin flag is stored in the app’s session cookie.

Version History

Version	Date	Change
1.0.0	05.10.2026	First release: login, registration and logout for the Jeopardy app via a short-lived JWT.
1.1.0	05.10.2026	Token carries the admin flag (manage_options), the basis for board ownership, public boards and templates in the app.

5. Oktober 2026

ppnp-game-auth

PPNP Game – Login-Brücke

Das Modul stellt eingeloggten Nutzern ein kurzlebiges, signiertes JWT aus, mit dem sich der separate Node.js-Spieldienst (ppnp.weinify.de/game) authentifiziert. Es gibt keinen eigenen Login-Nachbau – der Node-Dienst prüft nur die Signatur und vertraut WordPress als Identitätsquelle.

Allgemein

Spielstart per Button

Ein Shortcode zeigt einen „Spiel starten“-Button für eingeloggte, freigeschaltete Nutzer. Ein Klick holt per AJAX ein frisch signiertes Token und leitet direkt zum Node.js-Spieldienst weiter, der das Token aus dem URL-Fragment liest.

Drei getrennte Spiel-Berechtigungen

Neben der reinen Spielfreigabe (view-Recht über die normale Modulberechtigung) gibt es drei eigene, im Nutzerprofil einzeln vergebbare Capabilities: Stammdaten pflegen (Typen, Attacken, Pyxlinge), neue Welten erstellen und den Beta-Bereich verwalten. Editoren und Administratoren erhalten die ersten beiden automatisch über ihre Rolle, die Beta-Berechtigung bewusst nur Administratoren.

Spielerliste für den Node-Dienst

Der Node-Dienst kann per authentifiziertem Callback die vollständige Liste aller fürs Spiel freigeschalteten Nutzer abrufen – Grundlage für die Spieler-Zuweisung pro Welt im Spieldienst selbst.

Shortcodes

Shortcode Beschreibung
weinhold_ppnp_game_launch Button für eingeloggte, freigeschaltete Nutzer, der ein signiertes Spiel-Login-Token holt und zum Node.js-Spiel weiterleitet. Keine Parameter

Dateien

modules/ppnp_game_auth.php – einzige Datei des Moduls: Capability-Verwaltung, JWT-Signierung, AJAX-Endpunkte (Token-Ausstellung, Spielerliste), Shortcode, Admin-Statusseite, Cleanup.

Für Entwickler

Kein eigener Datenbank-State

Anders als fast alle anderen Module gibt es kein maybe_install() und keine eigene Tabelle: Das Modul signiert bei jedem Aufruf nur ein kurzlebiges Token aus bereits vorhandenen WordPress-Nutzerdaten. weinhold_ppnp_game_auth_cleanup() existiert trotzdem, weil die drei Capabilities echter, dauerhafter State sind, der beim Zurücksetzen sauber von allen Rollen UND individuell zugewiesenen Nutzern entfernt werden muss.

Selbst gebautes HS256-JWT ohne Bibliothek

weinhold_ppnp_game_auth_sign_token() baut das JWT von Hand (Base64url-Encoding, HMAC-SHA256-Signatur über hash_hmac()) statt eine Composer-Bibliothek einzubinden – der Node-Dienst validiert nur die Signatur mit demselben Secret (PPNP_GAME_JWT_SECRET aus der wp-config.php), es findet keine eigene Session-Verwaltung im Spieldienst statt. Das Token trägt neben der Nutzer-ID auch die drei Capability-Flags direkt im Payload und läuft nach 120 Sekunden ab – bewusst nur als kurzlebiges Sprungbrett zum Aufbau der WebSocket-Verbindung gedacht, nicht als dauerhaftes Zugangs-Credential.

Server-zu-Server per Shared Secret

Der Callback für die Spielerliste läuft über einen nopriv-Ajax-Hook (der Node-Dienst hat keine WordPress-Session) und wird stattdessen über ein zweites, vom JWT-Secret getrenntes Shared Secret abgesichert (Header X-PPNP-Game-Secret, Konstante PPNP_GAME_API_SECRET, Vergleich per hash_equals() gegen Timing-Angriffe). Die Freigabeprüfung nutzt exakt dieselbe Funktion wie beim Token-Ausstellen, damit „wer darf spielen“ nur eine einzige Quelle der Wahrheit hat.

Besonderheiten

Dieses Modul ist das dokumentierte Vorbild für den MCP-Server-Manager: Beide nutzen signierte Tokens, ein zweites Shared Secret für Server-zu-Server-Calls und Capability-basierte statt tabellenbasierte Zugriffsrechte. Der MCP Server Manager weicht bewusst in zwei Punkten ab (dynamische statt fester Capabilities, langlebige statt kurzlebige Tokens) – wer den Aufbau des einen Moduls versteht, erkennt die Struktur des anderen sofort wieder.

Zwei komplett getrennte Secrets für zwei komplett getrennte Zwecke: PPNP_GAME_JWT_SECRET signiert Nutzer-Tokens, PPNP_GAME_API_SECRET schützt den Server-zu-Server-Callback – ein kompromittiertes Secret legt nie beide Kanäle gleichzeitig offen.

Die Beta-Berechtigung wird absichtlich NICHT wie die anderen beiden Capabilities automatisch an Editoren vergeben, obwohl der Code dafür identisch aufgebaut ist – reine Vorsichtsmaßnahme, damit ein unfertiger Beta-Bereich nicht versehentlich für alle Spielleiter sichtbar wird.

Versionshistorie

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

PPNP Game – Login Bridge

The module issues logged-in users a short-lived, signed JWT used to authenticate against the separate Node.js game service (ppnp.weinify.de/game). There is no reimplementation of login — the Node service only verifies the signature and trusts WordPress as the identity source.

General

Launching the Game via a Button

A shortcode shows a „Start game“ button for logged-in, authorized users. Clicking it fetches a freshly signed token via AJAX and redirects straight to the Node.js game service, which reads the token from the URL fragment.

Three Separate Game Permissions

Besides plain game access (the view right via the normal module permission), there are three dedicated capabilities, individually assignable in the user profile: managing master data (types, moves, Pyxlinge), creating new worlds, and managing the beta area. Editors and administrators get the first two automatically through their role; the beta permission is deliberately given only to administrators.

Player List for the Node Service

The Node service can fetch the full list of users authorized to play via an authenticated callback — the basis for assigning players to worlds within the game service itself.

Shortcodes

Shortcode Description
weinhold_ppnp_game_launch Button for logged-in, authorized users that fetches a signed game login token and redirects to the Node.js game. No parameters

Files

modules/ppnp_game_auth.php – the module’s only file: capability management, JWT signing, AJAX endpoints (token issuance, player list), shortcode, admin status page, cleanup.

For Developers

No Database State of Its Own

Unlike almost every other module, there is no maybe_install() and no dedicated table: the module simply signs a short-lived token from existing WordPress user data on every call. weinhold_ppnp_game_auth_cleanup() still exists because the three capabilities are real, persistent state that must be cleanly removed from all roles AND individually assigned users on reset.

A Hand-Rolled HS256 JWT, No Library

weinhold_ppnp_game_auth_sign_token() builds the JWT by hand (base64url encoding, HMAC-SHA256 signature via hash_hmac()) instead of pulling in a Composer library — the Node service only validates the signature with the same secret (PPNP_GAME_JWT_SECRET from wp-config.php); there is no separate session management in the game service. The token carries the three capability flags directly in the payload alongside the user ID and expires after 120 seconds — deliberately just a short-lived stepping stone for bootstrapping the WebSocket connection, not a lasting access credential.

Server-to-Server via Shared Secret

The player-list callback runs through a nopriv Ajax hook (the Node service has no WordPress session) and is instead secured with a second shared secret, separate from the JWT secret (header X-PPNP-Game-Secret, constant PPNP_GAME_API_SECRET, compared with hash_equals() against timing attacks). The authorization check uses the exact same function as token issuance, so „who may play“ has only a single source of truth.

Special Cases

This module is the documented template for the MCP Server Manager: both use signed tokens, a second shared secret for server-to-server calls, and capability-based rather than table-based access rights. The MCP Server Manager deliberately diverges in two ways (dynamic instead of fixed capabilities, long-lived instead of short-lived tokens) — understanding this module’s structure makes the other module’s structure immediately recognizable.

Two completely separate secrets for two completely separate purposes: PPNP_GAME_JWT_SECRET signs user tokens, PPNP_GAME_API_SECRET protects the server-to-server callback — a compromised secret never exposes both channels at once.

The beta permission is deliberately NOT granted automatically to editors like the other two capabilities, even though the code for it is structured identically — a pure precaution so an unfinished beta area doesn’t accidentally become visible to every game master.

Version History

Version Date Change
1.0.0 22.09.2026 Introduction of versioning.

22. September 2026
login-gate

Login Gate

Das Login-Gate-Modul schützt die Login-Seite mit einer vorgeschalteten „Vorraum“-Seite: Statt direkt das Login-Formular zu sehen, müssen Besucher erst einen Button klicken. Das blockiert einen Großteil automatisierter Bot-Angriffe, bevor überhaupt ein Login-Versuch stattfindet.

Allgemein

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.

Dateien

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.

Für Entwickler

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.

Besonderheiten

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.

Versionshistorie

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

Login Gate

The Login Gate module protects the login page with a „waiting room“ page in front of it: instead of seeing the login form right away, visitors first have to click a button. This blocks most automated bot attacks before a login attempt even happens.

General

Flow

When a visitor opens the login page, only the gate page with a single „Log in now“ button appears at first. Clicking it (optionally after a background reCAPTCHA check succeeds) sets a short-lived cookie and redirects back to the login page — only now does the actual username/password form appear.

Network-Wide, Centrally Controlled

Unlike most modules, Login Gate can’t be switched on or off per site — there’s a single, central setting under Weinhold Network → Login Gate that applies to all sites at once. It also lets you configure how long the gate cookie stays valid after the click (1–60 minutes).

Working Together with reCAPTCHA

If the reCAPTCHA module is active, clicking the gate button additionally checks an invisible reCAPTCHA score before the cookie is set. Without an active reCAPTCHA module, the gate still works — then the button click alone counts.

Files

modules/login_gate_core.php – the module’s only file (core module, the _core.php suffix always loads it): cookie/token management, POST handler for the gate click, gate page rendering, admin settings, cleanup.

For Developers

Hook Point: weinhold_auth_login_override

Login Gate hooks into the same weinhold_auth_login_override filter, at priority 5, that the Device Security module also uses for its challenge page. If the gate is active and no valid cookie exists, it returns HTML for the waiting-room page instead of null — the User Management module then shows this HTML instead of the normal login form.

Cookie & Transient

After the button click, a random token is generated, stored as a transient wf_gate_{token} with the configured lifetime, and additionally set as an HttpOnly cookie wf_login_gate (SameSite=Strict, Secure over SSL) in the browser. weinhold_login_gate_has_valid_cookie() checks on every login page load whether the cookie value and transient still match.

Protection Against Direct POST Attacks

The Security Manager module reads the same cookie name (wf_login_gate) and the same transient prefix in its own function weinhold_security_block_gateless_post() — a POST directly to the login processing without a valid gate cookie is blocked there, independently of the gate rendering itself. The two modules are therefore deliberately coupled via the cookie name, not via a direct function call.

Special Cases

No per-site control: a deliberate design choice, because bot protection is only consistently effective network-wide — a single unprotected subsite would otherwise still allow direct attacks.

reCAPTCHA is checked twice in the full flow: once at the gate click (this module) and a second time at the actual login submit (User Management module, if also enabled there) — two independent checkpoints instead of one.

Error messages (invalid nonce, failed reCAPTCHA check) are cached IP-based as a short-lived transient and shown once the next time the gate page loads — no session or cookie-based mechanism needed for that.

Version History

Version Date Change
1.0.0 22.09.2026 Introduction of versioning.

22. September 2026
recaptcha

reCAPTCHA

Das reCAPTCHA-Modul prüft Login, Registrierung, Passwort-vergessen und Kommentare mit Googles reCAPTCHA Enterprise auf Bot-Verhalten und blockiert oder protokolliert verdächtige Anfragen anhand eines Score-Schwellwerts.

Allgemein

Score statt Bilderrätsel

Statt sichtbarer Bilderrätsel nutzt das Modul Googles reCAPTCHA Enterprise im Hintergrund: Jede geschützte Formular-Aktion liefert einen Score zwischen 0 und 1, der mit einem einstellbaren Schwellwert verglichen wird (Standard 0,5). Besucher merken im Normalfall nichts davon.

Vier schützbare Formulare

Einzeln zuschaltbar: Login, Registrierung, Passwort vergessen und Kommentare. Bei einer Unterschreitung des Schwellwerts entscheidet die Einstellung „Aktion bei Fehlschlag“ darüber, ob die Anfrage blockiert (block) oder nur protokolliert wird (log_only), ohne den Nutzer zu stören.

Statistik-Dashboard

Jede Prüfung wird protokolliert und im Dashboard mit Kennzahlen (Gesamt/Durchgelassen/Blockiert/Block-Rate/Ø Score), Zeitverlauf, Score-Verteilung und Aufschlüsselung nach Formular-Typ ausgewertet – filterbar nach Zeitraum, Website und IP-Adresse, inklusive CSV-Export. Alte Log-Einträge werden nach einer konfigurierbaren Aufbewahrungsfrist (Standard 90 Tage) automatisch per täglichem Cronjob gelöscht.

Dateien

modules/recaptcha.php – einzige Datei des Moduls: Einstellungen, Verschlüsselung, Frontend-Integration, Formular-Prüfungen, Logging-Tabelle, Statistik-Dashboard, CSV-Export, Cleanup.

Für Entwickler

Verschlüsselter API-Key

Site Key, API-Key und Projekt-ID für die Google-Cloud-Anbindung werden zentral eingetragen; der API-Key wird wie beim E-Mail-Versand-Modul mit AES-256-CBC verschlüsselt gespeichert (Schlüssel aus dem WordPress-AUTH_KEY abgeleitet). Ein Test-Button in den Einstellungen prüft die Zugangsdaten direkt gegen Google, ohne einen echten Seitenaufruf zu benötigen.

Fail-Open bei Google-Ausfall

weinhold_recaptcha_verify() ruft die reCAPTCHA-Enterprise-API auf und liefert Score sowie Ergebnis zurück. Ist Google nicht erreichbar, gilt die Prüfung als bestanden (fail-open) statt alle Nutzer auszusperren – bewusste Entscheidung gegen einen kompletten Login-Ausfall bei einem Google-seitigen Problem. Debug-Informationen zum letzten Aufruf werden eine Stunde als Transient für die Fehlersuche vorgehalten.

Login-Prüfung ohne Security-Manager-Zählung

Die Login-Prüfung hängt bewusst am Hook login_init statt am späteren wp_authenticate_user – dadurch feuert bei einem fehlgeschlagenen reCAPTCHA-Score niemals der Hook wp_login_failed, und das Security-Manager-Modul zählt reCAPTCHA-Fehlschläge folglich nicht als fehlgeschlagenen Login-Versuch für seine eigene Sperrlogik.

Automatische Formular-Erkennung

Das eingebundene JavaScript erkennt Login- (Felder log/pwd), Registrierungs- und Passwort-vergessen-Formulare automatisch anhand ihrer Standard-Feldnamen und erzeugt beim Laden proaktiv ein Token. Eigene Formulare lassen sich zusätzlich über das Attribut data-wf-recaptcha einbinden.

Besonderheiten

Obwohl der Modul-Header Scope: site trägt (also pro Website aktivierbar ist), gibt es keine site-spezifischen Einstellungen mehr – Site Key, API-Key, Schwellwert und alle Schutz-Schalter sind ausschließlich netzwerkweit konfigurierbar. weinhold_recaptcha_cleanup() hat entsprechend nichts mehr zu bereinigen, nur der Netzwerk-Cleanup entfernt die globale Konfiguration und die Log-Tabelle.

Fail-Open bedeutet: Ist die Google-API nicht erreichbar, lässt das Modul Anfragen lieber durch als Nutzer komplett auszusperren – Verfügbarkeit hat hier bewusst Vorrang vor lückenloser Bot-Abwehr.

Versionshistorie

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

reCAPTCHA

The reCAPTCHA module checks login, registration, lost-password, and comment forms against bot behavior using Google reCAPTCHA Enterprise, and blocks or logs suspicious requests based on a score threshold.

General

A Score Instead of Image Puzzles

Instead of visible image puzzles, the module uses Google reCAPTCHA Enterprise in the background: every protected form action returns a score between 0 and 1, compared against a configurable threshold (default 0.5). Visitors normally notice nothing.

Four Protectable Forms

Individually toggleable: login, registration, lost password, and comments. When the score falls below the threshold, the „action on failure“ setting decides whether the request is blocked (block) or only logged (log_only) without bothering the user.

Statistics Dashboard

Every check is logged and evaluated in the dashboard with KPIs (total/passed/blocked/block rate/average score), a timeline, score distribution, and a breakdown by form type — filterable by period, site, and IP address, including CSV export. Old log entries are automatically deleted by a daily cron job after a configurable retention period (default 90 days).

Files

modules/recaptcha.php – the module’s only file: settings, encryption, frontend integration, form checks, logging table, statistics dashboard, CSV export, cleanup.

For Developers

Encrypted API Key

Site key, API key, and project ID for the Google Cloud connection are entered centrally; like the Email Delivery module, the API key is stored encrypted with AES-256-CBC (key derived from the WordPress AUTH_KEY). A test button in the settings checks the credentials directly against Google without needing a real page load.

Fail-Open on Google Outage

weinhold_recaptcha_verify() calls the reCAPTCHA Enterprise API and returns the score and result. If Google is unreachable, the check is treated as passed (fail-open) instead of locking out all users — a deliberate choice against a complete login outage caused by a problem on Google’s side. Debug information about the last call is kept as a transient for one hour for troubleshooting.

Login Check Without Security Manager Counting It

The login check deliberately hooks into login_init instead of the later wp_authenticate_user — as a result, a failed reCAPTCHA score never fires the wp_login_failed hook, so the Security Manager module does not count reCAPTCHA failures as failed login attempts for its own lockout logic.

Automatic Form Detection

The included JavaScript automatically detects login (log/pwd fields), registration, and lost-password forms by their standard field names and proactively generates a token on page load. Custom forms can additionally be included via the data-wf-recaptcha attribute.

Special Cases

Although the module header carries Scope: site (meaning it can be activated per website), there are no site-specific settings anymore — site key, API key, threshold, and all protection toggles are configurable exclusively network-wide. weinhold_recaptcha_cleanup() accordingly has nothing left to clean up; only the network cleanup removes the global configuration and the log table.

Fail-open means: if the Google API is unreachable, the module lets requests through rather than locking users out entirely — availability deliberately takes priority over airtight bot defense here.

Version History

Version Date Change
1.0.0 22.09.2026 Introduction of versioning.

22. September 2026

Shortcode	Beschreibung
weinhold_ppnp_game_launch	Button für eingeloggte, freigeschaltete Nutzer, der ein signiertes Spiel-Login-Token holt und zum Node.js-Spiel weiterleitet. Keine Parameter

Shortcode	Description
weinhold_ppnp_game_launch	Button for logged-in, authorized users that fetches a signed game login token and redirects to the Node.js game. No parameters

rudelroots

RudelRoots

Das RudelRoots-Modul verwaltet Zutaten für die Barf-Fütterung (biologisch artgerechte Rohfleisch-Fütterung von Hunden) in Sets und berechnet daraus benötigte Mengen und Kosten – wahlweise nach Anzahl Tagen oder nach bereits vorhandener Menge einer Zutat.

Allgemein

Zutaten & Sets

Jede Zutat erhält Name, Beschreibung, Bild, optionalen Einkaufslink, einen Grammwert pro 5 kg Hundegewicht und Tag sowie einen Preis pro 100 g. Zutaten werden zu Sets gruppiert (z. B. für unterschiedliche Fütterungspläne); ein Set kann als Standard markiert werden und wird dann beim Aufruf des Rechners automatisch vorausgewählt.

Bedarfsrechner mit zwei Modi

Im Modus „Planung nach Tagen“ gibt man die gewünschte Anzahl Tage ein, das Modul berechnet für jede Zutat des gewählten Sets die benötigte Menge und die Kosten. Im Modus „Planung nach vorhandener Menge“ wählt man stattdessen eine bereits vorhandene Zutat mit ihrer Menge in Gramm aus – das Modul errechnet daraus, für wie viele ganze Tage der Vorrat reicht, und wie viel von den übrigen Zutaten des Sets für denselben Zeitraum benötigt wird.

Übersichtsliste

Eine separate Ansicht zeigt alle hinterlegten Zutaten als Kartenraster mit Bild, Beschreibung, Preis pro 100 g und optionalem Kauflink.

Shortcodes

Shortcode	Beschreibung
weinhold_rudelroots_list	Kartenraster aller Zutaten mit Bild, Beschreibung und Preis. Keine Parameter
weinhold_rudelroots_calculator	Bedarfsrechner mit Set-Auswahl und den zwei Berechnungsmodi. Keine Parameter
rudelroots_list	/ rudelroots_calculator Legacy-Aliase ohne weinhold_-Präfix, bereits in bestehenden Beiträgen verwendet und aus Kompatibilitätsgründen weiterhin aktiv

Dateien

Datei	Inhalt
modules/rudelroots.php	Modul-Header, Initialisierung, Shortcode-Registrierung inkl. Legacy-Aliase, Audit-Log-Integration
modules/rudelroots/db.php	Tabellen, Installation/Cleanup, CRUD für Zutaten und Sets
modules/rudelroots/admin.php	Admin-Oberfläche, Formularverarbeitung, Bild-Upload
modules/rudelroots/frontend.php	Beide Shortcode-Renderer inkl. Rechenlogik für die zwei Kalkulationsmodi

Für Entwickler

Datenbank

Tabelle	Spalten	(Auswahl)
weinhold_rudelroots_ingredients	name, description, link_url, image_url, gramm_per_5kg_per_day, price_per_100g, sort_order
weinhold_rudelroots_sets	name, description, image_url, is_default, sort_order
weinhold_rudelroots_set_ingredients	set_id, ingredient_id	(eindeutige Kombination)

Rechenlogik

weinhold_rudelroots_calculate_mode_a() skaliert gramm_per_5kg_per_day jeder Zutat linear mit der eingegebenen Tagesanzahl. weinhold_rudelroots_calculate_mode_b() rechnet umgekehrt: aus der vorhandenen Menge einer gewählten Zutat und ihrem Tagesbedarf ergibt sich die exakte sowie die abgerundete Anzahl reichender Tage, die dann auf alle übrigen Zutaten des Sets angewendet wird.

Bild-Upload & Audit-Log

Bilder für Zutaten und Sets laufen über wp_handle_upload() mit eigens gesetztem Upload-Verzeichnis- und Mime-Type-Filter statt über die volle Mediathek. Speichern und Löschen von Zutaten und Sets wird – sofern das Audit-Log-Modul aktiv ist – über weinhold_audit_log_log_event() protokolliert (Events ingredient_saved, ingredient_deleted, set_saved, set_deleted).

Besonderheiten

Die Legacy-Shortcode-Aliase (rudelroots_list, rudelroots_calculator ohne weinhold_-Präfix) wurden bewusst nicht entfernt, obwohl das Framework inzwischen konsequent das weinhold_-Präfix nutzt – bereits veröffentlichte Beiträge verwenden noch die alten Namen und sollen weiter funktionieren.

Beim Löschen einer Zutat oder eines Sets werden zuerst die Verknüpfungen in weinhold_rudelroots_set_ingredients entfernt und erst danach der Haupteintrag – ohne Fremdschlüssel-Constraint auf Datenbankebene übernimmt das Modul diese Reihenfolge selbst.

Wird beim Speichern eines Sets is_default gesetzt, entfernt das Modul das Flag zuerst bei allen anderen Sets – es kann also immer nur genau ein Standard-Set geben.

Versionshistorie

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

RudelRoots

The RudelRoots module manages ingredients for BARF feeding (biologically appropriate raw food for dogs) in sets and calculates the amounts and costs needed from them — either by number of days or by an amount of an ingredient already on hand.

General

Ingredients & Sets

Each ingredient gets a name, description, image, optional purchase link, a gram value per 5 kg of dog weight per day, and a price per 100 g. Ingredients are grouped into sets (e.g. for different feeding plans); a set can be marked as default and is then automatically preselected when opening the calculator.

Two-Mode Calculator

In „Plan by days“ mode, you enter the desired number of days and the module calculates the amount and cost needed for each ingredient in the selected set. In „Plan by amount on hand“ mode, you instead pick an ingredient you already have along with its amount in grams — the module works out how many whole days the supply lasts, and how much of the set’s other ingredients are needed for the same period.

Overview List

A separate view shows all stored ingredients as a card grid with image, description, price per 100 g, and an optional purchase link.

Shortcodes

Shortcode	Description
weinhold_rudelroots_list	Card grid of all ingredients with image, description, and price. No parameters
weinhold_rudelroots_calculator	Requirement calculator with set selection and the two calculation modes. No parameters
rudelroots_list	/ rudelroots_calculator Legacy aliases without the weinhold_ prefix, already used in existing posts and kept active for compatibility

Files

File	Contents
modules/rudelroots.php	Module header, initialization, shortcode registration including legacy aliases, audit log integration
modules/rudelroots/db.php	Tables, install/cleanup, CRUD for ingredients and sets
modules/rudelroots/admin.php	Admin UI, form processing, image upload
modules/rudelroots/frontend.php	Both shortcode renderers including the calculation logic for the two modes

For Developers

Database

Table	Columns	(selection)
weinhold_rudelroots_ingredients	name, description, link_url, image_url, gramm_per_5kg_per_day, price_per_100g, sort_order
weinhold_rudelroots_sets	name, description, image_url, is_default, sort_order
weinhold_rudelroots_set_ingredients	set_id, ingredient_id	(unique combination)

Calculation Logic

weinhold_rudelroots_calculate_mode_a() linearly scales each ingredient’s gramm_per_5kg_per_day by the entered number of days. weinhold_rudelroots_calculate_mode_b() works the other way: from the amount on hand of a chosen ingredient and its daily requirement, it derives the exact and the rounded-down number of days the supply lasts, then applies that to all other ingredients in the set.

Image Upload & Audit Log

Images for ingredients and sets go through wp_handle_upload() with a dedicated upload-directory and mime-type filter instead of the full media library. Saving and deleting ingredients and sets is logged via weinhold_audit_log_log_event() when the Audit Log module is active (events ingredient_saved, ingredient_deleted, set_saved, set_deleted).

Special Cases

The legacy shortcode aliases (rudelroots_list, rudelroots_calculator without the weinhold_ prefix) were deliberately kept even though the framework now consistently uses the weinhold_ prefix — already-published posts still use the old names and are meant to keep working.

When deleting an ingredient or a set, the links in weinhold_rudelroots_set_ingredients are removed first, then the main entry — without a database-level foreign key constraint, the module enforces this order itself.

When is_default is set while saving a set, the module first clears the flag on all other sets — so there can only ever be exactly one default set.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

22. September 2026

mcp-server-manager

MCP Server Manager

Das MCP-Server-Manager-Modul verwaltet Nutzerzugriffe auf die selbstgehosteten MCP-Server unter mcp-server.weinify.de: Es nimmt den Server-Katalog vom Gateway entgegen, gibt eingeloggten Nutzern API-Tokens für KI-Clients wie Claude aus und prüft diese Tokens für den Gateway – inklusive vollem OAuth-2.1-Connector-Support.

Allgemein

Katalog & Freischaltung

Der Gateway meldet regelmäßig seinen aktuellen Server-Katalog (ID, Name, Beschreibung, optionaler Web-Pfad) an dieses Modul, das ihn lokal spiegelt. Für jeden Server im Katalog entsteht zur Laufzeit eine eigene Berechtigung; Administratoren schalten Nutzer im WordPress-Profil oder über eine Freigabe-Tabelle auf der Modul-Admin-Seite pro Server frei.

API-Tokens für KI-Clients

Freigeschaltete Nutzer erzeugen über ein Dashboard eigene, langlebige API-Tokens (gültig 5 Jahre) mit eigener Bezeichnung und optional eingeschränktem Server-Scope, um sie in die Konfiguration von KI-Clients wie Claude Desktop einzutragen. Jeder Token lässt sich jederzeit einzeln widerrufen.

OAuth-2.1-Connector-Support

Für Anbindungen, die einen klassischen OAuth-Login-Flow statt eines manuell eingetragenen Tokens erwarten (Connector), spielt WordPress selbst den Authorization Server: Dynamic Client Registration, Login samt Einwilligungsseite und Token-Ausstellung laufen alle über dieses Modul und münden am Ende im selben Token-Format wie die manuell erzeugten Tokens.

Eingebettete Web-Oberflächen

Für Server mit eigener Web-Oberfläche lässt sich diese direkt in eine weinify.de-Seite einbetten – das Modul prägt dafür automatisch einen kurzlebigen, auf genau diesen Server begrenzten Token, ohne dass Nutzer manuell etwas eintragen müssen.

Shortcodes

Shortcode	Beschreibung
weinhold_mcp_server_manager_dashboard	Dashboard für eingeloggte Nutzer: eigene MCP-Server-Zugriffe einsehen, API-Tokens erzeugen und widerrufen. Keine Parameter
weinhold_mcp_server_manager_embed	Bettet die Web-Oberfläche eines MCP-Servers per iframe ein, mit drei Zuständen (bitte einloggen / kein Zugriff / normale Anzeige). Parameter server: Server-ID aus dem Katalog, z. B. „memory“ (muss einen Web-Pfad hinterlegt haben)

Dateien

modules/mcp_server_manager.php – einzige Datei des Moduls: Katalog-Spiegel, Capability-Verwaltung, JWT-Signierung/-Prüfung, Token-Speicher, OAuth-2.1/DCR-Endpunkte, Shortcodes, Admin-Oberflächen, Cleanup.

Für Entwickler

Dynamische Capabilities statt eigener ACL-Tabelle

Statt einer eigenen Datenbanktabelle für Zugriffsrechte nutzt das Modul WordPress-Capabilities: Pro Server im Katalog entsteht zur Laufzeit eine Capability mcp_access_{id}. weinhold_mcp_server_manager_get_user_server_ids() ist die einzige Quelle der Wahrheit dafür, welcher Nutzer welchen Server sehen darf – sowohl fürs eigene Dashboard als auch für die Token-Prüfung des Gateways. Eine separate Verwaltungs-Capability (manage_mcp_server_users) regelt, wer die Server-Zuordnung anderer Nutzer bearbeiten darf; nur Administratoren erhalten sie automatisch.

Selbst signierte JWTs, Widerruf per jti

Tokens sind HS256-signierte JWTs (Secret aus der Konstante MCP_JWT_SECRET in der wp-config.php), enthalten aber zusätzlich eine eindeutige jti. Diese wird beim Erzeugen als Metadatensatz im User-Meta abgelegt; weinhold_mcp_server_manager_verify_token() prüft Signatur, Ablaufzeit UND ob die jti noch in dieser Liste steht – ein Token ist also trotz gültiger Signatur sofort ungültig, sobald er im Dashboard widerrufen wurde. Die effektiven Server-IDs eines Tokens sind die Schnittmenge aus dem beim Erzeugen gewählten Scope und den AKTUELLEN Nutzer-Berechtigungen: Ein Token kann also nie mehr, als der Nutzer JETZT darf, selbst wenn der Scope bei der Erzeugung weiter war.

Server-zu-Server ohne Login

Katalog-Sync und Token-Prüfung kommen vom Gateway selbst, ohne WordPress-Session. Beide Endpunkte laufen über nopriv-Ajax-Hooks und werden stattdessen über ein Shared Secret (Header X-MCP-Gateway-Secret, Konstante MCP_WP_API_SECRET) mit hash_equals() abgesichert – ein eigenes Secret, getrennt vom JWT-Signing-Secret.

OAuth-2.1-Endpunkte

.well-known/oauth-authorization-server wird über den parse_request-Hook bedient, weil RFC 8414 einen festen Pfad ohne admin-ajax.php-Präfix verlangt. Dynamic Client Registration (RFC 7591) nimmt praktisch jede Registrierung mit gültigen Redirect-URIs (https oder localhost) an und vergibt nur eine Client-ID ohne Secret – Public-Client-Modell, abgesichert über PKCE statt Client-Secret-Verwaltung. Registrierung, Authorize-Endpunkt und Token-Endpunkt antworten bewusst NICHT im WordPress-Ajax-Hüllformat ({„success“:true,“data“:…}), sondern mit unverpackten JSON-Antworten nach OAuth-Spezifikation, da ein echter OAuth-Client die WP-Hülle nicht verstehen würde. Connector-Tokens laufen mit 180 Tagen Gültigkeit deutlich kürzer als die 5 Jahre manuell erzeugter Tokens.

Besonderheiten

Der Modul-Header trägt Scope: site, das Modul selbst orientiert sich aber am Muster des PPNP-Spiel-Auth-Moduls (signierte Tokens, Shared-Secret für Server-zu-Server-Calls, Capability-basierte statt tabellenbasierte Rechte) – mit zwei bewussten Abweichungen: Die Server-Liste ist dynamisch statt drei fest einprogrammierter Capabilities, und Tokens sind langlebig und darum per jti widerrufbar statt rein zustandslos wie PPNPs 120-Sekunden-Bootstrap-Token.

Der eingebettete Web-Oberflächen-Token liest der jeweilige MCP-Server direkt aus dem URL-Fragment nach dem Raute-Zeichen aus – Fragmente werden nie an den Server mitgesendet, sondern bleiben rein clientseitig im Browser, was den Token vor Server-Logs schützt.

Trotz voller OAuth-2.1-Unterstützung gibt es keinen Refresh-Grant: Connector-Tokens laufen nach 180 Tagen schlicht ab und müssen neu autorisiert werden, sind aber jederzeit vorher über das Dashboard „Deine Tokens“ widerrufbar.

Versionshistorie

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

MCP Server Manager

The MCP Server Manager module manages user access to the self-hosted MCP servers at mcp-server.weinify.de: it receives the server catalog from the gateway, issues API tokens for AI clients like Claude to logged-in users, and verifies those tokens for the gateway — including full OAuth 2.1 connector support.

General

Catalog & Access Grants

The gateway regularly reports its current server catalog (ID, name, description, optional web path) to this module, which mirrors it locally. Each server in the catalog gets its own capability at runtime; administrators grant users access per server, either in the WordPress profile or via an access table on the module’s admin page.

API Tokens for AI Clients

Authorized users create their own long-lived API tokens (valid for 5 years) via a dashboard, with a custom label and an optionally restricted server scope, to enter into AI client configurations such as Claude Desktop. Every token can be revoked individually at any time.

OAuth 2.1 Connector Support

For integrations expecting a classic OAuth login flow instead of a manually entered token (connectors), WordPress itself acts as the authorization server: dynamic client registration, login with a consent screen, and token issuance all run through this module and end up in the same token format as the manually created tokens.

Embedded Web Interfaces

For servers with their own web interface, that interface can be embedded directly into a weinify.de page — the module automatically mints a short-lived token scoped to exactly that server, so no user ever has to enter anything manually.

Shortcodes

Shortcode	Description
weinhold_mcp_server_manager_dashboard	Dashboard for logged-in users: view your own MCP server access, create and revoke API tokens. No parameters
weinhold_mcp_server_manager_embed	Embeds an MCP server’s web interface via an iframe, with three states (please log in / no access / normal display). Parameter server: server ID from the catalog, e.g. „memory“ (must have a web path configured)

Files

modules/mcp_server_manager.php – the module’s only file: catalog mirror, capability management, JWT signing/verification, token storage, OAuth 2.1/DCR endpoints, shortcodes, admin UIs, cleanup.

For Developers

Dynamic Capabilities Instead of a Dedicated ACL Table

Instead of a dedicated database table for access rights, the module uses WordPress capabilities: each server in the catalog gets a runtime capability mcp_access_{id}. weinhold_mcp_server_manager_get_user_server_ids() is the single source of truth for which user may see which server — both for the user’s own dashboard and for the gateway’s token verification. A separate management capability (manage_mcp_server_users) governs who may edit other users‘ server access; only administrators get it automatically.

Self-Signed JWTs, Revocation via jti

Tokens are HS256-signed JWTs (secret from the MCP_JWT_SECRET constant in wp-config.php), but also carry a unique jti. That jti is stored as a metadata record in user meta when the token is created; weinhold_mcp_server_manager_verify_token() checks the signature, expiry, AND whether the jti is still present in that list — so a token becomes invalid immediately once revoked from the dashboard, despite a still-valid signature. A token’s effective server IDs are the intersection of the scope chosen at creation time and the user’s CURRENT permissions: a token can never grant more than the user is allowed right now, even if its original scope was broader.

Server-to-Server Without Login

Catalog sync and token verification come from the gateway itself, without a WordPress session. Both endpoints run through nopriv Ajax hooks and are instead secured with a shared secret (header X-MCP-Gateway-Secret, constant MCP_WP_API_SECRET) checked via hash_equals() — a secret of its own, separate from the JWT signing secret.

OAuth 2.1 Endpoints

.well-known/oauth-authorization-server is served via the parse_request hook because RFC 8414 requires a fixed path without the admin-ajax.php prefix. Dynamic Client Registration (RFC 7591) accepts essentially any registration with valid redirect URIs (https or localhost) and issues only a client ID with no secret — a public-client model secured by PKCE instead of client-secret management. Registration, the authorize endpoint, and the token endpoint deliberately do NOT respond in the WordPress Ajax wrapper format ({„success“:true,“data“:…}) but with unwrapped JSON per the OAuth spec, since a real OAuth client wouldn’t understand the WP wrapper. Connector tokens are valid for 180 days, notably shorter than the 5 years of manually created tokens.

Special Cases

The module header carries Scope: site, but the module itself follows the pattern of the PPNP Game Auth module (signed tokens, shared secret for server-to-server calls, capability-based rather than table-based rights) — with two deliberate differences: the server list is dynamic instead of three hardcoded capabilities, and tokens are long-lived and therefore revocable via jti instead of purely stateless like PPNP’s 120-second bootstrap token.

The embedded web interface reads its token directly from the URL fragment after the hash character — fragments are never sent to the server and stay purely client-side in the browser, which keeps the token out of server logs.

Despite full OAuth 2.1 support, there is no refresh grant: connector tokens simply expire after 180 days and must be reauthorized, but can be revoked at any time beforehand via the „Your Tokens“ dashboard.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

22. September 2026

bastard-des-monats

Bastard des Monats

Das BdM-Modul verwaltet und präsentiert Schandtaten im Cyberpunk-Terminal-Stil. Mitglieder reichen Einträge über ein Formular ein, ein Admin schaltet sie frei – der zuletzt freigeschaltete Eintrag gilt als amtierender „Bastard des Monats“.

Allgemein

In der Praxis – bastard-des-monats.weinify.de

Das Modul ist in der Praxis vollständig umgesetzt auf bastard-des-monats.weinify.de. Dort lässt sich live sehen, wie das Terminal-UI aussieht und wie Einträge präsentiert werden.

Einreichen & Freischalten

Über das Einsende-Formular reicht jeder Besucher (Name, E-Mail, „Luder“, Tatzeit, Schandtat als Text) einen Vorschlag ein. Neue Einreichungen erhalten den Status eingereicht und erscheinen auf der Wand als anonymisierter, verschlüsselt wirkender Platzhalter-Eintrag – erst nach Freischaltung im Admin-Bereich (Status freigegeben) werden Name des Zeugen, Titel und Schandtat-Text öffentlich sichtbar.

Der amtierende Champion

Der zuletzt freigeschaltete Eintrag wird prominent als „Amtierender Champion der Inkompetenz“ hervorgehoben. Es gibt keine automatische Monats-Rotation oder Abstimmung – welcher Eintrag Champion ist, ergibt sich rein daraus, welcher zuletzt vom Admin freigegeben wurde.

Administration

Eingereichte Schandtaten können im Dashboard freigegeben, bearbeitet oder gelöscht werden. Beim Löschen kann eine individuelle Begründung angegeben werden, die dem Einsender automatisch per E-Mail zugeschickt wird. Zusätzlich benachrichtigt das Modul konfigurierbare Admin-E-Mail-Adressen automatisch über jede neue Einreichung.

Shortcodes

Shortcode	Beschreibung
weinhold_bdm_submit_form	Das Einsende-Formular im Terminal-Design
weinhold_bdm_list	Die „Wand der Schande“: zeigt alle eingereichten und freigeschalteten Einträge
bdm_submit_form	Legacy-Alias für weinhold_bdm_submit_form
bdm_list	Legacy-Alias für weinhold_bdm_list

Dateien

modules/bdm_einsender.php – einzige Datei des Moduls: Datenbank, Formular-Verarbeitung, Admin-Moderation, E-Mail-Benachrichtigungen, beide Frontend-Shortcodes.

Für Entwickler

Datenbank (Tabelle wp_bdm_submissions, Praefix aus wpdb prefix)

Spalte	Bedeutung
submitted_at,event_time	Einreichungszeitpunkt bzw. Zeitpunkt der Schandtat selbst
einsender,email	Angaben zum Einsender
luder	Name der/des Genannten
schandtat	Freitext-Beschreibung
status	eingereicht oder freigegeben

Eigenes Tabellenpraefix (wpdb prefix statt des sonst im Framework ueblichen wpdb base_prefix) – dieses Modul ist bewusst nicht Multisite-übergreifend gedacht, jede Site hat ihre eigene Tabelle.

E-Mail-Benachrichtigungen

Bei jeder neuen Einreichung werden konfigurierbare Admin-Adressen benachrichtigt (Option weinhold_bdm_admin_notify_emails, mehrere Adressen per Zeilenumbruch oder Komma getrennt; ohne Konfiguration greift die WordPress-Admin-E-Mail als Fallback) über die zentrale weinhold_send_module_mail()-Funktion mit dem Template bdm_new_submission. Beim Ablehnen/Löschen eines Eintrags geht zusätzlich eine individuelle Absage direkt per wp_mail() an den Einsender – unabhängig vom Modul-Template-System.

Besonderheiten

Keine Community-Abstimmung: Trotz des Namens „Bastard des Monats“ gibt es weder eine öffentliche Bewertungsfunktion noch eine automatische monatliche Rotation – die redaktionelle Auswahl liegt vollständig bei der Freischaltung durch einen Admin.

Redirect-Fix nach dem Absenden: Nach erfolgreicher Einreichung leitet das Formular per Post/Redirect/Get-Muster auf dieselbe Seite mit ?sent=1 weiter, um ein versehentliches Doppel-Absenden bei Browser-Neuladen zu verhindern.

Historisch gewachsener Code: Der Admin-Renderer enthält mehrere per if (false && …) bewusst deaktivierte Codeblöcke – eine ältere Version der POST-Verarbeitung, die inzwischen komplett in weinhold_bdm_handle_admin_actions() (Hook admin_init) verlagert wurde, aber als toter Code stehen geblieben ist.

Versionshistorie

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

Bastard of the Month

The BdM module manages and presents misdeeds in a cyberpunk terminal style. Members submit entries via a form, an admin approves them — the most recently approved entry counts as the reigning „Bastard of the Month“.

General

In Practice – bastard-des-monats.weinify.de

The module is fully implemented in practice at bastard-des-monats.weinify.de. There you can see live what the terminal UI looks like and how entries are presented.

Submitting & Approving

Via the submission form, any visitor can submit a proposal (name, email, „target“, time of the incident, misdeed as text). New submissions get the status eingereicht (submitted) and appear on the wall as an anonymized, encrypted-looking placeholder entry — only after approval in the admin area (status freigegeben/approved) do the witness’s name, title, and misdeed text become publicly visible.

The Reigning Champion

The most recently approved entry is prominently featured as the „Reigning Champion of Incompetence“. There’s no automatic monthly rotation or voting — which entry is champion is determined purely by which one an admin approved most recently.

Administration

Submitted misdeeds can be approved, edited, or deleted in the dashboard. When deleting, an individual reason can be given, which is automatically emailed to the submitter. The module also automatically notifies configurable admin email addresses about every new submission.

Shortcodes

Shortcode	Description
weinhold_bdm_submit_form	The submission form in terminal design
weinhold_bdm_list	The „wall of shame“: shows all submitted and approved entries
bdm_submit_form	Legacy alias for weinhold_bdm_submit_form
bdm_list	Legacy alias for weinhold_bdm_list

Files

modules/bdm_einsender.php – the module’s only file: database, form processing, admin moderation, email notifications, both frontend shortcodes.

For Developers

Database (table wp_bdm_submissions, prefix from wpdb prefix)

Column	Meaning
submitted_at,event_time	Submission time vs. the time of the misdeed itself
einsender,email	Submitter details
luder	Name of the person called out
schandtat	Free-text description
status	eingereicht (submitted) or freigegeben (approved)

Uses its own wpdb prefix instead of the wpdb base_prefix otherwise standard across the framework — this module is deliberately not meant to span the whole Multisite network, each site has its own table.

Email Notifications

Every new submission notifies configurable admin addresses (option weinhold_bdm_admin_notify_emails, multiple addresses separated by line breaks or commas; falls back to the WordPress admin email if unconfigured) via the central weinhold_send_module_mail() function with the bdm_new_submission template. When rejecting/deleting an entry, an individual rejection also goes directly to the submitter via wp_mail() — independent of the module template system.

Special Cases

No community voting: despite the name „Bastard of the Month“, there’s neither a public rating feature nor an automatic monthly rotation — the editorial selection rests entirely on an admin’s approval.

Redirect fix after submitting: on successful submission, the form redirects to the same page with ?sent=1 using the post/redirect/get pattern, to prevent accidental double-submission on a browser reload.

Historically grown code: the admin renderer contains several code blocks deliberately disabled via if (false && …) — an older version of the POST processing that has since been fully moved into weinhold_bdm_handle_admin_actions() (admin_init hook), but was left in place as dead code.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

pnp-book

PnP Buch

Das Regelwerk im Browser

Das PnP-Book-Modul verwandelt eine WordPress-Seite in ein vollständiges Rollenspielbuch. Kapitel, Unterkapitel, automatisches Inhaltsverzeichnis und clientseitige Suche sind integriert – im DnD-Buch-Look & Feel.

Shortcode

[[weinhold_pnp_book]] – Rendert das vollständige Buch auf einer WordPress-Seite inklusive Navigation, Inhaltsverzeichnis und Suchfunktion.

Inhalte verwalten

Kapitel und Unterkapitel werden im Admin-Dashboard angelegt und können per Drag & Drop sortiert werden. Das Inhaltsverzeichnis wird automatisch aus der Kapitelstruktur generiert.

Suche

Die Suchfunktion durchsucht alle Kapitelinhalte clientseitig in Echtzeit – ohne Seitenneuladung. Ideal für umfangreiche Regelwerke, in denen man schnell eine bestimmte Regel nachschlagen möchte.

Versionshistorie

1.0.0 – 22.09.2026 – Einführung der Versionierung.

PnP Book

The Rulebook in the Browser

The PnP Book module transforms a WordPress page into a complete tabletop RPG rulebook. Chapters, subchapters, automatic table of contents, and client-side search are integrated — in a DnD book look & feel.

Shortcode

[[weinhold_pnp_book]] – Renders the complete book on a WordPress page, including navigation, table of contents, and search.

Managing Content

Chapters and subchapters are created in the admin dashboard and can be sorted via drag & drop. The table of contents is automatically generated from the chapter structure.

Search

The search function searches all chapter content client-side in real time — without page reload. Ideal for extensive rulebooks where you need to quickly look up a specific rule.

Version History

1.0.0 – 22.09.2026 – Introduction of versioning.

10. Juni 2026

lol-comp-generator

LoL Comp Generator

Der LoL Comp Generator erstellt auf Knopfdruck zufällige Team-Kompositionen für League of Legends aus einer verwaltbaren Champion-Datenbank – inklusive Speichern, Teilen und einem zusätzlichen Challenge-Würfel-Modus.

Allgemein

Champions, Sets & Presets

Die Champion-Liste wird im Admin-Dashboard gepflegt. Champions werden zu Sets gruppiert (benannte Champion-Pools je Rolle), mehrere Sets wiederum zu Presets zusammengefasst – ein Preset bestimmt also, aus welchen Sets pro Rolle beim Generieren gezogen wird.

Generieren, Speichern, Teilen

Jede generierte Komposition erhält einen eindeutigen Hash und lässt sich als Link teilen – der Aufruf mit ?lol_session=HASH öffnet direkt die Detailansicht dieser Session, inklusive optionalem Ergebnis, Screenshot, Tags und Notizen.

Challenges

Über einen Umschalter im Generator lässt sich zusätzlich ein Challenge-Modus aktivieren: Aus konfigurierten Kategorien wird per Würfel-Button eine zufällige Challenge gezogen (Name, Beschreibung, optional beteiligte Champions). Ergebnisse lassen sich inklusive Screenshot direkt per Discord-Webhook posten.

Statistiken & Verlauf

Eine chronologische Verlaufsliste sowie Statistiken (Win-Rates, Top-Champions, Leaderboard, Hall of Shame) runden das Modul ab.

Shortcodes

Shortcode	Beschreibung
weinhold_lol_comp_generator	Der Hauptgenerator (3-Schritt-Flow) mit integriertem Challenge-Modus. Mit ?lol_session=HASH direkt zur Session-Detailansicht
weinhold_lol_comp_history	Chronologische Liste aller gespeicherten Sessions mit Tag-Filter
weinhold_lol_comp_stats	Statistiken: Win-Rates, Top-Champions, Leaderboard, Hall of Shame

Dateien

Datei	Inhalt
modules/lol_comp_generator.php	Lade-Stub: Init, Audit-Log- und Discord-Integration, alle AJAX-Registrierungen, Admin- und Cleanup-Einstiegspunkte
modules/lol_comp_generator/db.php	Datenbank-Installation (10 Tabellen) und alle Lese-/Schreibfunktionen
modules/lol_comp_generator/admin.php	Admin-Oberfläche: Champions, Sets, Presets, Sessions verwalten
modules/lol_comp_generator/frontend.php	Frontend-Shortcodes: Generator, Challenges, Verlauf, Statistiken

Für Entwickler

Datenbank (Auswahl)

Tabelle	Inhalt
weinhold_lol_champions	Champion-Stammdaten
weinhold_lol_sets,weinhold_lol_set_champions	Sets und ihre Champion-Zuordnung
weinhold_lol_presets,weinhold_lol_preset_sets	Presets und ihre Set-Zuordnung
weinhold_lol_sessions	Generierte/gespeicherte Kompositionen (hash, preset_id, mode, result, screenshot_path, tags, notes)
weinhold_lol_session_players	Pro Session: Spieler, Rolle, verwendetes Set, gezogener Champion
weinhold_lol_challenge_categories,weinhold_lol_challenges,weinhold_lol_challenge_champions	Challenge-Oberkategorien, einzelne Challenges und ihre Champion-Zuordnung

Berechtigungen

weinhold_lol_comp_generator_current_user_can_view()/_can_edit() setzen zusätzlich zur Modul-Berechtigung immer einen eingeloggten Nutzer voraus – anders als bei rein view-basierten Modulen ist hier auch das reine Ansehen nicht für Gäste vorgesehen.

Discord-Integration

Zwei getrennte Discord-Integrationen über den Filter weinhold_discord_module_integrations: lol_comp_generator (neue gespeicherte Session) und lol_comp_generator_challenge (manuell per Button gepostetes Challenge-Ergebnis). Der Challenge-Discord-Versand läuft dabei NICHT über die zentrale weinhold_discord_fire_module_event()-Funktion wie bei anderen Modulen, sondern baut den Webhook-Request inkl. optionalem Bild-Multipart-Upload (Screenshot als Anhang) direkt selbst zusammen.

AJAX-Endpunkte

Über 20 registrierte wp_ajax_*-Actions, grob in vier Gruppen: Admin-Verwaltung (Champions/Sets/Presets speichern, löschen, synchronisieren), Frontend-Generator (Daten laden, Session speichern, Ergebnis setzen, Screenshot hochladen/ausliefern, Tags/Notizen, Replay), Challenge-Verwaltung (Kategorien und Challenges speichern/löschen, Discord-Versand) sowie ein öffentlicher (nopriv) Endpunkt für Statistiken.

Besonderheiten

Statistik-Endpunkt (get_stats) und Screenshot-Auslieferung (serve_screenshot) sind bewusst auch für nicht eingeloggte Besucher freigegeben (wp_ajax_nopriv_*), obwohl der Rest des Moduls Login voraussetzt – Statistiken und geteilte Screenshots sollen auch ohne Konto einsehbar sein.

Sessions werden über einen eindeutigen hash (nicht die numerische ID) referenziert – verhindert das Erraten fortlaufender Session-IDs beim Teilen von Links.

Der Challenge-Discord-Versand baut den Multipart-Request für Bild-Uploads manuell zusammen (eigener Boundary-String), da WordPress‘ wp_remote_post() keine native Unterstützung für multipart/form-data mit Dateianhang bietet.

Versionshistorie

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

LoL Comp Generator

The LoL Comp Generator creates random League of Legends team compositions at the click of a button from a manageable champion database — including saving, sharing, and an additional Challenges dice-roll mode.

General

Champions, Sets & Presets

The champion list is maintained in the admin dashboard. Champions are grouped into sets (named champion pools per role), and multiple sets are in turn combined into presets — a preset determines which sets are drawn from per role when generating.

Generate, Save, Share

Every generated composition gets a unique hash and can be shared as a link — visiting with ?lol_session=HASH opens that session’s detail view directly, including an optional result, screenshot, tags and notes.

Challenges

A toggle in the generator additionally enables a Challenges mode: a roll button draws a random challenge from configured categories (name, description, optionally involved champions). Results, including a screenshot, can be posted directly via Discord webhook.

Statistics & History

A chronological history list plus statistics (win rates, top champions, leaderboard, hall of shame) round out the module.

Shortcodes

Shortcode	Description
weinhold_lol_comp_generator	The main generator (3-step flow) with built-in Challenges mode. With ?lol_session=HASH, jumps straight to that session’s detail view
weinhold_lol_comp_history	Chronological list of all saved sessions with tag filtering
weinhold_lol_comp_stats	Statistics: win rates, top champions, leaderboard, hall of shame

Files

File	Content
modules/lol_comp_generator.php	Load stub: init, audit log and Discord integration, all AJAX registrations, admin and cleanup entry points
modules/lol_comp_generator/db.php	Database installation (10 tables) and all read/write functions
modules/lol_comp_generator/admin.php	Admin UI: manage champions, sets, presets, sessions
modules/lol_comp_generator/frontend.php	Frontend shortcodes: generator, challenges, history, statistics

For Developers

Database (Selection)

Table	Content
weinhold_lol_champions	Champion master data
weinhold_lol_sets,weinhold_lol_set_champions	Sets and their champion assignment
weinhold_lol_presets,weinhold_lol_preset_sets	Presets and their set assignment
weinhold_lol_sessions	Generated/saved compositions (hash, preset_id, mode, result, screenshot_path, tags, notes)
weinhold_lol_session_players	Per session: player, role, set used, champion drawn
weinhold_lol_challenge_categories,weinhold_lol_challenges,weinhold_lol_challenge_champions	Challenge top-level categories, individual challenges and their champion assignment

Permissions

weinhold_lol_comp_generator_current_user_can_view()/_can_edit() always require a logged-in user in addition to the module permission — unlike purely view-based modules, plain viewing isn’t intended for guests here either.

Discord Integration

Two separate Discord integrations via the weinhold_discord_module_integrations filter: lol_comp_generator (new saved session) and lol_comp_generator_challenge (challenge result posted manually via button). The challenge Discord send does NOT go through the central weinhold_discord_fire_module_event() function used by other modules — it builds the webhook request, including an optional multipart image upload (screenshot as attachment), itself.

AJAX Endpoints

Over 20 registered wp_ajax_* actions, roughly in four groups: admin management (save/delete/sync champions, sets, presets), frontend generator (load data, save session, set result, upload/serve screenshot, tags/notes, replay), challenge management (save/delete categories and challenges, Discord send), and one public (nopriv) endpoint for statistics.

Special Cases

The statistics endpoint (get_stats) and screenshot serving (serve_screenshot) are deliberately open to logged-out visitors too (wp_ajax_nopriv_*), even though the rest of the module requires login — statistics and shared screenshots should be viewable without an account.

Sessions are referenced by a unique hash (not the numeric ID) — prevents guessing sequential session IDs when sharing links.

The challenge Discord send builds the multipart request for image uploads manually (its own boundary string), since WordPress‘ wp_remote_post() has no native support for multipart/form-data with a file attachment.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

media-player

Media Player

Das Media-Player-Modul bringt einen vollwertigen Audioplayer mit Playlisten-Verwaltung ins Weinhold Framework. Titel, Interpret, Cover-Bild, Download-Button, Favoriten und eigene Playlisten für eingeloggte Nutzer sind komplett integriert.

Allgemein

Playlisten verwalten

Im Dashboard unter Weinhold → Media Player werden Playlisten angelegt und Titel aus der WordPress-Mediathek hinzugefügt. Jeder Titel kann mit eigenen Metadaten (Titel, Interpret, Beschreibung, Cover-Bild) versehen werden, die die Mediathek-Angaben überschreiben. Playlisten und Titel lassen sich per Drag & Drop sortieren.

Für eingeloggte Nutzer: Favoriten & eigene Playlisten

Eingeloggte Besucher können Titel als Favorit markieren und eigene Playlisten aus dem vorhandenen Track-Angebot zusammenstellen – gespeichert pro Nutzer und pro Seite, auf der der Player eingebettet ist. Auch die zuletzt eingestellte Lautstärke wird pro Nutzer gemerkt. Der Player bietet dafür eigene Reiter: „Alle Tracks“, „Favoriten“ und „Meine Playlists“.

Gestaltung

Ein eigenes Custom-CSS-Feld im Dashboard erlaubt Anpassungen am Frontend-Design zusätzlich zur mitgelieferten Standardvorlage.

Shortcodes

Shortcode	Beschreibung
weinhold_media_player	Rendert den Player. Attribute: playlists (kommagetrennte Playlist-IDs, Standard alle), show_playlist_names (1/0), show_playlist_icons (1/0), collapsed (1/0, Liste initial eingeklappt starten)

Beispiel: nur bestimmte Playlisten und eingeklappt starten: playlists=“1,3,5″ collapsed=“1″.

Dateien

modules/media_player.php – einzige PHP-Datei des Moduls: Einstellungen, Track-Aufbereitung, AJAX-Handler für Favoriten/Lautstärke/eigene Playlisten, Shortcode-Rendering, Admin-Oberfläche, Cleanup. Frontend-Player-Logik in assets/weinhold_media_player_front.js, Admin-UI (Mediathek-Auswahl, Drag&Drop) in assets/weinhold_media_player_admin.js.

Für Entwickler

Datenhaltung

Playlisten/Tracks liegen als verschachteltes Array in der Option weinhold_media_player_settings (kein eigenes DB-Schema, Tracks referenzieren Anhänge der WordPress-Mediathek per media_id). Nutzerbezogene Daten (Favoriten, eigene Playlisten, Lautstärke) liegen als User-Meta, jeweils zusätzlich nach Blog-ID und – bei Favoriten/eigenen Playlisten – nach page_context getrennt (weinhold_media_player_get_page_context_key(): Beitrags-/Seiten-ID, sonst ein Hash der Request-URI).

AJAX-Endpunkte

Action	Zweck
weinhold_media_player_toggle_favorite	Track als Favorit markieren/entfernen
weinhold_media_player_save_volume	Lautstärke des Nutzers speichern
weinhold_media_player_save_user_playlists	Eigene Playlisten des Nutzers speichern (als JSON übergeben)

Alle drei erfordern einen eingeloggten Nutzer und einen Nonce, kein nopriv-Pendant.

Datenübergabe ans Frontend

Der komplette Player-Zustand (Tracks, Playlisten, eigene Playlisten, Favoriten, Lautstärke, Login-Status) wird als JSON im data-media-player-Attribut des Wrapper-Divs ausgegeben, nicht per wp_localize_script() – das Frontend-JS liest es direkt aus dem DOM.

Besonderheiten

Cover-Bild-Fallback: Ist für einen Track kein eigenes Cover hinterlegt, wird automatisch das Vorschaubild der Mediendatei selbst als Cover verwendet (falls vorhanden), bevor ganz auf ein Cover verzichtet wird.

Legacy-Migration bei Favoriten: Ältere Installationen speicherten Favoriten ohne page_context-Trennung. Beim ersten Zugriff auf eine noch nicht existierende page-context-spezifische Favoritenliste wird automatisch auf den alten, globalen Schlüssel zurückgegriffen und in den neuen migriert.

Cleanup entfernt Nutzer-Metadaten musterbasiert per SQL LIKE (z. B. alle weinhold_media_player_playlists_{blog_id}_*-Einträge über alle Nutzer hinweg), nicht nur die globalen Plugin-Einstellungen – wichtig, weil pro Nutzer und Seitenkontext eigene Meta-Keys entstehen, die sich nicht einzeln aufzählen lassen.

Versionshistorie

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

Media Player

The Media Player module brings a full-featured audio player with playlist management to the Weinhold Framework. Track title, artist, cover image, download button, favorites, and custom playlists for logged-in users are fully integrated.

General

Managing Playlists

Playlists are created and tracks are added from the WordPress media library in the dashboard under Weinhold → Media Player. Each track can have its own metadata (title, artist, description, cover image) that overrides the media library’s info. Playlists and tracks can be sorted via drag & drop.

For Logged-In Users: Favorites & Custom Playlists

Logged-in visitors can mark tracks as favorites and build their own playlists from the available tracks — saved per user and per page the player is embedded on. The last set volume is also remembered per user. The player provides dedicated tabs for this: „All Tracks“, „Favorites“, and „My Playlists“.

Styling

A dedicated custom CSS field in the dashboard allows adjustments to the frontend design in addition to the included default styling.

Shortcodes

Shortcode	Description
weinhold_media_player	Renders the player. Attributes: playlists (comma-separated playlist IDs, default all), show_playlist_names (1/0), show_playlist_icons (1/0), collapsed (1/0, start the list collapsed)

Example: only specific playlists, starting collapsed: playlists=“1,3,5″ collapsed=“1″.

Files

modules/media_player.php – the module’s only PHP file: settings, track preparation, AJAX handlers for favorites/volume/custom playlists, shortcode rendering, admin UI, cleanup. Frontend player logic lives in assets/weinhold_media_player_front.js, admin UI (media library picker, drag&drop) in assets/weinhold_media_player_admin.js.

For Developers

Data Storage

Playlists/tracks live as a nested array in the weinhold_media_player_settings option (no dedicated DB schema, tracks reference WordPress media library attachments via media_id). User-specific data (favorites, custom playlists, volume) live as user meta, additionally separated by blog ID and — for favorites/custom playlists — by page_context (weinhold_media_player_get_page_context_key(): post/page ID, otherwise a hash of the request URI).

AJAX Endpoints

Action	Purpose
weinhold_media_player_toggle_favorite	Mark/unmark a track as a favorite
weinhold_media_player_save_volume	Save the user’s volume
weinhold_media_player_save_user_playlists	Save the user’s custom playlists (passed as JSON)

All three require a logged-in user and a nonce, no nopriv counterpart.

Data Handoff to the Frontend

The complete player state (tracks, playlists, custom playlists, favorites, volume, login status) is output as JSON in the data-media-player attribute of the wrapper div, not via wp_localize_script() — the frontend JS reads it directly from the DOM.

Special Cases

Cover image fallback: if a track has no dedicated cover set, the media file’s own thumbnail is automatically used as the cover (if available), before falling back to no cover at all.

Legacy migration for favorites: older installations stored favorites without page_context separation. The first time a page-context-specific favorites list doesn’t exist yet, the module automatically falls back to the old global key and migrates it into the new one.

Cleanup removes user meta pattern-based via SQL LIKE (e.g. every weinhold_media_player_playlists_{blog_id}_* entry across all users), not just the global plugin settings — necessary because each user and page context creates its own meta keys that can’t be enumerated individually.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

Schlagwort: weinhold-framework

Jeopardy – Login-Brücke

Anmelden aus der App heraus

Was die Anmeldung in der App erlaubt

Abmelden

Kein eigener Datenbank-State

Ablauf und Einstieg

Token

Konfiguration

Jeopardy – Login Bridge

Signing In from the App

What Signing In Allows in the App

Signing Out

No Database State of Its Own

Flow and Entry Point

Token

Configuration

PPNP Game – Login-Brücke

Spielstart per Button

Drei getrennte Spiel-Berechtigungen

Spielerliste für den Node-Dienst

Kein eigener Datenbank-State

Selbst gebautes HS256-JWT ohne Bibliothek

Server-zu-Server per Shared Secret

PPNP Game – Login Bridge

Launching the Game via a Button

Three Separate Game Permissions

Player List for the Node Service

No Database State of Its Own

A Hand-Rolled HS256 JWT, No Library

Server-to-Server via Shared Secret

Login Gate

Ablauf

Netzwerkweit, zentral gesteuert

Zusammenspiel mit reCAPTCHA

Einhängepunkt: weinhold_auth_login_override

Cookie & Transient

Schutz vor direkten POST-Angriffen

Login Gate

Flow

Network-Wide, Centrally Controlled

Working Together with reCAPTCHA

Hook Point: weinhold_auth_login_override

Cookie & Transient

Protection Against Direct POST Attacks

reCAPTCHA

Score statt Bilderrätsel

Vier schützbare Formulare

Statistik-Dashboard

Verschlüsselter API-Key

Fail-Open bei Google-Ausfall

Login-Prüfung ohne Security-Manager-Zählung

Automatische Formular-Erkennung

reCAPTCHA

A Score Instead of Image Puzzles

Four Protectable Forms

Statistics Dashboard

Encrypted API Key

Fail-Open on Google Outage

Login Check Without Security Manager Counting It

Automatic Form Detection

RudelRoots

Zutaten & Sets

Bedarfsrechner mit zwei Modi

Übersichtsliste

Datenbank

Rechenlogik

Bild-Upload & Audit-Log

RudelRoots

Ingredients & Sets

Two-Mode Calculator

Overview List

Database

Calculation Logic

Image Upload & Audit Log

MCP Server Manager

Katalog & Freischaltung

API-Tokens für KI-Clients

OAuth-2.1-Connector-Support

Eingebettete Web-Oberflächen