WBCE CMS Forum

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.

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.

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.

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)

Beitrag geändert von Slugger (18.03.2026 21:02:08)