WBCE CMS Forum

Slugger

Developer

Snippet-Modul Dokumentation - Fehlende/Irreführende Hinweise

Snippet-Modul Dokumentation - Fehlende und irreführende Hinweise

Mein KI Claude meinte wir sollten etwas dazu schreiben.

Bei der Entwicklung eines Hybrid-Moduls (tool, snippet) sind wir auf mehrere undokumentierte Verhaltensweisen gestossen, die tagelange Fehlersuche verursacht haben. Ziel dieses Posts: Die Community und das WBCE-Team informieren, damit die Dokumentation verbessert werden kann.

Testumgebung

WBCE Version: 1.6.5
PHP: 8.1
Modul: mod_consent (DSGVO Cookie-Consent, Hybrid: tool + snippet)

Problem 1: ADMIN_URL ist kein Frontend-Guard

Quelle: Gaengige Praxis in aelteren Modulen, auch in einigen Beispielen zu finden.

Annahme: Der folgende Guard soll include.php vor Ausfuehrung im Backend schuetzen:

if (defined('ADMIN_URL')) { return; }

Realitaet: ADMIN_URL wird in /framework/initialize.php fuer ALLE Kontexte definiert, also auch im Frontend. Der Guard greift daher immer und verhindert jede Ausfuehrung der include.php.

Korrekter Guard:

if (!defined('WB_FRONTEND') || WB_FRONTEND !== true) { return; }

WB_FRONTEND wird nur in /framework/frontend.functions.php gesetzt und ist damit der einzig zuverlaessige Frontend-Indikator.

Empfehlung fuer die Doku: Explizit auf WB_FRONTEND als korrekten Guard hinweisen und ADMIN_URL als Guard ausdruecklich als falsch kennzeichnen.

Problem 2: echo in include.php landet nach dem schliessenden HTML-Tag

Quelle: https://help.wbce.org/pages/de/module-p … ippets.php

Die Doku sagt: "include.php: Wird automatisch beim Aufruf der Seiten im Frontend geladen."

Realitaet: Der Output von include.php landet in der Variable $sPreOutput und wird mit

$sContent = $sContent . $sPreOutput;

ans Ende des fertigen HTML angehaengt, also nach dem schliessenden HTML-Tag. Der genaue Ablauf in /index.php:

require WB_PATH . '/framework/frontend.functions.php';
$sPreOutput = ob_get_clean();
ob_start();
require TEMPLATE/index.php;
$sContent = ob_get_clean();
$sContent = $sContent . $sPreOutput;
$sContent = opf_controller('page', $sContent);

Folge: Direktes echo von HTML funktioniert zwar, weil Browser tolerant sind. Aber CSS und JS landen ausserhalb von head bzw. body und werden nicht korrekt verarbeitet.

Loesung: Die Insert-Klasse verwenden:

I::insertCssFile($url, 'HEAD BTM-');
I::insertJsFile($url, 'BODY BTM-');
I::insertHtmlCode($html, 'BODY BTM-');

Wichtig: Der OPF-Filter "Class Insert Helper" muss aktiv sein, damit die Insert-Klasse funktioniert.

Empfehlung fuer die Doku: Auf das $sPreOutput-Verhalten hinweisen, die Insert-Klasse als empfohlenen Weg dokumentieren und den Hinweis ergaenzen, dass der OPF-Filter "Class Insert Helper" aktiv sein muss.

Problem 3: Hybrid-Modul mit UPDATE in install.php

Manche aeltere Beispiele enthalten in install.php folgenden Code:

$database->query("UPDATE `{TP}addons` SET `function` = 'tool, snippet' ...");

Dieses UPDATE schlaegt bei Neuinstallation fehl, weil WBCE den Datensatz in der addons-Tabelle erst nach Ausfuehrung von install.php schreibt. Das UPDATE greift ins Leere.

Loesung: Kein UPDATE noetig. WBCE liest $module_function direkt aus info.php und schreibt es selbst in die addons-Tabelle.

Empfehlung fuer die Doku: Darauf hinweisen, dass ein manuelles UPDATE der addons-Tabelle in install.php nicht funktioniert und nicht benoetigt wird.

Referenz: Funktionierende include.php als Minimal-Vorlage

defined('WB_PATH') or die('Direct access not allowed.');

// Nur im Frontend ausfuehren
if (!defined('WB_FRONTEND') || WB_FRONTEND !== true) { return; }

// Tabellen-Check bei fehlgeschlagener Installation
$tbl = $database->query("SHOW TABLES LIKE '" . TABLE_PREFIX . "mein_modul'")->fetchRow();
if (!$tbl) { return; }

// CSS in den head-Bereich
I::insertCssFile(WB_URL . '/modules/mein_modul/css/style.css', 'HEAD BTM-');

// HTML ans Body-Ende
ob_start();
require WB_PATH . '/modules/mein_modul/frontend/output.php';
$html = ob_get_clean();
I::insertHtmlCode($html, 'BODY BTM-');

// JS ans Body-Ende
I::insertJsFile(WB_URL . '/modules/mein_modul/js/script.js', 'BODY BTM-');

Getestet und bestätigt von slugger, WBCE 1.6.5, Maerz 2026
Entwicklung: mod_consent (DSGVO Cookie-Consent Tool)

Last edited by Slugger (18.03.2026 22:02:08)

---

Hoster: ALL-INKL *** Grundsätzliche WBCE Konfig ***
WBCE: 1.6.5 • BE: 2.1.0 • PHP: 8.x * Alle • BE: Argos
Status Projekt 1-4:  OK

mrbaseman

Core-Team

Re: Snippet-Modul Dokumentation - Fehlende/Irreführende Hinweise

Da hat sich über die Jahre vieles geändert. Die Output-Filter und die Insert-Klasse kamen bei WBCE im Core durch die Integration des OPF Dashboards mit hinzu, während es Snippets schon viel länger gab.

Hybride Module, die gleichzeitig als normale Page-Module fungieren und außerdem ein Droplet bereitstellen (NWI ist so ein Beispiel) wurden auch erst viel später möglich.

Die Doku hält nicht immer mit den Neuerungen Schritt, aber oft sind das sehr spezielle Themen, die man entweder im Forum finden kann oder auf Anfrage erläutert bekommt.

Auch die Release-Notes informieren regelmäßig bei jedem Release recht umfangreich über die Neuerungen im Core. Danke an dieser Stelle an Florian, der dies immer sehr vorbildlich zusammen stellt, inclusive Anleitung zum Upgrade.