Schlagwort: modul

  • charakterboegen


    Charakterbögen

    PPNP – Welten, Trainer, Pyxlinge

    Das Charakterbögen-Modul verwaltet und zeigt Charakterbögen für das Pen-&-Paper-Rollenspiel PPNP („Pen, Paper and Pyxlinge“, inspiriert von Pokémon) als strukturiertes Frontend. Es bildet die vollständige Datenhierarchie ab: Welten enthalten Trainer, Trainer besitzen Pyxlinge.

    Shortcode

    [[weinhold_character_sheets]] – Rendert die komplette Charakterbögen-Übersicht auf einer WordPress-Seite. Die Darstellung ist für Desktop und Mobilgeräte optimiert.

    Datenverwaltung

    Welten, Trainer und Pyxlinge werden über das Admin-Dashboard gepflegt. Jede Entität kann mit eigenen Eigenschaften, Bildern und Werten versehen werden. Die Daten werden in einer eigenen Datenbankstruktur gespeichert – völlig unabhängig von WordPress-Beiträgen.

    Pro Site

    Das Modul ist pro Subsite konfiguriert. Verschiedene Subsites können unterschiedliche Welten und Kampagnen verwalten, ohne sich gegenseitig zu beeinflussen.

    Versionshistorie

    1.0.1 – 28.10.2026 – Rebranding: Hub-Untertitel nennt Pyxlinge statt Pokémon.

    1.0.0 – 22.09.2026 – Einführung der Versionierung.

  • 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

    ShortcodeBeschreibung
    weinhold_family_ordersRendert 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


    TabelleSpalten(Auswahl)
    weinhold_family_orderstitle, description, shop_url, status(open/closed), deadline_gmt, notify_user_ids, launch_mail_sent, reminder_mail_sent, closed_mail_sent
    weinhold_family_order_itemsorder_id, name, item_url, sort_order
    weinhold_family_order_entriesorder_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


    FunktionWannEmpfänger
    weinhold_family_orders_send_launch_mail($order_id)BeiErstellung Konfigurierte notify_user_ids
    weinhold_family_orders_send_reminder_mail($order)Fristin unter 7 Tagen notify_user_ids PLUS alle, die bereits eine Menge eingetragen haben
    weinhold_family_orders_send_closed_summary_mail($order_id)Fristerreicht 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

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.


  • 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

    ShortcodeBeschreibung
    weinhold_analyseRendert 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


    TabelleSpalten(Auswahl)
    weinhold_analyse_entriescreator_user_id, caption, description, video_url, content_type, site_id
    weinhold_analyse_commentsentry_id, user_id, comment_text
    weinhold_analyse_favoritesentry_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


    FunktionBeschreibung
    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

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.


  • 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

    ShortcodeBeschreibung
    weinhold_wishlistRendert 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


    TabelleSpalten(Auswahl)
    weinhold_wishlistsowner_user_id, title, caption, description, reveal_at_gmt
    weinhold_wishlist_itemswishlist_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


    FunktionBeschreibung
    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

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.


  • 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

    ShortcodeBeschreibung
    weinhold_aboutWrapper-Shortcode – umschließt weinhold_about_de/_en, baut den Sprachumschalter und lädt Styles/JS
    weinhold_about_deDeutscher Inhalt, nur innerhalb von weinhold_about
    weinhold_about_enEnglischer Inhalt, nur innerhalb von weinhold_about
    about_deutschLegacy-Alias für weinhold_about_de – bereits in bestehenden Beiträgen im Einsatz, in neuen Beiträgen weinhold_about_de verwenden
    about_englischLegacy-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

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.


  • 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


    SpalteTypBedeutung
    object_typevarchar(50)analyse_comment, post oder wp_comment
    object_idbigintID des bewerteten Objekts
    user_idbigintWer reagiert hat
    reactionenum(‚like‘,’dislike‘)Die Reaktion
    created_at_gmtdatetimeZeitstempel (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

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.


  • blog-list


    Blog-Listen


    Das Blog-List-Modul ist die Grundlage für mehrsprachige Modul- und Server-Dokumentation im ganzen Weinhold-Framework – inklusive der Übersichtsseite, auf der du diesen Beitrag gefunden hast, und der Struktur, in der dieser Beitrag selbst geschrieben ist.

    Allgemein

    Diese Seite nutzt dieses Modul


    Die Übersicht auf weinify.de/module ist selbst mit dem Blog-List-Modul gebaut. Der Shortcode weinify_blog_list mit den Parametern tag, style, orderby und order rendert dort die Kachel-Übersicht aller Modul-Beiträge.

    Zwei Formate


    Für kurze Übersichtsseiten gibt es das einfache wf_de/wf_en-Format mit frei eingegebenem HTML. Für ausführliche Doku-Beiträge (wie diesen hier) gibt es das strukturierte weinhold_blog_list_de/weinhold_blog_list_en-Format mit benannten, einklappbaren Sektionen, automatischem Inhaltsverzeichnis und Entwickler-Tabellen. Beide Formate unterstützen denselben DE/EN-Umschalter.

    Core-Hervorhebung


    Posts mit dem Schlagwort core, wichtig oder benötigt werden in Listen-Ansichten automatisch nach oben sortiert und mit einem dezenten „Core“-Label hervorgehoben.

    Tag-Übersetzungen & Icons


    Unter Weinhold → Blog List → Tag-Übersetzungen & Icons lässt sich pro Schlagwort eine englische Übersetzung und ein Icon hinterlegen, die automatisch in der Badge-Anzeige (weinhold_blog_list_meta) und im englischen Sprachblock verwendet werden.

    Shortcodes

    ShortcodeBeschreibung
    weinify_blog_listRendert eine gefilterte Kachel-/Listen-Übersicht. Attribute: tag, style (cards/showcase/timeline/list), limit (Standard 9), orderby (title/date/menu_order), order (ASC/DESC), pin_core (1/0, Standard 1)
    weinhold_blog_list_de,weinhold_blog_list_enDeutscher bzw. englischer Inhaltsblock im strukturierten Format. Sind beide vorhanden, erscheint automatisch ein Umschalter
    weinhold_blog_list_captionKurzbeschreibung, wird als Seitenüberschrift und als Kartentitel in Listen-Ansichten verwendet
    weinhold_blog_list_metaZeigt alle Schlagwörter des Posts als Badges (ohne rein strukturelle Tags wie modul/weinhold-framework)
    weinhold_blog_list_sectionBenannte, einklappbare Sektion, erzeugt automatisch einen Eintrag im Inhaltsverzeichnis
    weinhold_blog_list_h2Zwischenüberschrift innerhalb einer Sektion
    weinhold_blog_list_devtableEntwickler-Tabelle aus einfachem, spaltengetrenntem Text
    weinhold_blog_list_collapseFrei benannter, einklappbarer Textblock ohne Inhaltsverzeichnis-Eintrag
    wf_de,wf_en,wf_caption,wf_h2,wf_devtable,wf_collapseLegacy-Kurzformen für das einfache Format bzw. Alias-Namen der obigen Shortcodes – in neuem Inhalt die kanonischen weinhold_blog_list_*-Namen verwenden

    Dateien

    modules/blog_list.php – einzige Datei des Moduls: alle Shortcode-Renderer, Sprachumschalter- und Inhaltsverzeichnis-JS, Tag-Metadaten-Verwaltung, Caption-Speicherung, Zurück-Button-Injektion.

    Für Entwickler

    Wie Devtables geparst werden


    Erste Zeile ist die Kopfzeile, sie bestimmt die Spaltenanzahl. Danach wird jede Zeile in Leerzeichen-getrennte Tokens zerlegt; die ersten N-1 Spalten bekommen je ein Token zugewiesen, die letzte Spalte nimmt den kompletten Rest der Zeile. Endet ein Token mit einem Komma oder enthält es eine offene runde Klammer, läuft die Spalte über das nächste Leerzeichen hinaus weiter (z. B. bleibt „bigint, Auto-Increment“ oder „weinhold_…_get_rows( array $filters, …“ trotz enthaltener Leerzeichen und Kommas in einer Spalte). Seit 2026-09-22 wird daraus ein echtes HTML-table-Element gerendert (vorher nur Text mit br-Umbrüchen).

    Inhaltsverzeichnis & Sprachumschalter


    Beides läuft rein im Frontend-JS (weinhold_blog_list_inline_js()): buildTocs() sammelt alle Sektionen mit data-toc-title im aktuellen Scope und baut daraus automatisch eine Navigation samt „Alle auf-/zuklappen“-Button, initLangToggles() blendet je nach gewählter Sprache den passenden Block ein/aus und merkt die Wahl in localStorage unter dem Schlüssel weinhold_lang.

    Naming-Fix: wf_* vs. weinhold_blog_list_*


    Die kanonischen Shortcode-Namen sind weinhold_blog_list_*, die kürzeren wf_*-Namen existieren nur noch als Alias für bereits veröffentlichte, ältere Beiträge. In neuem Doku-Inhalt immer die langen Namen verwenden.

    Besonderheiten

    weinhold_blog_list_meta zeigt bewusst nicht zwischen „Kategorie“, „Geltungsbereich“ oder „Core“ unterschiedene Badges – im Code sind das alles einfach Tags wie jeder andere auch. Nur rein strukturelle, nicht unterscheidende Tags (modul, weinhold-framework, wichtig, benötigt) werden herausgefiltert.

    Shortcodes innerhalb von weinhold_blog_list_collapse werden nicht per do_shortcode() aufgelöst – ein Shortcode wie eine Server-Einbettung darf deshalb nie in einem Collapse-Block stehen, sondern muss direkt auf Beitragsebene, außerhalb aller weinhold_blog_list_*-Wrapper platziert werden.

    Der Zurück-Button am Ende jedes Beitrags sowie das Zuklappen/Aufklappen-Verhalten der Sektionen werden über den the_content-Filter automatisch injiziert – Autoren müssen dafür nichts zusätzlich in den Beitrag schreiben.

    Versionshistorie

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.


  • 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üsselBedeutung
    target_modehome, page oder custom_url
    target_page_idZiel-Seiten-ID bei target_mode=page
    target_custom_urlZiel-URL bei target_mode=custom_url
    status_code301 oder 302
    apply_for_logged_inAuch eingeloggte Nutzer umleiten
    allow_admin_debugAdministratoren von der Weiterleitung ausnehmen
    append_from404Hängt from404=1 und den fehlenden Pfad als missing-Parameter an die Ziel-URL an
    exception_custom_pathsZusä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

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.


  • 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üsselBedeutung
    enabledWartungsmodus aktiv
    allow_logged_inAlle eingeloggten Nutzer zusätzlich zu Administratoren durchlassen
    start_date,end_dateOptionales Zeitfenster
    descriptionFreitext, der auf der Wartungsseite erscheint
    page_idID der automatisch erzeugten Wartungsseite
    exception_page_ids,exception_custom_pathsAusgenommene 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

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.


  • 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

    VersionDatumÄnderung
    1.0.022.09.2026Einführung der Versionierung.