Magento Visual Editor: Die Schicht, die Hyvä nicht liefert

Hyvä beschleunigt, wie Entwickler Magento-2-Themes bauen. Es gibt Marketern aber keine Möglichkeit, Seiten selbst zu komponieren oder zu bearbeiten, ohne ein Entwickler-Ticket zu schreiben. Genau diese Schicht fehlt den meisten Magento-Frontends heute, und genau die liefert ein Magento Visual Editor obendrauf auf demselben Magento-Backend, ohne Hyvä zu ersetzen, wo es bereits funktioniert.

Was Hyvä wirklich ist (und was nicht)

Hyvä hat Magentos Standard-Theme Luma durch einen schlankeren Stack ersetzt: TailwindCSS fürs Styling, AlpineJS für Interaktivität, PHTML-Templates statt des RequireJS-/KnockoutJS-Bündels, das Luma mitbrachte. Das Ergebnis ist real: Shops auf Hyvä-Basis gehen typischerweise 30 bis 50 Prozent schneller live als vergleichbare Luma-Builds, und das Ökosystem ist nachgezogen, mit mittlerweile über 1.000 Magento-Extensions, die offizielle Hyvä-Kompatibilität mitbringen. Anfang 2026 ist Hyvä keine aufstrebende Alternative mehr. Es ist die Standardwahl für Magento-Händler, denen Frontend-Performance wichtig ist.

Das ändert nichts daran, was Hyvä ist: ein Theme-Framework für Entwickler. Jedes Template, jede Sektion, jeder neue Content-Block ist eine PHTML-Datei, die ein Entwickler schreibt, testet und deployed. Hyvä war nie darauf ausgelegt, die Seiten-Komposition ans Marketing-Team zu übergeben, und die eigene Dokumentation behauptet das auch nicht. Das ist keine Lücke in der Umsetzung. Es ist eine bewusste Scope-Entscheidung, und eine sinnvolle für ein Projekt, das sich auf Rendering-Performance konzentriert, nicht auf Editing-Erfahrung.

Die Lücke: Marketer schreiben weiter ein Ticket pro Seite

Sprich mit einem Magento-Händler, der wegen der Performance auf Hyvä migriert ist, und die Frontend-Zahlen haben sich meist verbessert. Frag das Marketing-Team, was sich am Publizieren einer neuen Landingpage, einer Saison-Kampagne oder einer Produktstory geändert hat, und die Antwort lautet meist: nichts. Sie schreiben weiter ein Briefing, geben es an einen Entwickler, warten auf einen Sprint-Slot und prüfen einen Staging-Link, bevor irgendetwas live geht.

Genau darum geht es hier. Hyvä hat das Performance-Problem gelöst. Es hat das Komposition-Problem nicht angefasst: wer eine Seite bauen und ändern kann, und wie schnell. Für einen Product oder Marketing Owner, der einen Content-Kalender, eine Black-Friday-Kampagne oder eine neue Produkt-Landingpage betreibt, sind ein "schnelles Magento-Frontend" und eine "schnelle Time-to-Publish" zwei verschiedene Probleme, und Hyvä löst nur das erste.

Warum "einfach ein Page-Builder-Modul dazu" die Lücke nicht schließt

Adobe Commerce, die kostenpflichtige Magento-Edition, bringt einen eigenen Page Builder mit, aber das ist ein Adobe-Commerce-Feature, kein Standard bei Magento Open Source oder einem Hyvä-Storefront. Selbst wo ein Page-Builder-artiges Modul existiert, bearbeitet es typischerweise CMS-Blöcke und statische Content-Bereiche innerhalb der bestehenden Template-Struktur. Es gibt Marketern keine Kontrolle über die vollständige Seiten-Komposition, wiederverwendbare Sektionen oder eine Live-Vorschau, die dem entspricht, was ein Entwickler in PHTML gebaut hat. Editing-Oberfläche und Rendering-Ebene bleiben zwei getrennte Systeme, die von Hand synchron gehalten werden müssen.

Das ist das wiederkehrende Fehlermuster bei nachgerüsteten Editoren: Sie fügen ein UI hinzu, ohne das zugrunde liegende Komponenten-Modell anzufassen. Die Templates des Entwicklers und die Blöcke des Marketers driften auseinander, und irgendwann muss jemand das wieder zusammenführen, meist wieder ein Entwickler.

Die fehlende Schicht: ein visueller, komponentenbasierter Editor für Marketer

Was Magento-Händler eigentlich suchen, wenn sie nach einem "No-Code Magento Frontend" suchen, ist nicht überall null Code. Es ist ein Weg, jede Seitenänderung nicht mehr durch eine Engineering-Warteschlange zu routen. Dafür braucht es drei Dinge gleichzeitig: einen visuellen Editor mit Live-Vorschau, eine gemeinsame Komponenten-Bibliothek, die Entwickler besitzen und Marketer daraus komponieren, und eine direkte Verbindung zu denselben Produkt-, Preis- und Bestandsdaten, die Magento ohnehin hat.

Genau diese Schicht liefert Laioutr FMP dazu. Studio, unser komponierbarer visueller Page Builder, ist ein visueller Editor mit Live-Vorschau: Ein Product oder Marketing Owner zieht Sektionen aus einer gemeinsamen Komponenten-Bibliothek, konfiguriert sie und veröffentlicht ohne Pull-Request. Entwickler behalten die Komponenten, die Design-Tokens und die Datenanbindungen. Nichts hier ist "No-Code für alle". Es ist Low-Code für Marketer und vollständig code-offen für Entwickler, und genau das ist die Aufteilung, die auf einem Magento-Storefront zählt. Ein Magento Visual Editor, der so funktioniert, ändert die Rechnung fürs Marketing-Team spürbar, nicht den Engineering-Rückstau.

Wie sich das neben Magento und Hyvä einfügt, nicht anstelle davon

Laioutr FMP verbindet sich mit Magento genauso wie jedes moderne Frontend: über Magentos GraphQL-API, ohne Custom-Connector. Das heißt, Teams müssen kein bestehendes Hyvä-Theme ausbauen, um eine marketerfähige Editing-Schicht zu bekommen. Ein übliches Muster: Engineering behält ein Hyvä-gebautes Theme, oder ein Laioutr-gebautes, für Templates, die tiefe Custom-Logik brauchen, wie Checkout-Schritte oder Konfigurator-Flows, während Marketing Kampagnen-Seiten, Landingpages und Content-Sektionen über Laioutr Studio für Marketing Manager betreibt, beide gegen dasselbe Magento-Backend lesend und schreibend.

Hyvä optimiert den Build des Entwicklers. Laioutr FMP optimiert das Publizieren des Marketers. Sie beantworten unterschiedliche Fragen, und ein Magento-Shop kann während einer Übergangsphase beides gleichzeitig fahren, oder sich voll auf Laioutrs Studio für alles Kundenzugewandte verlassen, sobald das Team bereit ist.

Was mit dieser Schicht konkret dazu kommt:

• Ein visueller Editor mit Live-Vorschau statt eines Staging-Link-Review-Zyklus
• Eine gemeinsame, markenkonsistente Komponenten-Bibliothek, sodass eine neue Kampagnen-Seite freigegebene Sektionen wiederverwendet, statt einen Einzelbau zu brauchen
• WCAG-konforme Komponenten ab Werk, was die Accessibility-Lücke schließt, die Luma-basierte Themes typischerweise ungeprüft mitschleppen
• EU-Hosting und eine auf Core Web Vitals optimierte Auslieferungsschicht: Neue Landingpages gehen üblicherweise rund 65 Prozent schneller live als bei einem klassischen Headless-Setup mit Entwickler-Ticket pro Seite, und der Content-Management-Layer hält Multi-Locale-Inhalte synchron

Wie das in der Praxis aussieht

Teams, die diese Schicht zu einem bestehenden Magento-Setup dazufügen, gehen typischerweise dieselben vier Schritte durch: Magentos GraphQL-API anbinden, keine Custom-Middleware nötig; die Sektionen des bestehenden Themes auf Laioutrs Komponenten-Bibliothek mappen; entscheiden, welche Seiten entwicklerverantwortet bleiben und welche zu Studio wandern; und die marketerzugewandten Seiten zuerst launchen, während der Rest der Migration, falls es eine gibt, parallel läuft. Nichts davon braucht einen Hyvä-Rebuild oder einen Magento-Versionswechsel. Das Backend bleibt genau da, wo es ist. Dieser Ansatz ist Teil dessen, wofür die Agentic Frontend Management Platform gebaut ist: Marketing und Engineering arbeiten mit derselben Komponenten-Basis, statt mit zwei getrennten Systemen.

Der ehrliche Scope

Wenn das Problem eines Magento-Shops rein die Rendering-Performance ist und das Team keine Beschwerden über die Publish-Geschwindigkeit hat, kann Hyvä allein die richtige Antwort sein, und eine zusätzliche Frontend-Schicht obendrauf würde ein Problem lösen, das noch gar nicht existiert. Die hier beschriebene Schicht zählt konkret dann, wenn ein Product oder Marketing Owner derjenige ist, der bei jeder neuen Seite auf einen Entwickler wartet. Das ist ein eigenständiger, verbreiteter und meist unterschätzter Kostenfaktor auf Magento-Storefronts, und genau den soll ein visueller, komponentenbasierter Editor entfernen.