Block-Overrides, Seeds, Flächen

Block-Overrides

Ein Override ist eine Datei views/blocks/{typ}.blade.php im Theme. Sie ersetzt die Ausgabe eines Blocks — nicht die Entscheidung, was ausgegeben wird.

1. Schema nachschlagen:

   php artisan blocks:schema category_grid

2. Die eingebaute Darstellung als Ausgangspunkt nehmen und das Markup frei gestalten.

3. Jede Option des Blocks auswerten ($o['…']) — und keine lesen, die es nicht gibt.

Ein abschreckendes Beispiel aus der Praxis: Ein Kategorie-Raster-Override hatte acht Kategorien fest im PHP stehen. Der Händler pflegte im Builder Kacheln, die nirgends erschienen, und sah dafür Kategorien, die er nie eingetragen hatte.

Regeln für Overrides

• Preise nie selbst formatieren. $p->priceHtml(), unitPriceHtml(), deliveryTimeHtml() — dort hängen sich die Pflichtangaben ein (MwSt., Versand, Grundpreis).
• Keine erfundenen Zahlen — kein Platzhalter-Preis, keine Bewertung, keine „nur noch 3 Stück”. Platzhalter gehen live, und erfundene Knappheit ist irreführend (UWG).
• Symbole über block_icon('fa-name') — im Shop wird keine Icon-Schrift geladen.
• Bilder über den Bildbaustein bzw. media_picture(): liefert <picture> mit AVIF und WebP. Im CSS deshalb .hero img, nie .hero > img.
• Das erste Bild im Sichtbereich nie lazy laden — sonst kommt das größte Element zu spät.
• Produktfotos nie beschneiden: in Kacheln media_kachel_url(), Hintergrund media_randfarbe(), Format aus media_kachel_format().
• Keine eigene Kauflogik. Die Produktseiten-Mechanik kommt aus dem Core.

Seeds — Beispielinhalte

Unter demo/ liegt je Fläche eine JSON-Datei mit dem Block-Baum, den der Händler nach dem Aktivieren sieht:

Datei	Fläche
home.json	Startseite
header.json, mobile_header.json	Kopfzeile, mobile Kopfzeile
footer.json	Fußzeile
product_template.default.json	Produktvorlage
category_template.default.json	Kategorievorlage
announcement.json	Ankündigungsleiste
menus.json, pages.json	Beispielmenü und Beispielseiten
checkout_template.*.json	Kasse — siehe unten
{fläche}.json	jede eigene Fläche

Seeds füllen nur leere Flächen. Ohne Seeds startet der Builder leer — der Händler sieht nach dem Aktivieren nichts (Doctor: GELB).

Seeds dürfen nur Blocktypen enthalten, die es gibt, nur Optionen aus deren Schema und nur Blöcke, die in der Fläche erlaubt sind. Ein falscher Schlüssel (title statt heading) läuft ohne Fehler durch und zeigt den Vorgabetext.

Beispieltexte ohne Werbeaussagen, die ein Händler ungeprüft übernehmen könnte — insbesondere keine Umweltaussagen wie „nachhaltig” oder „klimaneutral” (EmpCo).

Eigene Flächen

Rendert ein Theme mehr als die fünf Kernflächen — etwa eine Kategorieleiste unter der Kopfzeile —, meldet es sie an. Sonst sieht der Händler sie im Shop und findet nirgends eine Stelle zum Ändern.

"regions": {
    "catbar": {
        "label": "Kategorieleiste",
        "hint":  "Weiße Leiste unter der Kopfzeile",
        "like":  ["header", "announcement"]
    }
}

Im Layout: {!! theme_blocks_render('catbar') !!}. Die Fläche erscheint im Builder als eigene Karte mit Vorschau und nimmt einen Seed unter demo/catbar.json.

like ist Pflicht: Jeder Block trägt eine Liste der Flächen, in denen er liegen darf, und kein Block kennt den Namen einer Theme-Fläche. like sagt, wie sich die Fläche verhält — was im Header liegen darf, darf auch in catbar liegen. Ohne like bleibt die Fläche leer.

Was gehört wohin?

Was	Wohin
Texte, Links, Reihenfolge, Ein/Aus	Fläche (Blöcke)
Schalter, die Theme-Zustand bedienen (Menü-Schublade öffnen)	Layout
Farben, Schriften, Abstände	Design-Tokens und Einstellungen

Eine eigene Kasse

Ein Theme kann eigene Kassen-Vorlagen mitbringen: demo/checkout_template.gate.json (Anmeldung), …step1.json bis …step4.json (Schritte) und …success.json (Bestätigung). Fehlen sie, nimmt der Shop seine eingebauten. Die Pflichtblöcke nach § 312j BGB (⚖ …) müssen im Prüfschritt liegen; der Doctor prüft das.