Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

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

  1. etc/widget.xml - Registrierung: ID, Block-Klasse, Label, Beschreibung und die im Admin editierbaren Parameter (Kapitel 57).
  2. Eine Block-Klasse, die \Magento\Widget\Block\BlockInterface implementiert - das eigentliche Rendering (Kapitel 56 baut die erste dieses Moduls).
  3. 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.