Seit Magento Open Source 2.4.3, erschienen im August 2021, ist der Page Builder auch in der kostenlosen Magento-Version enthalten. Davor war der Drag-and-drop-Editor Adobe Commerce vorbehalten, und wer eine Landingpage bauen wollte, schrieb HTML in den TinyMCE-Editor oder ein Ticket an die Agentur. Heute kannst du Magento 2 an vielen Stellen ohne Programmierkenntnisse anpassen. An vielen, nicht an allen. Und manches, was im Admin technisch möglich ist, würden wir trotzdem nicht so lösen. In diesem Artikel zeigen wir, was die Design-Konfiguration kann, wo der Page Builder seine Stärken hat und an welchen Stellen du um einen Entwickler nicht herumkommst.
Was die Design-Konfiguration im Magento-Admin wirklich kann
Die zentrale Stelle für das Erscheinungsbild liegt im Admin unter Content > Design > Configuration. Dort stellst du pro Website, Store oder Store View ein, welches Theme aktiv ist, und pflegst Logo, Favicon, Standard-Seitentitel und Meta-Angaben. Auch Wasserzeichen für Produktbilder und das Logo der Transaktions-E-Mails liegen hier.
Farben und Schriften fehlen dort komplett. Luma, das Standard-Theme von Magento, bietet dafür im Admin keine einzige Einstellung. Die Farben stecken in LESS-Variablen, bei Hyvä in der Tailwind-Konfiguration, und beides ist Entwicklerarbeit. Einige kommerzielle Themes aus dem Marketplace bringen eigene Options-Panels mit Farbwähler mit. Das ist bequem, bindet dich aber eng an dieses Theme und an die Update-Politik seines Herstellers.
Bei Kategorien, Produkten und CMS-Seiten wählst du außerdem das Seitenlayout, also ob die Seite einspaltig ist oder eine Sidebar links oder rechts bekommt. Früher gab es dort zusätzlich ein Feld für frei eingegebenes Layout-XML. Seit Magento 2.3.4 ist das für neue Anpassungen Geschichte. Im Admin wählst du nur noch Layout-Update-Dateien aus, die ein Entwickler im Theme hinterlegt hat. Wir halten das für die richtige Entscheidung. Frei eingetipptes XML in der Datenbank war ein Sicherheitsrisiko und tauchte in keiner Versionskontrolle auf.
Widgets und CMS-Blöcke: das unterschätzte Werkzeug
Bevor du zum Page Builder greifst, lohnt ein Blick auf zwei ältere Werkzeuge. CMS-Blöcke unter Content > Blocks sind wiederverwendbare Inhaltsbausteine. Ein Versandhinweis, der auf vierzig Seiten steht, wird genau einmal geändert und ist überall aktuell.
Widgets unter Content > Widgets platzieren solche Blöcke oder dynamische Inhalte an festen Stellen im Layout, eingeschränkt auf bestimmte Seitentypen, Kategorien oder Store Views. Das Widget „Catalog Products List“ zeigt zum Beispiel alle Produkte, die eine Bedingung erfüllen, etwa eine bestimmte Kategorie oder einen Attributwert. Neue Produkte erscheinen dort automatisch, ohne dass jemand die Seite anfasst.
Zeitgesteuerte Inhalte gibt es in Magento Open Source nicht. Content Staging, mit dem sich eine Aktionsseite für Freitag 0 Uhr vorbereiten lässt, ist Adobe Commerce vorbehalten. In Open Source braucht es dafür eine Erweiterung oder jemanden, der um Mitternacht auf „Speichern“ klickt.
Page Builder: stark bei Landingpages, schwach bei Struktur
Der Page Builder ersetzt seit 2.4.3 den TinyMCE-Editor bei CMS-Seiten, CMS-Blöcken, Kategorie- und Produktbeschreibungen. Du ziehst Zeilen, Bilder, Slider und Produktlisten auf die Seite, prüfst das Ergebnis in der Vorschau für Desktop und Mobil und speicherst gelungene Aufbauten als Vorlage. Für eine Kampagnenseite oder eine Markenwelt ist das ein echter Fortschritt. Eine Marketing-Abteilung kann damit arbeiten, ohne auf den nächsten Sprint zu warten.
Die Grenzen zeigen sich meist erst nach ein paar Monaten:
- Design wandert in den Content. Page Builder speichert jede Seite als HTML mit Datenattributen und Stilangaben in der Datenbank. Abstände, Farben und Schriftgrößen hängen damit am einzelnen Element. Ändert sich das Corporate Design, fasst du jede Seite einzeln an.
- Mobil bricht die Reihenfolge. Spalten rutschen auf dem Smartphone untereinander, und zwar immer in der Reihenfolge von links nach rechts. Steht auf dem Desktop das Bild rechts, landet es mobil unter dem Text, und umgekehrt. Eine Einstellung dafür gibt es im Standard nicht.
- Es fehlen Elemente. Ein Accordion für FAQs sucht man im Standard vergeblich.
- Jedes Element kostet Ladezeit. Unter Luma laden Slider und Produktkarussells eine eigene Karussell-Bibliothek samt jQuery-Abhängigkeiten nach. Ein Slider ganz oben auf der Startseite ist deshalb häufig der Grund für einen schwachen Wert beim Largest Contentful Paint.
- Kein Versionsverlauf. Wer eine Seite versehentlich überschreibt, kann in Open Source nicht auf den Stand von gestern zurück, außer über ein Datenbank-Backup.
Unter Hyvä läuft der Page Builder nur über ein Kompatibilitätsmodul, und Page-Builder-Elemente von Drittanbietern brauchen oft eine eigene Hyvä-Anpassung.
Zwei der genannten Lücken haben wir übrigens selbst geschlossen: mit einem Accordion-Element für den Page Builder und einer Option, die Spaltenreihenfolge auf Mobilgeräten umzukehren. Das Accordion läuft unter Luma und Hyvä.
Admin-Einstellungen, Widgets und Page Builder im Vergleich
Welches Werkzeug passt zu welcher Aufgabe?
| Aspekt | Design-Konfiguration und Widgets | Page Builder |
|---|---|---|
| Wer damit arbeitet | Shop-Admin | Marketing, Redaktion |
| Was sich ändern lässt | Logo, Meta-Angaben, Seitenlayout, Platzierung von Blöcken | Inhalt und Aufbau einzelner Seiten |
| Farben und Schriften | nein, liegen im Theme-Code | pro Element einstellbar |
| Fehlerrisiko | gering, der Rahmen ist fest | mittel, mobile Darstellung kann brechen |
| Performance | neutral | hängt von Anzahl und Art der Elemente ab |
| Zeitsteuerung | nein | nur mit Content Staging in Adobe Commerce |
| Typischer Einsatz | globale Einstellungen, wiederkehrende Hinweise | Landingpages, Kampagnen, Markenseiten |
Als Faustregel hat sich bewährt: Was auf mehr als drei Seiten gleich aussehen soll, gehört ins Theme oder in einen CMS-Block. Was einmalig ist und nach der Kampagne wieder verschwindet, darf in den Page Builder.
Wo du ohne Entwickler nicht weiterkommst
Ohne Programmierkenntnisse kommst du in Magento 2 weit, solange es um Inhalte geht. Sobald es um Gestaltungsregeln oder um Logik geht, ist Schluss. Das betrifft vor allem vier Bereiche.
- Farben, Schriften und Abstände zentral ändern. Das passiert im Theme, bei Luma in LESS, bei Hyvä in Tailwind.
- Neue Page-Builder-Elemente. Ein eigener Content-Typ besteht aus XML-, JavaScript- und Template-Dateien, oft auch aus PHP.
- Aufbau von Produktseite und Checkout. Welche Informationen wo stehen, regelt das Layout-XML im Theme.
- Geschäftslogik. Preislogik jenseits von Katalog- und Warenkorb-Preisregeln, Versandlogik oder zusätzliche Checkout-Felder brauchen Code.
Der naheliegende Ausweg ist eine Erweiterung aus dem Marketplace. Für viele Aufgaben ist das auch der richtige Weg. „Plug-and-play“ ist es trotzdem nicht: Jedes Modul bringt fremden Code in deinen Shop, der bei jedem Magento-Update mitziehen muss. Was das für Stabilität und Sicherheit bedeutet, haben wir im Artikel über Drittanbieter-Module in Hyvä-Shops ausführlich beschrieben. Wir haben lieber zwei gut gewartete Module im Shop als zehn, von denen keiner mehr weiß, wofür sie installiert wurden.
Was du als Nächstes tun kannst
Wenn in deinem Shop bereits viele Seiten mit dem Page Builder entstanden sind, gibt es zwei pragmatische erste Schritte:
- Selbst prüfen: Öffne deine drei wichtigsten Page-Builder-Seiten auf dem Smartphone und in PageSpeed Insights. Achte darauf, ob Bilder und Texte mobil in einer sinnvollen Reihenfolge stehen und ob ein Slider das größte Element im sichtbaren Bereich ist.
- Mit uns aufräumen: Wir übernehmen die Content-Pflege in Magento, ziehen wiederkehrende Gestaltung aus dem Page Builder zurück ins Theme und bauen fehlende Elemente wie ein erweitertes Banner. Schreib uns an office@copex.io oder über das Kontaktformular.
Verwandte Themen aus unserem Blog: Hyvä, das neue Frontend für Magento, Largest Contentful Paint gezielt verbessern, Mage-OS 3.0 und seine Page-Builder-Neuerungen.
Quellen und Weiterlesen
- Adobe Experience League: Release Notes Magento Open Source 2.4.3 mit der Aufnahme des Page Builders in Open Source
- Adobe Developer: Page Builder mit Architektur und eigenen Content-Typen
- Adobe Experience League: Widgets mit Widget-Typen und Platzierung
