Bekannte Fallstricke

Gesammelte Erfahrungen aus der Praxis — undokumentierte Verhaltensweisen die tagelange Fehlersuche verursachen können. Besonders relevant für Snippet- und Hybrid-Module.

Getestet: WBCE 1.6.5 / PHP 8.x — März 2026

Fallstrick 1 — ADMIN_URL ist kein Frontend-Guard

Problem

In älteren Modulen und Beispielen findet sich dieser Guard:

// ❌ FALSCH
if (defined('ADMIN_URL')) { return; }

Die Annahme: ADMIN_URL ist nur im Backend definiert → Guard schützt vor Backend-Ausführung.

Realität: ADMIN_URL wird in /framework/initialize.php für alle Kontexte definiert — also auch im Frontend. Der Guard greift immer und verhindert jede Ausführung der include.php.

Lösung

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

WB_FRONTEND wird nur in /framework/frontend.functions.php gesetzt und ist der einzig zuverlässige Frontend-Indikator.

Fallstrick 2 — echo in include.php landet nach

Problem

Output von include.php wird intern in $sPreOutput gesammelt:

// Ablauf in /index.php (vereinfacht):
require WB_PATH . '/framework/frontend.functions.php';
$sPreOutput = ob_get_clean();    // ← include.php Output landet hier
ob_start();
require TEMPLATE/index.php;
$sContent = ob_get_clean();
$sContent = $sContent . $sPreOutput;  // ← wird ANS ENDE gehängt!

Folge: CSS und JS die per echo ausgegeben werden landen nach dem schließenden </html> Tag. Browser sind tolerant — aber korrekt ist es nicht.

Lösung — Insert-Klasse verwenden

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

// JS ans Body-Ende:
I::insertJsFile(WB_URL . '/modules/mein_modul/js/script.js', 'BODY 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-');

Voraussetzung: OPF-Filter "Class Insert Helper" muss aktiv sein!

Fallstrick 3 — UPDATE addons-Tabelle in install.php schlägt fehl

Problem

Manche älteren Beispiele für Hybrid-Module enthalten:

// ❌ FALSCH
$database->query("UPDATE `{TP}addons` SET `function` = 'tool,snippet'
    WHERE `directory` = 'mein_modul'");

Realität: WBCE schreibt den Datensatz in die addons-Tabelle erst nach Ausführung von install.php. Das UPDATE greift ins Leere.

Lösung

// ✅ RICHTIG — einfach in info.php:
$module_function = 'page,tool,snippet';

WBCE liest $module_function direkt aus info.php und schreibt es selbst in die addons-Tabelle. Kein manuelles UPDATE nötig.

Minimale include.php als Vorlage

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

// Nur im Frontend ausführen
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>
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-');

Checkliste Snippet / Hybrid-Modul

✅ WB_FRONTEND als Guard — nicht ADMIN_URL
✅ Insert-Klasse statt echo für CSS/JS
✅ OPF-Filter "Class Insert Helper" aktiv
✅ Kein UPDATE addons-Tabelle in install.php
✅ module_function in info.php setzen