Bludit Hooks komplett erklärt: Frontend, Admin, Seiten-Lifecycle und typische Einsatzfälle

Welche Hooks wann laufen, welche vom Theme abhängen und wie man den richtigen Erweiterungspunkt auswählt.

18.09.20262 Minuten Lesezeit

Hooks sind das eigentliche Erweiterungsmodell von Bludit. Ein Hook ist eine Methode im Plugin, die Bludit oder ein Theme an einem definierten Punkt ausführt. Wer den richtigen Hook wählt, braucht viel seltener Core-Patches.

Die wichtigsten Hook-Gruppen

Hook	Typischer Einsatz
`beforeAll`	sehr früh, noch vor dem Theme
`beforeRulesLoad`	vor Regeln/weiterer Verarbeitung
`beforeSiteLoad`	Frontend, nachdem Inhalte bereitstehen; gut für Laufzeit-Manipulation
`siteHead`	im des Themes
`siteBodyBegin`	direkt nach Body-Beginn, wenn Theme ihn aufruft
`pageBegin`	vor einem Beitrag/Seitenblock, themeabhängig
`pageEnd`	nach einem Beitrag/Seitenblock, themeabhängig
`siteSidebar`	Sidebar-Ausgabe, themeabhängig
`siteBodyEnd`	am Ende des Body
`afterSiteLoad`	nach Frontend-Verarbeitung
`adminHead`	Admin-Head
`adminBodyBegin`	Beginn Admin-Body
`adminSidebar`	Adminnavigation
`dashboard`	Historischer Dashboard-Hook: in 3.16.x von der View aufgerufen; in Bludit 3.22.0 weiterhin registriert, aber in der aktuellen Dashboard-View nicht mehr ausgeführt. Für 3.22.x deshalb z. B. `adminBodyEnd` als Fallback verwenden.
`beforeAdminLoad`	vor Admin-Controller/View
`afterAdminLoad`	nach Admin-Ausgabe
`afterFormSave`	nach Formularspeichern
`afterPageCreate`	nach Seitenerstellung
`afterPageModify`	nach Seitenänderung
`afterPageDelete`	nach Seitenlöschung
`loginHead`	Login-Head
`loginBodyBegin`	Beginn Login-Body
`loginBodyEnd`	Ende Login-Body

Wichtig ab Bludit 3.22.x: dashboard ist ein Sonderfall

Die Plugin-Registry kennt dashboard in 3.22.0 weiterhin. Die aktuelle Datei bl-kernel/admin/views/dashboard.php ruft Theme::plugins('dashboard') aber nicht mehr auf. Ein Plugin kann daher eine formal richtige dashboard()-Methode besitzen, ohne dass sie sichtbar wird. Das ausführliche Dashboard-3.22.x-Tutorial zeigt eine rückwärtskompatible Lösung mit dashboard() für ältere Versionen und adminBodyEnd() als 3.22.x-Fallback.

Frontend-Hook: siteHead

public function siteHead()
{
    return '<meta name="example" content="mein-plugin">';
}

Damit das funktioniert, muss das Theme Theme::plugins('siteHead') im HTML-Head aufrufen. Hooks, die vom Theme ausgelöst werden, sind nur so zuverlässig wie die Theme-Integration.

Content vor Ausgabe verändern

public function beforeSiteLoad()
{
    global $content;
    foreach ($content as $page) {
        $raw = $page->contentRaw();
        $page->setField('content', str_replace('[[jahr]]', date('Y'), $raw));
    }
}

Diese Änderung betrifft das Laufzeitobjekt, nicht automatisch die Datei auf dem Datenträger. Das ist ideal für Shortcodes oder dynamische Platzhalter. Zum permanenten Bearbeiten verwendest du dagegen die Pages-Datenbank bzw. passende Create/Modify-Hooks.

afterPageCreate und afterPageModify

Diese Hooks erhalten den Page-Key. Damit kann ein Plugin nach dem Speichern Metadaten berechnen, Suchindizes aktualisieren oder externe Caches invalidieren. Vermeide Endlosschleifen: Wenn dein Hook wiederum die gleiche Seite speichert, kann er erneut ausgelöst werden.

Hook-Auswahl als Entscheidung

Soll nur HTML/CSS/JS ergänzt werden? → Theme-Hook wie siteHead oder siteBodyEnd.
Soll geladener Inhalt nur für die Ausgabe verändert werden? → beforeSiteLoad.
Soll nach einer gespeicherten Seite etwas passieren? → afterPageCreate/Modify/Delete.
Soll eine eigene Admin-Route Daten verarbeiten? → adminController() plus View, nicht alles in beforeAdminLoad.
Soll ein Admin-JavaScript nur auf bestimmten Seiten laufen? → adminHead/adminBodyEnd und Controller prüfen.