Page Builder Content Types verstehen
Page Builder Content Types verstehen
~5 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Widgets (Kapitel 55-57) geben Redakteurinnen kontrollierten, entwicklerdefinierten Zugriff auf Code. Page Builder geht einen Schritt weiter: der seit Magento 2.3 eingebaute visuelle Seitenbaukasten im Admin, mit dem ganze Seiten per Drag-and-drop aus einzelnen Bausteinen - "Content Types" - zusammengesetzt werden, ganz ohne WYSIWYG-Direktiven-Syntax.
Content Types: die Bausteine von Page Builder
Jeder Baustein, den eine Redakteurin auf die Page-Builder-Bühne ziehen kann - Text, Überschrift, Bild, Banner, Zeile/Spalte als Layout-Container, Produkte, eingebetteter CMS-Block, Video, Buttons, Tabs, Slider, Karte - ist ein eigener Content Type. Core-Content-Types kommen als eigene kleine Module (Magento_PageBuilder*); ein eigener Content Type registriert sich genauso über eine eigene etc/pagebuilder/content_type.xml.
Master-Format: die eigentliche Persistenzform
Der wichtigste Architekturunterschied zu Widgets: Ein Widget wird bei JEDEM Seitenaufruf frisch aus der {{widget}}-Direktive gerendert (Kapitel 55). Die meisten Page-Builder-Content-Types dagegen rendern nur EINMAL, im Admin, beim Speichern - das Ergebnis, das sogenannte "Master-Format"-HTML (mit data-content-type/data-appearance/data-element-Attributen für spätere erneute Bearbeitung), wird direkt in das content-Feld der CMS-Seite bzw. des CMS-Blocks geschrieben. Im Frontend wird dieses HTML weitgehend unverändert ausgeliefert - nur Stil-/Attribut-Verarbeitung läuft zur Laufzeit noch über Magento\PageBuilder\Model\Render\Attributes, keine erneute PHP-Ausführung des eigentlichen Inhalts.
Achtung: Das hat eine wichtige praktische Konsequenz: Die meisten eigenen Content Types können KEINE live-aktuellen, pro Request unterschiedlichen Daten anzeigen - genau wie ein Punktestand pro Kunde. Core-Content-Types, die trotzdem dynamisch sein müssen (der eingebettete CMS-Block, die Produkt-Kachel, personalisierte "Dynamic Blocks"), backen deshalb gar keinen echten Inhalt ein - ihr Master-Format ist selbst nur eine {{widget type="..."}}-Platzhalter-Direktive, die erst zur Laufzeit vom selben Widget-Filter aus Kapitel 55 aufgelöst wird. Ein eigener Content Type KANN denselben Trick anwenden, ist dann aber genaugenommen ein als Page-Builder-Baustein verkleidetes Widget. Kapitel 61 greift diese Abwägung noch einmal konkret auf.
Die Dateien eines eigenen Content Types
Neue Dateien in diesem Block (Kapitel 59/60)
app/code/Mironsoft/Loyalty/
├── etc/pagebuilder/content_type.xml # Registrierung (Kapitel 59)
├── Block/PageBuilder/PointsBanner.php # Master-/Frontend-Render-Block (Kapitel 59)
├── view/frontend/templates/pagebuilder/points-banner/
│ └── default.phtml # Frontend-Template (Kapitel 59)
├── view/adminhtml/web/js/content-type/points-banner/
│ └── preview.js # Live-Vorschau-Komponente (Kapitel 60)
└── view/adminhtml/web/template/content-type/points-banner/
└── preview.html # Knockout-Vorschau-Template (Kapitel 60)etc/pagebuilder/content_type.xml- Registrierung: Name, Label, Menü-Abschnitt, Icon, sowie die Komponentenpfade für Vorschau und Master-Format.Block/PageBuilder/PointsBanner.php- Block-Klasse für die serverseitige Master-Format-Erzeugung beim Speichern UND für die Frontend-Ausgabe - dasselbe Block+Template-Paar übernimmt beide Rollen.view/frontend/templates/pagebuilder/points-banner/default.phtml- das eigentliche Markup.view/adminhtml/web/js/content-type/points-banner/preview.js+ zugehöriges.html-Template - die Live-Vorschau auf der Admin-Bühne, komplett unabhängig vom PHP-Rendering (Kapitel 60).
Content-Type-Vorschau vs. Widget-Vorschau
Ein Widget hat im WYSIWYG-Editor KEINE Live-Vorschau - bis zum Speichern zeigt der Editor nur einen Platzhalter-Chip mit dem Widget-Label. Ein Page-Builder-Content-Type dagegen rendert sofort, bearbeitbar, WYSIWYG-genau direkt auf der Admin-Bühne - genau das ist Page Builders eigentliches Wertversprechen, und genau deshalb braucht ein eigener Content Type spürbar mehr Dateien als ein Widget: die separate Knockout-Vorschau-Komponente aus Kapitel 60 gibt es bei einem Widget schlicht nicht.
Tipp: Der exakte Aufbau von content_type.xml und der internen Master-Format-Render-Route unterscheidet sich zwischen Magento-Minor-Versionen leicht. Bevor dieses Modul produktiv würde, lohnt ein Blick in vendor/magento/module-page-builder-banner/etc/pagebuilder/content_type.xml der eigenen Installation - der eingebaute Banner-Content-Type ist unserem Punkte-Banner aus Kapitel 59 strukturell am nächsten (Bild/Text/Call-to-Action) und damit die zuverlässigste Quelle für Details, die dieses Tutorial bewusst vereinfacht.