Schlagwort: 🏠

familien-bestellungen

Familien-Bestellungen

Das Familien-Bestellungen-Modul vereinfacht wiederkehrende Sammelbestellungen innerhalb einer Gruppe – ob Familie, Freundeskreis oder Community. Jedes Mitglied trägt seine Menge pro Position ein, ein Koordinator behält die Gesamtübersicht.

Allgemein

Eine Bestellung erstellen

Ein Koordinator legt eine Sammelbestellung mit Titel, Beschreibung, optionalem Shop-Link, einer Liste von Positionen und einer Einsendefrist an. Ausgewählte Mitglieder werden per E-Mail über die neue Bestellung informiert.

Mengen eintragen

Solange eine Bestellung offen ist, tragen Mitglieder ihre gewünschte Menge pro Position direkt im Frontend ein – mehrfach anpassbar, bis die Frist erreicht ist.

Fristen & automatische E-Mails

Ein stündlicher Hintergrundjob prüft alle offenen Bestellungen: Läuft die Frist in weniger als sieben Tagen ab, wird einmalig eine Erinnerungsmail verschickt (an die ursprünglich benachrichtigten Mitglieder UND alle, die bereits eine Menge eingetragen haben). Ist die Frist erreicht, schließt das Modul die Bestellung automatisch und verschickt eine Abschluss-Zusammenfassung.

Koordinator-Übersicht & Export

Der Koordinator sieht eine Gesamtübersicht aller Positionen mit Mengen pro Nutzer und kann die Bestellung als CSV exportieren.

Shortcodes

Shortcode	Beschreibung
weinhold_family_orders	Rendert die Bestellübersicht: offene und abgeschlossene Bestellungen, Erstell-Formular, Detail-/Mengen-Ansicht

Dateien

modules/family_orders.php – einzige Datei des Moduls: Datenbank, Cron-Job, Frontend-Formularverarbeitung, drei E-Mail-Versandfunktionen, CSV-Export, Shortcode, Admin-Seite, Cleanup.

Für Entwickler

Datenbank

Tabelle	Spalten	(Auswahl)
weinhold_family_orders	title, description, shop_url, status	(open/closed), deadline_gmt, notify_user_ids, launch_mail_sent, reminder_mail_sent, closed_mail_sent
weinhold_family_order_items	order_id, name, item_url, sort_order
weinhold_family_order_entries	order_id, item_id, user_id, quantity	(unique je Kombination aus allen dreien)

Cron-Job

weinhold_family_orders_cron_tick läuft stündlich (registriert 15 Minuten nach der Modul-Aktivierung, WP-Cron-Standardintervall hourly). weinhold_family_orders_run_cron_tick() schließt Bestellungen mit abgelaufener Frist automatisch und löst dabei die Abschluss-Mail aus, verschickt außerdem für Bestellungen mit Frist innerhalb der nächsten sieben Tage einmalig die Erinnerungsmail (Flags launch_mail_sent/reminder_mail_sent/closed_mail_sent verhindern Mehrfachversand).

Drei E-Mail-Funktionen

Funktion	Wann	Empfänger
weinhold_family_orders_send_launch_mail($order_id)	Bei	Erstellung Konfigurierte notify_user_ids
weinhold_family_orders_send_reminder_mail($order)	Frist	in unter 7 Tagen notify_user_ids PLUS alle, die bereits eine Menge eingetragen haben
weinhold_family_orders_send_closed_summary_mail($order_id)	Frist	erreicht notify_user_ids

Besonderheiten

Die Erinnerungsmail geht NICHT nur an Mitglieder ohne Eintrag, sondern zusätzlich an alle, die bereits eine Menge eingetragen haben – vermutlich damit auch Teilnehmer, die schon mitgemacht haben, ihre Mengen vor Fristende noch anpassen können.

Alle drei E-Mail-Funktionen nutzen direktes wp_mail() statt des zentralen Template-Systems des E-Mail-Versand-Moduls – anders als z. B. Gerätesicherheit oder Security Manager, die ihre Benachrichtigungen über weinhold_send_module_mail() mit anpassbaren Vorlagen versenden.

Eigenes Tabellenpräfix wpdb prefix statt des sonst im Framework üblichen wpdb base_prefix – wie beim Bastard-des-Monats-Modul ist dieses Modul bewusst nicht Multisite-übergreifend gedacht.

Versionshistorie

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

Family Orders

The Family Orders module simplifies recurring group orders within a group — whether family, friends, or a community. Each member enters their quantity per item, and a coordinator keeps the overall overview.

General

Creating an Order

A coordinator creates a group order with a title, description, optional shop link, a list of items, and a submission deadline. Selected members are notified by email about the new order.

Entering Quantities

As long as an order is open, members enter their desired quantity per item directly in the frontend — adjustable repeatedly until the deadline is reached.

Deadlines & Automatic Emails

An hourly background job checks all open orders: if the deadline is less than seven days away, a one-time reminder email is sent (to the originally notified members AND everyone who has already entered a quantity). Once the deadline is reached, the module automatically closes the order and sends a closing summary.

Coordinator Overview & Export

The coordinator sees an overall overview of all items with quantities per user and can export the order as CSV.

Shortcodes

Shortcode	Description
weinhold_family_orders	Renders the order overview: open and closed orders, creation form, detail/quantity view

Files

modules/family_orders.php – the module’s only file: database, cron job, frontend form processing, three email-sending functions, CSV export, shortcode, admin page, cleanup.

For Developers

Database

Table	Columns	(selection)
weinhold_family_orders	title, description, shop_url, status	(open/closed), deadline_gmt, notify_user_ids, launch_mail_sent, reminder_mail_sent, closed_mail_sent
weinhold_family_order_items	order_id, name, item_url, sort_order
weinhold_family_order_entries	order_id, item_id, user_id, quantity	(unique per combination of all three)

Cron Job

weinhold_family_orders_cron_tick runs hourly (scheduled 15 minutes after module activation, WP-Cron’s standard hourly interval). weinhold_family_orders_run_cron_tick() automatically closes orders past their deadline, triggering the closing email, and also sends the one-time reminder email for orders with a deadline within the next seven days (the launch_mail_sent/reminder_mail_sent/closed_mail_sent flags prevent duplicate sends).

Three Email Functions

Function	When	Recipients
weinhold_family_orders_send_launch_mail($order_id)	On	creation Configured notify_user_ids
weinhold_family_orders_send_reminder_mail($order)	Deadline	under 7 days away notify_user_ids PLUS everyone who has already entered a quantity
weinhold_family_orders_send_closed_summary_mail($order_id)	Deadline	reached notify_user_ids

Special Cases

The reminder email does NOT go only to members without an entry, but additionally to everyone who has already entered a quantity — presumably so participants who already joined in can still adjust their quantities before the deadline.

All three email functions use direct wp_mail() instead of the Email Delivery module’s central template system — unlike, for example, Device Security or Security Manager, which send their notifications via weinhold_send_module_mail() with customizable templates.

Uses its own wpdb prefix instead of the wpdb base_prefix otherwise standard across the framework — like the Bastard of the Month module, this module is deliberately not meant to span the whole Multisite network.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

analyse

Analyse

Das Analyse-Modul bietet einen dedizierten Bereich für Match-Analysen mit Video- und Texteinträgen. Eingeloggte Nutzer können Analysen erstellen, bearbeiten, als Favorit markieren und kommentieren.

Allgemein

Video- & Text-Einträge

Jede Analyse hat einen Titel und wahlweise einen Video-Link oder einen ausführlichen Textinhalt. Video-Links werden automatisch eingebettet: unterstützt werden YouTube (inkl. Shorts), Twitch-VODs und Twitch-Clips. Für YouTube wird zusätzlich automatisch ein Vorschaubild aus dem Video gezogen.

Favoriten & Kommentare

Einträge lassen sich als Favorit markieren und in der Übersicht danach filtern. Die Kommentarfunktion erlaubt den direkten Austausch zu einzelnen Einträgen. Kombiniert mit dem Reactions-Modul lassen sich Kommentare zusätzlich mit Likes/Dislikes bewerten.

Berechtigungen

Über das Benutzerverwaltungs-Modul lässt sich genau steuern, wer Analysen lesen (view) und wer sie erstellen oder bearbeiten (edit) darf – unabhängig pro Subsite. Beide Berechtigungen setzen zusätzlich einen eingeloggten Nutzer voraus, auch für reines Lesen gibt es keinen Gastzugang.

Shortcodes

Shortcode	Beschreibung
weinhold_analyse	Rendert den vollständigen Analyse-Bereich mit Übersicht, Such- und Favoriten-Filter sowie Detail-/Bearbeiten-Ansichten

Dateien

modules/analyse.php – einzige Datei des Moduls: Datenbank, Einbettungs-Erkennung, Frontend-Formularverarbeitung, Übersichts-/Detail-/Bearbeiten-Ansichten, Shortcode, Admin-Seite, Cleanup.

Für Entwickler

Datenbank

Tabelle	Spalten	(Auswahl)
weinhold_analyse_entries	creator_user_id, caption, description, video_url, content_type, site_id
weinhold_analyse_comments	entry_id, user_id, comment_text
weinhold_analyse_favorites	entry_id, user_id	(Unique je Kombination)

Versionierte Migration: DB-Version 1 zu 2 fügt nachträglich die Spalte content_type sowie die komplette Favoriten-Tabelle hinzu (weinhold_analyse_maybe_install() prüft den gespeicherten Versionsstand und wendet nur die fehlenden Schritte an).

Video-Einbettung erkennen

weinhold_analyse_get_embed_url($url) erkennt per regulärem Ausdruck YouTube-Videos (inkl. Shorts), Twitch-VODs und Twitch-Clips und baut daraus die passende iframe-Embed-URL, inklusive korrektem parent-Parameter für Twitch (aus der aktuellen Domain abgeleitet). weinhold_analyse_get_thumbnail_url($url) liefert zusätzlich ein Vorschaubild, aktuell nur für YouTube implementiert.

Wichtige Funktionen

Funktion	Beschreibung
weinhold_analyse_get_entries($site_id,$search,$offset,$per_page,$only_favorites,$user_id)	Gefilterte, paginierte Liste der Einträge
weinhold_analyse_is_favorited($entry_id,$user_id)	Ob ein Nutzer einen Eintrag favorisiert hat
weinhold_analyse_current_user_can()/_can_edit()	Berechtigungsprüfungen, beide verlangen zusätzlich einen eingeloggten Nutzer

Besonderheiten

Twitch-Embeds benötigen zwingend den korrekten parent-Parameter (die eigene Domain) – ohne ihn verweigert Twitch die Einbettung im iframe. Das Modul leitet ihn automatisch aus home_url() ab, keine manuelle Konfiguration nötig.

Rich-Text-Editor wird gezielt erzwungen: An zwei Stellen im Bearbeiten-Formular wird der Filter user_can_richedit kurzzeitig mit hoher Priorität auf wahr gesetzt, damit der volle WordPress-Editor auch für Nutzer ohne die sonst dafür nötige Berechtigung zur Verfügung steht.

Content-Type als einfaches Integer-Flag: content_type unterscheidet Video- von Text-Einträgen als tinyint statt als beschreibender String – bei Erweiterung um weitere Inhaltstypen wäre eine Umstellung auf lesbare Werte sinnvoll.

Versionshistorie

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

Analysis

The Analysis module provides a dedicated area for match analyses with video and text entries. Logged-in users can create, edit, favorite, and comment on analyses.

General

Video & Text Entries

Every analysis has a title and either a video link or a longer text body. Video links are embedded automatically: YouTube (including Shorts), Twitch VODs, and Twitch clips are supported. For YouTube, a thumbnail is also pulled from the video automatically.

Favorites & Comments

Entries can be marked as favorites and filtered by that in the overview. The comment feature allows direct discussion on individual entries. Combined with the Reactions module, comments can additionally be rated with likes/dislikes.

Permissions

Via the User Management module, it can be precisely controlled who can read analyses (view) and who can create or edit them (edit) — independently per subsite. Both permissions additionally require a logged-in user; there’s no guest access even for plain reading.

Shortcodes

Shortcode	Description
weinhold_analyse	Renders the complete analysis area with overview, search and favorites filter, plus detail/edit views

Files

modules/analyse.php – the module’s only file: database, embed detection, frontend form processing, overview/detail/edit views, shortcode, admin page, cleanup.

For Developers

Database

Table	Columns	(selection)
weinhold_analyse_entries	creator_user_id, caption, description, video_url, content_type, site_id
weinhold_analyse_comments	entry_id, user_id, comment_text
weinhold_analyse_favorites	entry_id, user_id	(unique per combination)

Versioned migration: DB version 1 to 2 retroactively adds the content_type column plus the entire favorites table (weinhold_analyse_maybe_install() checks the stored version and only applies the missing steps).

Detecting Video Embeds

weinhold_analyse_get_embed_url($url) uses a regular expression to recognize YouTube videos (including Shorts), Twitch VODs, and Twitch clips, building the matching iframe embed URL, including the correct parent parameter for Twitch (derived from the current domain). weinhold_analyse_get_thumbnail_url($url) additionally provides a thumbnail, currently only implemented for YouTube.

Key Functions

Function	Description
weinhold_analyse_get_entries($site_id,$search,$offset,$per_page,$only_favorites,$user_id)	Filtered, paginated list of entries
weinhold_analyse_is_favorited($entry_id,$user_id)	Whether a user has favorited an entry
weinhold_analyse_current_user_can()/_can_edit()	Permission checks, both additionally require a logged-in user

Special Cases

Twitch embeds strictly require the correct parent parameter (your own domain) — without it, Twitch refuses the iframe embed. The module derives it automatically from home_url(), no manual configuration needed.

The rich text editor is deliberately forced: at two points in the edit form, the user_can_richedit filter is briefly set to true at high priority, so the full WordPress editor is available even to users without the permission normally required for it.

Content type as a plain integer flag: content_type distinguishes video from text entries as a tinyint rather than a descriptive string — if more content types are added later, switching to readable values would make sense.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

wunschliste

Wunschliste

Das Wunschlisten-Modul ermöglicht gemeinsame Wunschlisten für Mitglieder einer Webseite. Der clevere Trick: Andere Nutzer können Wünsche als „gekauft“ markieren – der Listenbesitzer sieht das aber erst nach einem selbst festgelegten Datum.

Allgemein

Wünsche verwalten

Jeder Wunsch besteht aus Name, optionalem Link und Menge. Die Verwaltung der eigenen Liste (Titel, Kurzbeschreibung, ausführliche Beschreibung, Reihenfolge der Wünsche, Verbergen-Datum) erfolgt direkt im Frontend, solange die Liste noch verborgen ist.

Verdeckte Kaufmarkierung

Sobald ein anderer Nutzer einen Wunsch als „gekauft“ markiert, sieht der Listenbesitzer bis zum eingestellten Datum ausschließlich „Bis Datum verborgen“ – unabhängig vom tatsächlichen Status. Erst nach Ablauf der Frist wird sichtbar, was gekauft wurde und von wem. Hat ein anderer Nutzer einen Wunsch bereits markiert, können weitere Nutzer ihn nicht zusätzlich markieren oder entmarkieren – nur wer selbst markiert hat, kann die Markierung wieder rückgängig machen.

Zugriff

Sichtbar sind nur Wunschlisten von Mitgliedern der jeweiligen Website (bei Multisite: Mitgliedschaft auf der konkreten Subsite, Netzwerk-Administratoren sehen immer alles).

Shortcodes

Shortcode	Beschreibung
weinhold_wishlist	Rendert die Wunschlisten-Übersicht. Eingeloggte Nutzer sehen ihre eigene Liste und können die Listen anderer Mitglieder einsehen

Dateien

modules/wishlist.php – einzige Datei des Moduls: Datenbank, Datum-/Zeitzonen-Hilfsfunktionen, Frontend-Formularverarbeitung, Listen- und Detailansicht, Shortcode, Cleanup.

Für Entwickler

Datenbank

Tabelle	Spalten	(Auswahl)
weinhold_wishlists	owner_user_id, title, caption, description, reveal_at_gmt
weinhold_wishlist_items	wishlist_id, name, item_url, quantity, sort_order, purchased_by, purchased_at_gmt

Beide Tabellen nutzen das site-lokale wpdb prefix, keine eigene site_id-Trennung auf Item-Ebene (die liegt nur auf der Listen-Tabelle).

Zeitzonen-Handling

reveal_at_gmt wird konsequent in UTC gespeichert. weinhold_wishlist_parse_local_datetime() wandelt die lokale Eingabe aus dem datetime-local-Formularfeld in UTC um, weinhold_wishlist_get_datetime_input_value() den umgekehrten Weg fürs erneute Befüllen des Formulars, weinhold_wishlist_format_local_datetime() für die reine Anzeige in der Zeitzone der Website.

Wichtige Funktionen

Funktion	Beschreibung
weinhold_wishlist_user_has_access($user_id,$site_id)	Prüft Mitgliedschaft auf der Site (Multisite: is_user_member_of_blog, Super-Admins immer erlaubt)
weinhold_wishlist_get_lists_for_site($site_id,$mode)	Listet Listen einer Site, Modus open oder revealed (nach reveal_at_gmt gefiltert)
weinhold_wishlist_render_detail($list,$user_id,$site_id)	Rendert eine einzelne Liste inkl. der komletten Sichtbarkeitslogik für Kaufstatus

Besonderheiten

Die Verbergung ist konsequent serverseitig: Der Kaufstatus wird dem Besitzer schlicht nie ausgeliefert, solange reveal_at_gmt in der Zukunft liegt – nicht nur per CSS versteckt, sondern gar nicht erst unterscheidbar von „nicht gekauft“ gerendert.

Kein Prioritäts- oder Bildfeld je Wunsch: Anders als man vom Namen „Wunschliste“ erwarten könnte, unterstützt das Datenmodell aktuell nur Name, Link und Menge pro Eintrag – keine Prioritätsstufen, keine Bilder.

Formulare werden auf der wp-Action verarbeitet (weinhold_wishlist_handle_frontend_actions(), vor dem Template-Rendering), das im Framework übliche Muster für Frontend-POST-Verarbeitung.

Versionshistorie

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

Wishlist

The Wishlist module enables shared wishlists for members of a website. The clever trick: other users can mark wishes as „purchased“ — but the list owner only sees this after a date they set themselves.

General

Managing Wishes

Every wish consists of a name, an optional link, and a quantity. Managing your own list (title, short caption, longer description, order of wishes, reveal date) happens directly in the frontend, as long as the list is still hidden.

Hidden Purchase Marking

Once another user marks a wish as „purchased“, the list owner only ever sees „Hidden until date“ until the set date is reached — regardless of the actual status. Only once the deadline passes does it become visible what was purchased and by whom. If another user has already marked a wish, further users can’t mark or unmark it — only the person who marked it can undo their own marking.

Access

Only wishlists of members of the respective website are visible (on Multisite: membership on that specific subsite; network administrators always see everything).

Shortcodes

Shortcode	Description
weinhold_wishlist	Renders the wishlist overview. Logged-in users see their own list and can view other members‘ lists

Files

modules/wishlist.php – the module’s only file: database, date/timezone helpers, frontend form processing, list and detail views, shortcode, cleanup.

For Developers

Database

Table	Columns	(selection)
weinhold_wishlists	owner_user_id, title, caption, description, reveal_at_gmt
weinhold_wishlist_items	wishlist_id, name, item_url, quantity, sort_order, purchased_by, purchased_at_gmt

Both tables use the site-local wpdb prefix; there’s no separate site_id column at the item level (only the list table has one).

Timezone Handling

reveal_at_gmt is consistently stored in UTC. weinhold_wishlist_parse_local_datetime() converts the local input from the datetime-local form field into UTC, weinhold_wishlist_get_datetime_input_value() does the reverse for re-populating the form, and weinhold_wishlist_format_local_datetime() is purely for display in the site’s timezone.

Key Functions

Function	Description
weinhold_wishlist_user_has_access($user_id,$site_id)	Checks site membership (Multisite: is_user_member_of_blog, super admins always allowed)
weinhold_wishlist_get_lists_for_site($site_id,$mode)	Lists a site’s wishlists, mode open or revealed (filtered by reveal_at_gmt)
weinhold_wishlist_render_detail($list,$user_id,$site_id)	Renders a single list including the full purchase-status visibility logic

Special Cases

Hiding is consistently server-side: the purchase status is simply never delivered to the owner while reveal_at_gmt is in the future — not just hidden via CSS, but rendered in a way that’s indistinguishable from „not purchased“ in the first place.

No priority or image field per wish: contrary to what the name „wishlist“ might suggest, the current data model only supports name, link, and quantity per entry — no priority levels, no images.

Forms are processed on the wp action (weinhold_wishlist_handle_frontend_actions(), before template rendering), the framework’s standard pattern for frontend POST processing.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

about-page

About Page

Das About-Page-Modul stellt eine persönliche Über-mich-Seite bereit, die direkt über einen Shortcode auf jeder WordPress-Seite eingebunden werden kann. Zweisprachige Inhalte und ein eigenes Styling sind inklusive.

Allgemein

Mehrsprachigkeit

Inhalte können in beiden Sprachen gepflegt werden, ohne eine zweite Seite anzulegen – ist nur eine Sprache vorhanden, wird der Umschalter automatisch ausgeblendet. Die Sprachwahl wird im Browser gemerkt (localStorage) und mit der Sprachwahl der übrigen Framework-Seiten (Blog-Listen-Modul) synchron gehalten, auch wenn die About-Seite ihren Umschalter technisch eigenständig implementiert.

In der Praxis

Auf weinify.de wird der weinhold_about-Shortcode für die persönliche Vorstellungsseite eingesetzt. Das Modul liefert dabei ein konsistentes, zum restlichen Framework passendes Design.

Shortcodes

Shortcode	Beschreibung
weinhold_about	Wrapper-Shortcode – umschließt weinhold_about_de/_en, baut den Sprachumschalter und lädt Styles/JS
weinhold_about_de	Deutscher Inhalt, nur innerhalb von weinhold_about
weinhold_about_en	Englischer Inhalt, nur innerhalb von weinhold_about
about_deutsch	Legacy-Alias für weinhold_about_de – bereits in bestehenden Beiträgen im Einsatz, in neuen Beiträgen weinhold_about_de verwenden
about_englisch	Legacy-Alias für weinhold_about_en – in neuen Beiträgen weinhold_about_en verwenden

Beispiel: weinhold_about als äußerer Wrapper, darin je ein Block weinhold_about_de mit deutschem und weinhold_about_en mit englischem Inhalt.

Dateien

modules/about_page.php – einzige Datei des Moduls: Shortcode-Registrierung, Wrapper-Rendering, Sprachumschalter (Inline-CSS/JS), Admin-Hilfeseite.

Für Entwickler

Wie der Wrapper funktioniert

weinhold_about_page_render_wrapper() setzt vor dem Rendern eine globale Zwischenablage ($weinhold_about_page_blocks) zurück und ruft do_shortcode() auf dem umschlossenen Inhalt auf. Die inneren Shortcodes weinhold_about_de/_en schreiben ihren gerenderten Inhalt nur in diese Zwischenablage und geben selbst einen leeren String zurück – der eigentliche HTML-Aufbau (Umschalter + beide Sprachblöcke) passiert erst danach im Wrapper. Ist nur eine der beiden Sprachen vorhanden, entfällt der Umschalter komplett.

Sprachumschalter

Eigenständige, kleine Inline-JS-Implementierung (kein Shortcode-Nesting wie beim Blog-List-Modul): blendet per CSS display den jeweils inaktiven Sprachblock aus und schreibt die Wahl in localStorage (Schlüssel weinhold_lang) – derselbe Schlüssel, den auch das Blog-List-Modul verwendet, wodurch die Sprachwahl seitenübergreifend konsistent bleibt.

Besonderheiten

Die Admin-Hilfeseite (Weinhold → About Page) dokumentiert weiterhin nur die Legacy-Aliase about_deutsch/about_englisch als Beispiel, nicht die kanonischen weinhold_about_de/_en-Tags – funktional identisch, aber bei neuem Modul-Code sollte die Doku-Seite künftig die kanonischen Tags zeigen.

Style-Parameter des weinhold_about-Wrappers (style=“default“) wird aktuell nur als CSS-Klasse weinhold-about-style-{wert} durchgereicht, ohne eigene vordefinierte Styles im Framework – Platzhalter für zukünftige Varianten.

Versionshistorie

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

About Page

The About Page module provides a personal about-me page that can be embedded on any WordPress page via a shortcode. Bilingual content and custom styling are included.

General

Multilingual Support

Content can be maintained in both languages without creating a second page — if only one language is present, the toggle is automatically hidden. The language choice is remembered in the browser (localStorage) and kept in sync with the language choice on the rest of the framework’s pages (Blog List module), even though the About page implements its own toggle technically.

In Practice

On weinify.de, the weinhold_about shortcode is used for the personal introduction page. The module delivers a consistent design that matches the rest of the framework.

Shortcodes

Shortcode	Description
weinhold_about	Wrapper shortcode – wraps weinhold_about_de/_en, builds the language toggle and loads styles/JS
weinhold_about_de	German content, only inside weinhold_about
weinhold_about_en	English content, only inside weinhold_about
about_deutsch	Legacy alias for weinhold_about_de – already used in existing posts, use weinhold_about_de in new posts
about_englisch	Legacy alias for weinhold_about_en – use weinhold_about_en in new posts

Example: weinhold_about as the outer wrapper, containing one weinhold_about_de block with German content and one weinhold_about_en block with English content.

Files

modules/about_page.php – the module’s only file: shortcode registration, wrapper rendering, language toggle (inline CSS/JS), admin help page.

For Developers

How the Wrapper Works

weinhold_about_page_render_wrapper() resets a global scratch array ($weinhold_about_page_blocks) before rendering and calls do_shortcode() on the wrapped content. The inner shortcodes weinhold_about_de/_en only write their rendered content into this scratch array and return an empty string themselves — the actual HTML build (toggle plus both language blocks) happens afterward in the wrapper. If only one of the two languages is present, the toggle is omitted entirely.

Language Toggle

A small, self-contained inline-JS implementation (no shortcode nesting like the Blog List module): toggles the inactive language block’s visibility via CSS display and writes the choice to localStorage (key weinhold_lang) — the same key the Blog List module uses, keeping the language choice consistent across the site.

Special Cases

The admin help page (Weinhold → About Page) still only documents the legacy aliases about_deutsch/about_englisch as the example, not the canonical weinhold_about_de/_en tags — functionally identical, but the help page should show the canonical tags going forward.

The weinhold_about wrapper’s style parameter (style=“default“) is currently just passed through as a CSS class weinhold-about-style-{value}, with no predefined styles of its own in the framework yet — a placeholder for future variants.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

reactions

Reactions

Das Reactions-Modul ergänzt Analyse-Kommentare, WordPress-Blogbeiträge und WordPress-Kommentare um eine Like/Dislike-Funktion. Nur eingeloggte Nutzer können reagieren – so bleiben Reactions aussagekräftig und frei von Spam.

Allgemein

Funktionsweise

Unter jedem unterstützten Inhalt erscheinen zwei Schaltflächen – Daumen hoch und Daumen runter. Die Stimme wird per AJAX ohne Seitenreload übermittelt. Ein erneuter Klick auf die bereits aktive Reaktion entfernt sie wieder, ein Klick auf die jeweils andere wechselt die Reaktion. Die aktuelle Verteilung der Likes und Dislikes wird in Echtzeit angezeigt.

Wo Reactions erscheinen

Automatisch integriert, ohne separate Ein-/Ausschalter pro Bereich: unter Analyse-Kommentaren (wenn das Analyse-Modul sie rendert), am Ende jedes WordPress-Blogbeitrags („War dieser Beitrag hilfreich?“) sowie unter jedem WordPress-Kommentar – jeweils nur sichtbar für eingeloggte Nutzer.

Admin-Übersicht

Unter Weinhold → Reactions zeigt eine reine Auswertungsseite die Gesamtzahl an Likes/Dislikes sowie die zehn am meisten gelikten Inhalte mit direktem Link. Keine Einstellungen, nur Statistik.

Dateien

modules/reactions.php – einzige Datei des Moduls: Datenbank, AJAX-Handler, Rendering für alle drei Integrationspunkte, Admin-Auswertungsseite.

Für Entwickler

Datenbank

Spalte	Typ	Bedeutung
object_type	varchar(50)	analyse_comment, post oder wp_comment
object_id	bigint	ID des bewerteten Objekts
user_id	bigint	Wer reagiert hat
reaction	enum(‚like‘,’dislike‘)	Die Reaktion
created_at_gmt	datetime	Zeitstempel (UTC)

Unique-Key auf (object_type, object_id, user_id) – genau eine Reaktion pro Nutzer und Objekt, ein Wechsel überschreibt statt zu duplizieren.

Eigene Inhalte anbinden

Für einen neuen Inhaltstyp genügt ein Aufruf von weinhold_reactions_render($object_type, $object_id) an der gewünschten Stelle (per do_action(‚weinhold_reactions_render‘, $type, $id), wie es das Analyse-Modul für seine Kommentare tut) oder ein eigener Content-Filter analog zu weinhold_reactions_append_to_post(). weinhold_reactions_get_counts($object_type, $object_id) liefert Like-/Dislike-Zahlen sowie die eigene Reaktion des aktuell eingeloggten Nutzers.

AJAX

Einziger Endpunkt wp_ajax_weinhold_reaction_toggle (kein nopriv-Pendant – nicht eingeloggte Anfragen werden mit 403 abgelehnt). Erwartet object_type, object_id, reaction und einen Nonce.

Besonderheiten

Keine Konfigurationsmöglichkeit, wo Reactions erscheinen sollen – die drei Integrationspunkte (Analyse-Kommentare, Blogbeiträge, WP-Kommentare) sind fest im Code verdrahtet, nicht über Einstellungen abschaltbar.

object_type ist bewusst ein freier String statt eines festen Enums in der Anwendungslogik (die Datenbank erlaubt jeden Wert bis 50 Zeichen) – die AJAX-Validierung schränkt aktuell zwar auf analyse_comment/post/wp_comment ein, weitere Typen lassen sich aber ohne Schema-Änderung ergänzen.

the_content und the_excerpt werden beide gefiltert, damit Reactions sowohl auf Einzelbeitrags- als auch auf Übersichtsseiten erscheinen, je nachdem welche Funktion das aktive Theme nutzt.

Versionshistorie

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

Reactions

The Reactions module adds a like/dislike function to Analysis comments, WordPress blog posts, and WordPress comments. Only logged-in users can react — keeping reactions meaningful and spam-free.

General

How It Works

Two buttons — thumbs up and thumbs down — appear below each supported piece of content. The vote is submitted via AJAX without a page reload. Clicking the already-active reaction again removes it, clicking the other one switches the reaction. The current like/dislike distribution is shown in real time.

Where Reactions Appear

Automatically integrated, with no separate on/off switch per area: under Analysis comments (when the Analysis module renders them), at the end of every WordPress blog post („Was this post helpful?“), and under every WordPress comment — each visible only to logged-in users.

Admin Overview

Under Weinhold → Reactions, a pure reporting page shows the total number of likes/dislikes plus the ten most-liked pieces of content with a direct link. No settings, just statistics.

Files

modules/reactions.php – the module’s only file: database, AJAX handler, rendering for all three integration points, admin reporting page.

For Developers

Database

Column	Type	Meaning
object_type	varchar(50)	analyse_comment, post, or wp_comment
object_id	bigint	ID of the rated object
user_id	bigint	Who reacted
reaction	enum(‚like‘,’dislike‘)	The reaction
created_at_gmt	datetime	Timestamp (UTC)

Unique key on (object_type, object_id, user_id) — exactly one reaction per user and object, switching overwrites instead of duplicating.

Hooking Up Your Own Content

To support a new content type, call weinhold_reactions_render($object_type, $object_id) at the desired spot (via do_action(‚weinhold_reactions_render‘, $type, $id), as the Analysis module does for its comments) or add your own content filter modeled on weinhold_reactions_append_to_post(). weinhold_reactions_get_counts($object_type, $object_id) returns the like/dislike counts plus the current logged-in user’s own reaction.

AJAX

Single endpoint wp_ajax_weinhold_reaction_toggle (no nopriv counterpart — logged-out requests are rejected with 403). Expects object_type, object_id, reaction, and a nonce.

Special Cases

No configuration option for where reactions should appear — the three integration points (Analysis comments, blog posts, WP comments) are hard-wired in code, not toggleable via settings.

object_type is deliberately a free string rather than a fixed enum in the application logic (the database column allows any value up to 50 characters) — AJAX validation currently restricts it to analyse_comment/post/wp_comment, but further types can be added without a schema change.

Both the_content and the_excerpt are filtered, so reactions appear on both single-post and archive/listing pages, depending on which function the active theme uses.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

subsite-404-redirect

404-Weiterleitung

Das Subsite-404-Redirect-Modul ersetzt die Standard-WordPress-404-Seite durch eine saubere Weiterleitung auf ein konfigurierbares Ziel. Statt einer nackten Fehlerseite landen Besucher bei einem Tippfehler in der URL auf der Startseite, einer bestimmten Seite oder einer frei angegebenen URL.

Allgemein

Konfiguration

Das Weiterleitungsziel wird pro Subsite im Dashboard unter Weinhold → 404 Redirect definiert – zur Wahl stehen die Startseite, eine bestimmte WordPress-Seite aus einer Auswahlliste, oder eine frei eingegebene URL. Zusätzlich lässt sich zwischen temporärer (302) und dauerhafter (301) Weiterleitung wählen, und ob eingeloggte Nutzer sowie Administratoren ebenfalls umgeleitet werden sollen (Admins standardmäßig ausgenommen, zum Debuggen).

Ausnahmepfade

Eigene Pfade (einer pro Zeile, z. B. api/webhook) lassen sich von der Weiterleitung ausnehmen. Technische WordPress-Pfade (wp-json, wp-login.php, wp-cron.php, xmlrpc.php, robots.txt, favicon.ico, Feeds) sowie AJAX- und REST-Requests sind fest eingebaut immer ausgenommen.

Pro Site

Da jede Subsite im Netzwerk unterschiedliche Inhalte und Strukturen haben kann, ist die Konfiguration bewusst pro Site getrennt. Eine öffentliche Seite kann z. B. auf die Startseite weiterleiten, während eine interne Site auf die Login-Seite umleitet. Subsites ohne aktivierte Konfiguration behalten die Standard-WordPress-404-Seite.

Dateien

modules/subsite_404_redirect.php – einzige Datei des Moduls: Weiterleitungslogik, Einstellungen, Admin-Seite, Cleanup.

Für Entwickler

Einstellungen (Option weinhold_subsite_404_redirect_settings)

Schlüssel	Bedeutung
target_mode	home, page oder custom_url
target_page_id	Ziel-Seiten-ID bei target_mode=page
target_custom_url	Ziel-URL bei target_mode=custom_url
status_code	301 oder 302
apply_for_logged_in	Auch eingeloggte Nutzer umleiten
allow_admin_debug	Administratoren von der Weiterleitung ausnehmen
append_from404	Hängt from404=1 und den fehlenden Pfad als missing-Parameter an die Ziel-URL an
exception_custom_paths	Zusätzliche, frei definierte Ausnahmepfade

Ablauf

Hängt an template_redirect und greift nur bei echten 404-Antworten außerhalb des Admin-Bereichs. Reihenfolge der Prüfungen: aktiver Wartungsmodus bricht sofort ab, dann Modul aktiv?, dann technische/Ausnahmepfade, dann Admin-Debug-Ausnahme, dann eingeloggte Nutzer, dann eigene Ausnahmepfade. Zeigt die aufgelöste Ziel-URL zufällig auf den aktuellen (404-)Pfad, wird ebenfalls nicht umgeleitet – verhindert eine Weiterleitung auf sich selbst.

Besonderheiten

Wartungsmodus hat Vorrang: Ist das Wartungsmodus-Modul aktiv, greift die 404-Weiterleitung gar nicht erst – die eigene Weiterleitung des Wartungsmodus soll nicht überschrieben werden.

REST- und AJAX-Requests sind immer ausgenommen, auch ohne manuelle Konfiguration – ein 404 innerhalb der REST-API soll als echter API-Fehler beim aufrufenden System ankommen, nicht als HTML-Weiterleitung.

Beim Modul-Reset werden zusätzlich mehrere Legacy-Optionen früherer Versionen entfernt (enabled/target/status/exceptions/exception_page_ids einzeln) – Überbleibsel, bevor die Einstellungen in ein einziges Array zusammengeführt wurden.

Versionshistorie

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

404 Redirect

The Subsite 404 Redirect module replaces the default WordPress 404 page with a clean redirect to a configurable destination. Instead of a bare error page, visitors with a typo in the URL land on the homepage, a specific page, or a freely entered URL.

General

Configuration

The redirect destination is defined per subsite in the dashboard under Weinhold → 404 Redirect — options are the homepage, a specific WordPress page from a dropdown, or a freely entered URL. You can also choose between a temporary (302) and a permanent (301) redirect, and whether logged-in users and administrators should also be redirected (admins excluded by default, for debugging).

Exception Paths

Custom paths (one per line, e.g. api/webhook) can be excluded from the redirect. Technical WordPress paths (wp-json, wp-login.php, wp-cron.php, xmlrpc.php, robots.txt, favicon.ico, feeds) as well as AJAX and REST requests are always excluded, built in.

Per Site

Since each subsite in the network can have different content and structure, the configuration is intentionally separated per site. A public site can redirect to the homepage, while an internal site redirects to the login page. Subsites without an enabled configuration keep the default WordPress 404 page.

Files

modules/subsite_404_redirect.php – the module’s only file: redirect logic, settings, admin page, cleanup.

For Developers

Settings (Option weinhold_subsite_404_redirect_settings)

Key	Meaning
target_mode	home, page, or custom_url
target_page_id	Target page ID when target_mode=page
target_custom_url	Target URL when target_mode=custom_url
status_code	301 or 302
apply_for_logged_in	Also redirect logged-in users
allow_admin_debug	Exempt administrators from the redirect
append_from404	Appends from404=1 and the missing path as a missing parameter to the target URL
exception_custom_paths	Additional, freely defined exception paths

Flow

Hooks into template_redirect and only applies on genuine 404 responses outside the admin area. Order of checks: active maintenance mode aborts immediately, then whether the module is enabled, then technical/exception paths, then the admin debug exemption, then logged-in users, then custom exception paths. If the resolved target URL happens to match the current (404) path, no redirect happens either — prevents redirecting to itself.

Special Cases

Maintenance mode takes precedence: if the maintenance mode module is active, the 404 redirect doesn’t apply at all — its own redirect shouldn’t be overridden.

REST and AJAX requests are always excluded, even without manual configuration — a 404 within the REST API should reach the calling system as a genuine API error, not as an HTML redirect.

On module reset, several legacy options from earlier versions are additionally removed (enabled/target/status/exceptions/exception_page_ids individually) — leftovers from before the settings were merged into a single array.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

maintenance-mode

Wartungsmodus

Das Maintenance-Mode-Modul versetzt eine Subsite in den Wartungsmodus. Besucher werden auf eine automatisch erstellte, konfigurierbare Wartungsseite weitergeleitet – Administratoren sehen standardmäßig weiterhin die normale Seite und können ungestört weiterarbeiten.

Allgemein

Zeitplan

Der Wartungsmodus kann mit einem optionalen Start- und Endzeitpunkt versehen werden. Vor dem Start bleibt die Seite trotz aktivierter Checkbox normal erreichbar, nach dem Endzeitpunkt schaltet sich der Wartungsmodus beim nächsten Seitenaufruf automatisch selbst wieder aus.

Ausnahmen

Bestimmte WordPress-Seiten (per Checkliste) oder frei eingegebene Pfade können vom Wartungsmodus ausgenommen werden – z. B. eine Kontaktseite oder ein Webhook-Endpunkt, der weiterhin erreichbar bleiben muss. Zusätzlich lässt sich per Checkbox erlauben, dass alle eingeloggten Nutzer die Seite normal sehen (nicht nur Administratoren, die ohnehin immer durchgelassen werden).

Vorschau & Test

Ein spezieller Vorschau-Link (?weinhold_maintenance_preview=1) erzwingt den Wartungsmodus nur für den eigenen Aufruf, ohne ihn für alle anderen Besucher zu aktivieren – zum schnellen Gegencheck der Wartungsseite.

Konfiguration

Alles wird im Dashboard unter Weinhold → Maintenance Mode konfiguriert. Kein Shortcode nötig – das Modul arbeitet vollständig automatisch.

Dateien

modules/maintenance_mode.php – einzige Datei des Moduls: Einstellungen, Wartungsseiten-Erzeugung/-Pflege, Weiterleitungslogik, Admin-Oberfläche, Cleanup.

Für Entwickler

Wartungsseite als echte WordPress-Seite

Bei der ersten Aktivierung wird automatisch eine normale WordPress-Seite mit dem Slug maintenance-mode angelegt (weinhold_create_maintenance_page()), deren Inhalt aus den konfigurierten Zeitfenster- und Beschreibungstexten zusammengesetzt wird. Bei jeder Einstellungsänderung wird ihr Inhalt aktualisiert (weinhold_update_maintenance_page()). Beim Deaktivieren wird die Seite bewusst NICHT gelöscht, sondern bleibt erhalten (eigener Löschen-Button in der Admin-Oberfläche für den expliziten Fall).

Ablauf

Hängt an template_redirect. Reihenfolge: Ist das Endzeitfenster bereits erreicht, wird der Wartungsmodus automatisch deaktiviert und die Funktion bricht ab. Dann werden Systempfade (Admin, AJAX, REST, XML-RPC, Cron sowie fest ausgenommene technische Pfade wie wp-login.php, wp-json, robots.txt) immer durchgelassen. Danach greift die Admin-Ausnahme, die allow_logged_in-Ausnahme und zuletzt die konfigurierten Ausnahmepfade. Bleibt keine Ausnahme übrig, liefert die Wartungsseite selbst HTTP 503 mit Retry-After-Header, alle anderen URLs werden per 302 dorthin weitergeleitet.

Einstellungen (Option weinhold_maintenance_mode_settings)

Schlüssel	Bedeutung
enabled	Wartungsmodus aktiv
allow_logged_in	Alle eingeloggten Nutzer zusätzlich zu Administratoren durchlassen
start_date,end_date	Optionales Zeitfenster
description	Freitext, der auf der Wartungsseite erscheint
page_id	ID der automatisch erzeugten Wartungsseite
exception_page_ids,exception_custom_paths	Ausgenommene Seiten bzw. frei eingegebene Pfade

Besonderheiten

Weder IP-basierte noch rollenbasierte Ausnahmen vorhanden – Bypass funktioniert ausschließlich über Administratorrechte, die allow_logged_in-Option (alle eingeloggten Nutzer pauschal) und Pfad-Ausnahmen. Eine feingranulare Steuerung nach Rolle oder IP-Adresse gibt es nicht.

HTTP-Statuscode ist korrekt 503 (nicht 200 oder 302) mit Retry-After-Header, wenn die Wartungsseite direkt aufgerufen wird – wichtig für Suchmaschinen, damit die Seite währenddessen nicht aus dem Index fällt. Bei allen anderen URLs erfolgt dagegen ein 302-Redirect zur Wartungsseite.

Das andere 404-Weiterleitungs- und das Login-Redirect-Modul prüfen jeweils selbst, ob der Wartungsmodus aktiv ist, und greifen dann nicht ein – die Module sind bewusst so verzahnt, dass Wartungsmodus stets Vorrang hat.

Versionshistorie

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

Maintenance Mode

The Maintenance Mode module puts a subsite into maintenance mode. Visitors are redirected to an automatically created, configurable maintenance page — administrators continue to see the normal site by default and can work undisturbed.

General

Schedule

Maintenance mode can be given an optional start and end time. Before the start, the site remains normally reachable despite the checkbox being enabled; after the end time, maintenance mode automatically switches itself off again on the next page load.

Exceptions

Specific WordPress pages (via a checklist) or freely entered paths can be excluded from maintenance mode — e.g. a contact page or a webhook endpoint that must remain reachable. You can additionally allow all logged-in users to see the site normally via a checkbox (not just administrators, who always get through regardless).

Preview & Testing

A special preview link (?weinhold_maintenance_preview=1) forces maintenance mode only for your own request, without activating it for all other visitors — for a quick check of the maintenance page.

Configuration

Everything is configured in the dashboard under Weinhold → Maintenance Mode. No shortcode needed — the module works fully automatically.

Files

modules/maintenance_mode.php – the module’s only file: settings, maintenance page creation/updates, redirect logic, admin UI, cleanup.

For Developers

The Maintenance Page Is a Real WordPress Page

On first activation, a normal WordPress page with the slug maintenance-mode is automatically created (weinhold_create_maintenance_page()), its content assembled from the configured time window and description text. On every settings change, its content is updated (weinhold_update_maintenance_page()). On deactivation, the page is deliberately NOT deleted, it’s kept around (a separate delete button in the admin UI covers the explicit case).

Flow

Hooks into template_redirect. Order: if the end time window has already passed, maintenance mode is automatically disabled and the function returns. Then system paths (admin, AJAX, REST, XML-RPC, cron, plus fixed technical paths like wp-login.php, wp-json, robots.txt) are always let through. Next comes the admin exception, the allow_logged_in exception, and finally the configured exception paths. If none apply, the maintenance page itself returns HTTP 503 with a Retry-After header; all other URLs are redirected there via 302.

Settings (Option weinhold_maintenance_mode_settings)

Key	Meaning
enabled	Maintenance mode active
allow_logged_in	Let all logged-in users through in addition to administrators
start_date,end_date	Optional time window
description	Free text shown on the maintenance page
page_id	ID of the automatically created maintenance page
exception_page_ids,exception_custom_paths	Excluded pages or freely entered paths

Special Cases

No IP-based or role-based exceptions exist — bypass works purely through administrator rights, the allow_logged_in option (all logged-in users at once), and path exceptions. There’s no fine-grained control by role or IP address.

The HTTP status code is correctly 503 (not 200 or 302) with a Retry-After header when the maintenance page itself is requested directly — important for search engines, so the site doesn’t fall out of the index in the meantime. All other URLs instead get a 302 redirect to the maintenance page.

The 404-redirect and login-redirect modules each check themselves whether maintenance mode is active and back off if so — the modules are deliberately interlocked so maintenance mode always takes precedence.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

login-redirect

Login Redirect

Das Login-Redirect-Modul leitet nicht eingeloggte Besucher automatisch zur Login-Seite weiter. So lässt sich der Zugang zu einer gesamten Subsite auf eingeloggte Nutzer beschränken – ohne komplizierte WordPress-Rollen-Konfiguration.

Allgemein

Ausnahmen definieren

Bestimmte Seiten werden von der Weiterleitung ausgenommen – mindestens die Login-Seite selbst. Weitere Ausnahmen (z. B. Impressum, Startseite, Datenschutzerklärung) können im Dashboard unter Weinhold → Login Redirect als Liste angekreuzt werden – dort erscheinen automatisch alle vorhandenen WordPress-Seiten der Site.

In der Praxis

Auf privaten Subsites im Weinhold-Netzwerk – etwa Community-Bereichen oder internen Projekten – sorgt dieses Modul dafür, dass Inhalte wirklich nur für Mitglieder sichtbar sind. Kein Shortcode, keine Anpassungen pro Seite nötig.

Dateien

modules/login_redirect.php – einzige Datei des Moduls: Weiterleitungslogik, Admin-Einstellungsseite, Cleanup.

Für Entwickler

Weiterleitungslogik

Hängt an template_redirect und greift nur, wenn der Besucher weder eingeloggt noch im Admin-Bereich ist. Die Ziel-URL kommt aus der zentral im Benutzerverwaltung-Modul konfigurierten Login-Seite (weinhold_user_management_get_auth_page_url()); ist dort keine Seite hinterlegt, dient /login/ als Fallback. Das aktuelle Ziel wird per redirect_to-Parameter an die Login-Seite angehängt (über weinhold_user_management_add_redirect_to_url(), damit derselbe Open-Redirect-Schutz wie im Benutzerverwaltung-Modul greift).

Schutz vor Redirect-Schleifen

Zwei unabhängige Sperren verhindern eine Endlosschleife: Erstens wird nicht weitergeleitet, wenn der aktuelle Pfad bereits die Login-, Registrierungs- oder Passwort-vergessen-Seite ist. Zweitens wird nicht weitergeleitet, wenn die Anfrage bereits einen redirect_to- oder redirect_url-Parameter enthält (dann läuft man vermutlich schon in einem Auth-Flow).

Zusätzlich greift das Modul gar nicht erst, wenn der Wartungsmodus aktiv ist (weinhold_maintenance_mode_settings) – dessen eigene Umleitung hat Vorrang.

Speicherung

Ausnahmeliste in der Option weinhold_login_redirect_exceptions (Array aus Seiten-Slugs, die Startseite als leerer String). Gecheckt über weinhold_path_matches_exceptions() aus den Framework-Helpern.

Besonderheiten

Betrifft nur das Frontend einer einzelnen Site (Module Scope: site) – jede Subsite konfiguriert ihre Ausnahmeliste unabhängig, es gibt keine netzwerkweite Einstellung.

allowed_redirect_hosts wird um alle Domains des Multisite-Netzwerks erweitert (gleicher Mechanismus wie im Benutzerverwaltung-Modul), damit wp_safe_redirect() auch netzwerkinterne Ziele akzeptiert.

Beim Modul-Reset werden zusätzlich mehrere Legacy-Optionen aus früheren Versionen entfernt (page_id/blog_id/site_id/login_url) – Überbleibsel einer älteren Implementierung, die die Login-Seite noch selbst verwaltete statt sie vom Benutzerverwaltung-Modul zu beziehen.

Versionshistorie

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

Login Redirect

The Login Redirect module automatically redirects unauthenticated visitors to the login page. This restricts access to an entire subsite to logged-in users — without complex WordPress role configuration.

General

Defining Exceptions

Specific pages are excluded from the redirect — at minimum the login page itself. Additional exceptions (e.g. imprint, homepage, privacy policy) can be checked off as a list in the dashboard under Weinhold → Login Redirect, which automatically shows every existing WordPress page on the site.

In Practice

On private subsites in the Weinhold network — such as community areas or internal projects — this module ensures that content is truly only visible to members. No shortcode, no per-page adjustments needed.

Files

modules/login_redirect.php – the module’s only file: redirect logic, admin settings page, cleanup.

For Developers

Redirect Logic

Hooks into template_redirect and only applies if the visitor is neither logged in nor in the admin area. The target URL comes from the login page centrally configured in the User Management module (weinhold_user_management_get_auth_page_url()); if none is set there, /login/ is used as a fallback. The current target is appended to the login page via a redirect_to parameter (through weinhold_user_management_add_redirect_to_url(), so the same open-redirect protection as in the User Management module applies).

Redirect Loop Protection

Two independent checks prevent an infinite loop: first, no redirect happens if the current path is already the login, registration, or lost-password page. Second, no redirect happens if the request already contains a redirect_to or redirect_url parameter (in that case you’re presumably already inside an auth flow).

The module also doesn’t apply at all while maintenance mode is active (weinhold_maintenance_mode_settings) — its own redirect takes precedence.

Storage

Exception list in the option weinhold_login_redirect_exceptions (array of page slugs, the homepage as an empty string). Checked via weinhold_path_matches_exceptions() from the framework helpers.

Special Cases

Affects only the frontend of a single site (Module Scope: site) — each subsite configures its exception list independently, there’s no network-wide setting.

allowed_redirect_hosts is extended with all domains of the Multisite network (same mechanism as in the User Management module), so wp_safe_redirect() also accepts network-internal targets.

On module reset, several legacy options from earlier versions are additionally removed (page_id/blog_id/site_id/login_url) — leftovers from an older implementation that used to manage the login page itself instead of sourcing it from the User Management module.

Version History

Version Date Change
1.0.0 22.09.2026 Introduction of versioning.

10. Juni 2026

cookie-consent

Cookie Consent

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

Allgemein

Einwilligungskategorien

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

Seitenspezifische Texte

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

Datenschutz- & Impressum-Links

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

Erneut öffnen

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

Shortcodes

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

Dateien

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

Für Entwickler

Übergabe an das Frontend

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

Einstellungen (Option weinhold_cookie_consent_settings, pro Site)

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

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

Besonderheiten

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

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

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

Versionshistorie

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

Cookie Consent

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

General

Consent Categories

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

Page-Specific Texts

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

Privacy & Imprint Links

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

Reopening It

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

Shortcodes

Shortcode	Description
weinhold_cookie_settings	Button that reopens the cookie settings panel

Files

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

For Developers

Handoff to the Frontend

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

Settings (Option weinhold_cookie_consent_settings, per site)

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

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

Special Cases

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

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

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

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026

custom-footer

Custom Footer

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

Allgemein

Buttons & Drag and Drop

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

Freies HTML

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

Pro Site, kein Shortcode

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

Dateien

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

Für Entwickler

Gemeinsamer Unterbau mit Custom Header

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

Speicherung (Optionen pro Site)

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

Wichtige Funktionen

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

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

Besonderheiten

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

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

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

Versionshistorie

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

Custom Footer

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

General

Buttons & Drag and Drop

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

Free HTML

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

Per Site, No Shortcode

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

Files

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

For Developers

Shared Foundation with Custom Header

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

Storage (Per-Site Options)

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

Key Functions

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

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

Special Cases

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

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

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

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

10. Juni 2026