Bludit verstehen: Ordnerstruktur, Flat-File-Daten und Update-Grenzen
Was gehört zum Core, wo liegen Inhalte und wie trennt man eigene Erweiterungen sauber vom System?
Wer Bludit erweitern will, sollte zuerst verstehen, welche Verzeichnisse zum Core gehören und welche den eigenen Zustand tragen. Das verhindert, dass ein Update selbst geschriebene Erweiterungen überschreibt oder ein Backup nur die Hälfte enthält.
Die fünf Hauptbereiche
| Pfad | Aufgabe |
|---|---|
bl-content/ | Inhalte, Datenbanken, Uploads, Plugin-Daten |
bl-kernel/ | Bludit-Core – möglichst nicht patchen |
bl-languages/ | Core-Sprachdateien |
bl-plugins/ | Erweiterungen und eigene Logik |
bl-themes/ | Frontend-Design und Templates |
Warum Core-Hacks problematisch sind
Eine Änderung in bl-kernel kann funktionieren, ist aber beim nächsten Update schwer nachzuvollziehen. Eine Funktion gehört deshalb möglichst in ein Plugin; Darstellung in ein Theme. Nur wenn es keine Erweiterungsschnittstelle gibt, sollte ein Core-Patch überhaupt erwogen und dann sauber dokumentiert werden.
Bludit lädt Seiten als Objekte
Im Frontend stehen je nach Ansicht vordefinierte Variablen zur Verfügung: $content enthält veröffentlichte Inhalte für Listenansichten, $staticContent statische Seiten, $page die aktuell betrachtete Seite. Die Objekte $pages, $categories und $tags repräsentieren die jeweiligen Datenbanken.
<?php
foreach ($content as $page) {
echo '<h2><a href="'.$page->permalink().'">'.$page->title().'</a></h2>';
echo $page->contentBreak();
}
?>Backup-Regel
Mindestens bl-content/ sichern. Wenn du eigene Themes oder Plugins entwickelt hast, zusätzlich bl-themes/ und bl-plugins/ sichern. Für reproduzierbare Deployments lohnt ein komplettes Projektarchiv, in dem sensible Zugangsdaten vor einer Weitergabe neutralisiert werden.