Sylius-Storefront nutzt Twig-Templates: der Weg zum entkoppelten Frontend
Ja, Sylius rendert seinen Storefront serverseitig mit Twig, dem Symfony-Template-Layer, kombiniert mit Bootstrap für das Styling und Symfony UX für Interaktivität. Das koppelt jede sichtbare Frontend-Änderung an den Sylius-Release-Zyklus. Über das eingebaute API-Platform-Bundle lässt sich der Storefront entkoppeln, aber danach ist der komplette Frontend-Aufbau Eigenleistung, wenn kein dedizierter Frontend-Layer dazukommt.
Was heißt „Sylius nutzt Twig-Templates" konkret?
Sylius ist ein Full-Stack-Symfony-Projekt. Der native Storefront ist eine Twig-Theme-Struktur: Kategorie-, Produkt- und Checkout-Seiten liegen als Twig-Templates in Theme-Bundles, das visuelle Grundgerüst ist Bootstrap, und punktuelle Interaktivität (Warenkorb-Updates, Filter, Formulare) läuft über Symfony UX mit Turbo, Stimulus und teils Live Components. Theme-Anpassungen bedeutet: Twig-Dateien überschreiben, Bundle neu bauen, Symfony-App neu deployen.
Das ist ein solides, bewährtes Setup für ein Symfony-Team. Der Punkt, den viele Sylius-Shops erst beim Wachsen spüren: Frontend und Backend sind über denselben Deploy-Zyklus verdrahtet. Ein Marketing-Team, das eine neue Landingpage oder eine Kampagnen-Variante will, braucht dafür einen Symfony-Developer und eine Freigabe im selben Release-Fenster wie jedes Backend-Update.
Das Problem, das viele Sylius-Teams gerade haben
Zwei Dinge treffen aufeinander. Erstens: Jedes Sylius-Upgrade (etwa von 1.x auf 2.x) berührt potenziell die Twig-Theme-Struktur, weil sich Bundle-Konventionen und Template-Hooks mitverändern. Ein Backend-Upgrade wird damit indirekt zum Frontend-Projekt. Zweitens: Marketing-Teams haben keinen Visual Editor. Jede Section-Änderung, jeder A/B-Test, jede neue Kampagnen-Seite läuft über ein Developer-Ticket, weil die Twig-Templates Code sind, kein editierbares Layout.
Sylius selbst kennt diesen Punkt und liefert mit dem API-Platform-Bundle eine saubere Antwort für Teams, die vom serverseitigen Rendering weg wollen: REST- und GraphQL-Endpunkte für Produkte, Kategorien, Warenkorb und Checkout. Das ist die technisch richtige Grundlage für einen entkoppelten Storefront. Nur bringt API Platform selbst keinen Storefront mit. Wer den Schritt in Eigenregie geht, baut Routing, SEO, Caching, Checkout-UX und Komponenten-Bibliothek komplett neu, meist mit einem eigenen Next.js- oder Nuxt-Projekt und einem eigenen Team dafür.
Wie Laioutr das löst, ohne Sylius abzulösen
Laioutr ist offizieller Sylius Technology Partner. Diese Partnerschaft ist die Grundlage für die Positionierung hier: Sylius bleibt euer Backend, Produktkatalog, Checkout-Logik, Order-Management und Admin-Bereich laufen unverändert weiter. Laioutr wird die Frontend-Ebene oben drauf, angebunden über genau die API-Platform-Schnittstelle, die Sylius bereits mitbringt.
Konkret heißt das: Laioutr spricht die Sylius-REST- und GraphQL-Endpunkte direkt an, ohne Custom-Glue-Code, und liefert PDP, PLP, Warenkorb und Checkout-Komponenten als fertigen Composable-Stack. Marketing bekommt dazu Studio, den Visual Editor, mit dem Landingpages, Kampagnen-Varianten und Section-Anpassungen ohne Developer-Ticket entstehen, live in der Storefront, nicht in einer isolierten Preview.
Der Effekt in einem Satz: Ihr verlasst den Twig-Release-Zug, Frontend-Änderungen sind nicht mehr an Sylius-Minor- oder Major-Releases gekoppelt, und ihr gewinnt einen Visual Editor, den die native Twig-Storefront nicht mitbringt. Wie sich das in der Praxis anfühlt, zeigt der Blick auf ein vergleichbares Muster bei Sylius B2B: Der Symfony-Backend mit einem entkoppelten Storefront kombiniert, wo dieselbe API-Platform-Anbindung für ein B2B-Setup genutzt wird.
Was Du gewinnst
- Zeit. Mit nativer Twig-Storefront: Landingpage-Änderung braucht Dev-Ticket + Symfony-Deploy. Mit Laioutr auf Sylius API Platform: Neue Landingpages und Kampagnen-Varianten im Studio, ohne Dev-Ticket.
- Geld. Mit nativer Twig-Storefront: Jedes Sylius-Upgrade ist potenziell auch ein Twig-Theme-Projekt. Mit Laioutr auf Sylius API Platform: Frontend-Release-Zyklus entkoppelt vom Sylius-Upgrade-Fenster.
- Qualität. Mit nativer Twig-Storefront: Performance und A11y hängen vom Theme-Stand ab. Mit Laioutr auf Sylius API Platform: Core Web Vitals und WCAG-konforme Komponenten als Plattform-Eigenschaft.
FAQ
Unterstützt Sylius Headless Commerce? Ja, über das API-Platform-Bundle stellt Sylius REST- und GraphQL-Endpunkte bereit. Was fehlt, ist ein fertiger Storefront auf dieser Basis, den Teil liefert Laioutr.
Müssen wir Sylius ablösen, um zu entkoppeln? Nein. Laioutr ist Sylius Technology Partner und setzt sich als Frontend-Layer auf euer bestehendes Sylius-Backend, ohne Replatforming.
Wie lange dauert die Umstellung typischerweise? Je nach Umfang eures API-Platform-Setups und der Zahl der Storefront-Sektionen meist vier bis sechs Wochen bis zum ersten produktiven Sylius-Storefront auf Laioutr.
Nächste Schritte
Wenn eure Sylius-Storefront gerade an die Grenzen der Twig-Theme-Struktur stößt, ist der nächste Schritt eine 30-minütige Demo, in der wir eure API-Platform-Konfiguration gegen den Laioutr-Composable-Stack spiegeln. Sylius-Frontend-Demo buchen.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist CEO & Co-Founder von Laioutr. Er begleitet Sylius-Teams direkt bei der Frage, wie sich der Storefront von der Backend-Release-Kadenz lösen lässt, ohne die bestehende Symfony-Investition aufzugeben.