Widgets in Magento 2: Grundlagen und Einsatzzweck
Widgets in Magento 2: Grundlagen und Einsatzzweck
~6 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Block 6 hat dem Modul eine vollständige, barrierefreie Frontend-Oberfläche gegeben - aber ausschließlich auf eigenen, vom Router aus Kapitel 46 kontrollierten Seiten. Was aber, wenn eine Marketing-Kollegin den Punktestand oder eine Werbebotschaft zum Programm auf eine ganz gewöhnliche CMS-Seite setzen will, ohne dafür einen Entwickler und ein neues Layout-XML zu bemühen? Genau dafür gibt es Widgets - und, ab Kapitel 58, Page Builder. Beide sind das Thema von Block 7.
Was ist ein Widget?
Ein Widget ist eine im Admin konfigurierbare Ausgabe, die sich in beliebigen WYSIWYG-Inhalt einfügen lässt: CMS-Seiten, CMS-Blöcke, Produkt- und Kategoriebeschreibungen - überall dort, wo Magento einen WYSIWYG-Editor mit "Widget einfügen"-Schaltfläche anbietet. Zwei unabhängige Einfügewege führen zum selben Ergebnis:
- Inline-Direktive:
{{widget type="..." param="value"}}landet direkt als Text im WYSIWYG-Feld, eingefügt über den "Widget einfügen"-Button. Kein separater Datensatz, das Widget lebt nur als Text innerhalb dieses einen Inhalts. - Widget Instance: unter Content > Elements > Widgets im Admin angelegt, bindet ein Widget dauerhaft an bestimmte Layout-Handles, Container und Store-Views - taucht selbst NICHT im WYSIWYG-Text auf, sondern erzeugt intern eine eigene Layout-XML-Aktualisierung.
Beide Wege instanziieren am Ende dieselbe PHP-Klasse mit denselben, im Admin eingegebenen Parametern - der Unterschied liegt nur darin, WO das Widget landet und wie es dort hinkommt.
Widget ist keine Alternative zu ViewModel
Kapitel 47 hat Block vs. ViewModel als Frage der Template-Datenversorgung für Entwickler-kontrollierte Seiten behandelt. Ein Widget beantwortet eine andere Frage: "Wie bekommt jemand OHNE Entwicklerzugriff - eine Redakteurin, ein Marketing-Kollege - kontrollierten Zugriff auf meinen Code, ohne eine Zeile Layout-XML zu schreiben?" Beide Fragen sind orthogonal zueinander, nicht konkurrierend.
Die drei Bestandteile eines Widgets
etc/widget.xml- Registrierung: ID, Block-Klasse, Label, Beschreibung und die im Admin editierbaren Parameter (Kapitel 57).- Eine Block-Klasse, die
\Magento\Widget\Block\BlockInterfaceimplementiert - das eigentliche Rendering (Kapitel 56 baut die erste dieses Moduls). - Ein
.phtml-Template - technisch identisch zu jedem anderen Block-Template dieser Serie.
<?xml version="1.0"?>
<widgets xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Widget:etc/widget.xsd">
<widget id="vendor_module_widget_id"
class="Vendor\Module\Block\Widget\SomeWidget"
is_email_compatible="false">
<label translate="true">Widget Label</label>
<description translate="true">Widget Description</description>
<parameters>
<!-- see chapter 57 for real parameter declarations -->
</parameters>
</widget>
</widgets>Achtung: is_email_compatible erlaubt, dasselbe Widget auch in Transaktions-E-Mail-Vorlagen einzufügen - ein völlig anderer Rendering-Kontext ohne laufenden HTTP-Request und ohne CustomerSession. Ein Widget, das wie das in Kapitel 56 gebaute auf der Session des eingeloggten Kunden beruht, gehört hier auf false. Genau dieser Kontext-Unterschied war schon in Kapitel 44 der Grund, warum EmailPointsHelper statt eines ViewModels oder Widgets für Transaktions-E-Mails zuständig ist.
Wo Widgets technisch ansetzen
Magento\Widget\Model\Template\Filter erkennt die {{widget}}-Direktive und instanziiert die konfigurierte Klasse, sobald WYSIWYG-Inhalt durch Magentos Filterkette läuft - dieselbe Kette, die auch {{trans}}- und {{config path=""}}-Direktiven auflöst, und die für CMS-Seiten, CMS-Blöcke sowie Produkt-/Kategoriebeschreibungen gleichermaßen gilt.
Tipp: widget.xml wird - wie crontab.xml aus Kapitel 32 oder events.xml aus Kapitel 30 - in den config-Cache-Typ eingelesen. Nach dem Anlegen oder Ändern einer widget.xml reicht bin/cache-clean config, damit das neue Widget im Admin auftaucht - ein vollständiges setup:upgrade ist dafür NICHT nötig, da keine Datenbanktabelle involviert ist.
Achtung: Eine im Admin unter Content > Elements > Widgets angelegte Widget Instance landet in der Tabelle widget_instance und referenziert die id aus widget.xml als reinen String. Wird diese ID später umbenannt oder die widget.xml-Datei komplett entfernt, bleibt der Datenbankeintrag bestehen, verweist aber ins Leere - das Widget verschwindet stillschweigend aus dem Frontend, ohne Fehlermeldung im Admin. Vor einem Rename immer prüfen, ob bereits produktive Widget Instances existieren.
Tipp: Kapitel 56 baut jetzt das erste echte Widget dieses Moduls: eine "Meine Punkte"-Anzeige für CMS-Seiten, die - wie schon in Kapitel 47 angekündigt - eine echte Block-Klasse braucht, dabei aber keine einzige Zeile Geschäftslogik dupliziert.