Shopware Controller: Wann du einen brauchst – und wann Standard reicht

Du planst eine neue Landingpage unter /kampagne oder willst einen JSON-Endpunkt für Live-Verfügbarkeiten bauen? Du öffnest das Backend, suchst in den Erlebniswelten – und stellst fest: Das geht so nicht. Die URL liefert 404, und die Daten, die du brauchst, sind nirgends verfügbar. Genau hier kommt der Shopware Controller ins Spiel – und wenn du dafür externe Unterstützung brauchst, hilft dir eine Shopware-Agentur oft schneller zur passenden Lösung. Aber bevor du loslegst: Brauchst du wirklich einen Controller? Oder reichen Shopware-Standard, Theme oder ein fertiges Plugin? In diesem Artikel erfährst du, wann ein Controller sinnvoll ist, welche Alternativen günstiger und schneller sind – und wie du die richtige Entscheidung für dein Projekt triffst.

Was ist ein Shopware Controller – in einfachen Worten

Ein Shopware Controller ist technisch gesehen der Einstiegspunkt für Anfragen (HTTP-Requests) in deinem Shop. Praktisch bedeutet das: Eine URL (z. B. /kampagne) wird auf eine bestimmte Funktion im Code gemappt. Diese Funktion lädt die benötigten Daten (z. B. Produkte, Texte, Verfügbarkeiten) und liefert eine Antwort – entweder als HTML-Seite (die du im Browser siehst) oder als JSON-Daten (für JavaScript/AJAX).

Wichtig: Ein Controller orchestriert nur – er ruft andere Dienste auf, die die eigentliche Arbeit machen (Daten laden, berechnen, speichern). Er sollte selbst keine Geschäftslogik enthalten, sondern nur die Anfrage entgegennehmen, die richtigen Helfer beauftragen und das Ergebnis zurückgeben.

Die zentrale Frage: Brauchst du überhaupt einen Controller?

Oft lautet die Antwort: Nein. Shopware bietet mächtige Standardwerkzeuge, die viele Anforderungen ohne Code abdecken. Bevor du Custom Code in Auftrag gibst, prüfe diese Alternativen:

1. Erlebniswelten / CMS (für Landingpages und Inhalte)

Du willst eine Kampagnenseite mit Bildern, Texten, Produkten und Call-to-Actions? Nutze die Erlebniswelten. Du baust Blöcke zusammen, pflegst Inhalte direkt im Backend – kein Code, keine Agentur nötig. Das CMS deckt 80 % aller „Ich brauche eine neue Seite"-Fälle ab.

Wann reicht CMS? Wenn du nur Layout, Bilder, Texte, statische Produkte zeigen willst. Wann nicht? Wenn du serverseitig Daten aus externen Systemen laden, komplexe Berechnungen machen oder spezielle URLs brauchst (die nicht über CMS-Kategorien abbildbar sind).

2. Theme-Anpassungen (für Layout-Änderungen)

Willst du nur das Aussehen ändern (andere Sidebar, zusätzliches Element, andere Farben)? Reicht Theme-Anpassung. Du überschreibst Templates (Twig-Dateien) oder CSS – ohne Controller, ohne Logik.

3. Rule Builder, Flows, Custom Fields (für Regeln und Daten)

Viele dynamische Anforderungen lassen sich über Shopware-Bordmittel konfigurieren: Preise je Kundengruppe, Versandkosten-Regeln, automatische E-Mails, zusätzliche Produktfelder. Prüfe, ob deine Anforderung über den Rule Builder oder Flows abbildbar ist – oft spart das Wochen Entwicklungszeit.

4. Store-API (für AJAX/JSON-Endpunkte)

Brauchst du JSON-Daten für JavaScript (z. B. Live-Suche, Warenkorb-Status)? Shopware liefert viele Standard-Endpunkte (Produkte, Kategorien, Cart, Checkout). Diese sind optimiert, sicher und upgrade-stabil. Prüfe die offizielle Shopware Store-API-Dokumentation – oft ist dein Endpunkt schon da.

5. Bestehendes Plugin/App aus dem Store

Vielleicht gibt es bereits eine Lösung im Shopware Store oder von Drittanbietern. Ein fertiges Plugin kostet oft 50–500 €, Custom-Entwicklung 2.000–10.000+ €. Lohnt sich die Recherche.

Wann wird ein Controller wirklich sinnvoll?

Controller wird relevant, wenn Standard-Mittel nicht ausreichen. Konkret:

• Du brauchst eine eigene URL, die Shopware ab Werk nicht hat (z. B. /konfigurator, /antragsformular, /api/verfuegbarkeit).
• Du willst serverseitig Daten bündeln aus mehreren Quellen: Shop-Context (Sprache, Währung, Kunde), Warenkorb, externe Systeme (ERP, PIM) – und sauber ins Template oder als JSON liefern.
• Du brauchst komplexe Validierung oder Geschäftslogik, die nicht über Rule Builder abbildbar ist (z. B. mehrstufige Formulare, Custom-Berechnungen).
• Du willst AJAX-Endpunkte, die Store-API nicht abdeckt (z. B. Echtzeit-Verfügbarkeit aus externem Lager, Custom-Filter mit spezieller Logik).
• Du willst Erweiterbarkeit für andere Plugins via Events (fortgeschrittenes Thema, relevant für Agenturen/große Projekte).

Entscheidungsbaum: Standard vs. Code – so entscheidest du

Stelle dir diese Fragen:

Business-Perspektive: Kosten, Risiken und Agentur-Briefing

Aus Projekt- und Entscheider:innen-Sicht ist die Frage nicht nur „technisch möglich?", sondern „wirtschaftlich sinnvoll?". Hier eine realistische Einordnung:

Typische Kostenrahmen (Agentur/Freelancer)

• CMS/Erlebniswelt-Seite: 500–2.000 € (je nach Komplexität, Blöcke, Content-Pflege)
• Theme-Anpassung (Layout): 1.000–3.000 € (CSS, Template-Overrides)
• Einfacher Controller (1 Seite/Endpoint): 2.000–5.000 € (inkl. Template, Tests, Deployment)
• Komplexe Seite (Controller + Daten-Services): 5.000–10.000 € (inkl. QA, Dokumentation)
• Umfangreiche Lösung (mehrere Endpunkte, externe Systeme): 10.000–25.000+ € (je nach Schnittstellen, Datenvolumen)

Wichtig: Einplanen solltest du Wartung, Updates und Tests. Custom Code ohne Tests ist riskant – plane 20–30 % Aufschlag für Qualitätssicherung, Deployment und Dokumentation ein.

Wann besser nicht custom entwickeln

• Fehlende interne Ressourcen: Wenn niemand im Team Code pflegen kann, entstehen Abhängigkeiten zur Agentur. Bei Standard/CMS bist du autonomer.
• Kurzfristige Kampagnen: Landingpage für 2-Wochen-Kampagne? CMS reicht meist und ist in Stunden statt Tagen live.
• Budget/Zeit knapp: Custom Code braucht Vorlauf (Konzept, Entwicklung, QA). Standard ist oft sofort verfügbar.
• Upgrade-Risiko hoch: Checkout-nahe Anpassungen können bei Shopware-Updates brechen. Minimal-invasiv arbeiten, Events nutzen.

Agentur-Briefing: Was du klären solltest

Wenn du mit einer Agentur arbeitest, kläre vor Beauftragung:

• Anforderungen konkret: Welche URL, welche Daten, welche Funktionen? Mockups/Wireframes helfen enorm.
• Alternativen prüfen: Kann Store-API, Plugin oder CMS das abdecken? Gute Agentur zeigt Optionen auf.
• Wartung/Ownership: Wer pflegt später? Nur Code oder auch Inhalte? Wer testet nach Updates?
• Tests/QA: Sind Tests inkludiert? Welche Browser/Geräte? Staging-System vorhanden?
• Dokumentation: Code-Kommentare, README, Übergabe-Dokumentation?
• Performance/Security: Wie wird gecacht? CSRF-Schutz? Rate-Limiting bei AJAX?

Wenn Controller: Was passiert dann technisch?

Falls du dich für Custom-Entwicklung entscheidest, hier die Grundlagen – nicht zum Selberbauen (das macht dein Dev-Team), sondern zum Verständnis, was „unter der Haube" passiert:

1. Route und Controller-Methode

Eine Route mappt eine URL (z. B. /kampagne) auf eine Methode im Controller. Diese Methode nimmt die Anfrage entgegen, ruft Services auf und liefert eine Antwort (HTML oder JSON).

2. Daten laden via Services

Der Controller selbst lädt keine Daten – er beauftragt Services (z. B. „PageLoader", „DataService"). Diese holen Daten aus Shopware (Produkte, Kategorien), externen Systemen (ERP, API) oder berechnen Werte (Verfügbarkeit, Preise).

3. Template oder JSON ausgeben

Für HTML-Seiten rendert der Controller ein Template (Twig-Datei) – das ist die „Maske", die Daten ins Layout einbaut. Für AJAX liefert er JSON – strukturierte Daten für JavaScript.

4. Context und Personalisierung

Der SalesChannelContext gibt dem Controller Infos über Sprache, Währung, Kunde, Kundengruppe, Sales Channel (DE/EN, B2B/B2C). So kannst du Inhalte personalisieren – z. B. unterschiedliche Preise je Kundengruppe oder Texte je Sprache. Wenn dein Setup mehrere Länder/Sprachversionen abbildet, lohnt auch ein Blick auf Shopware Sprachen als Grundlage für sauberes Routing und Content-Strukturen.

AJAX/JSON-Endpunkte: Wann und wie

Typische Use Cases: Live-Suche, Warenkorb-Status, Verfügbarkeitscheck, Custom-Filter. Erste Regel: Prüfe, ob Store-API schon einen passenden Endpunkt hat – oft ist das der Fall und spart dir Custom-Code.

Wenn du einen eigenen Endpunkt brauchst, beachte:

• Security: CSRF-Schutz bei POST/PUT/DELETE, Authentication prüfen (eingeloggt?), Input validieren (Typ, Range, Format). Gerade bei Formularen und Endpunkten solltest du das Thema CSRF-Tokens in Shopware sauber mitdenken.
• Performance: Nur nötige Daten laden, Caching nutzen (Redis/In-Memory), DB-Queries optimieren.
• Rate-Limiting: Verhindert Missbrauch (z. B. 100 Requests/Minute) – wichtig bei öffentlichen Endpunkten.

Caching & Performance: Warum manche Seiten langsam sind

Shopware 6 nutzt HTTP-Cache (Reverse Proxy), aber nicht alle Seiten sind cachebar. Was beeinflusst Caching?

• Personalisierung: Eingeloggte User = personalisierte Daten → Cache greift nicht oder nur teilweise.
• Warenkorb: Änderungen invalidieren Cache – deshalb laden Warenkorb-Infos oft per AJAX nach.
• Query-Parameter: Unterschiedliche URLs = unterschiedliche Cache-Einträge (z. B. ?page=1 vs. ?page=2).

Praktische Tipps: Statische Teile cachen (Header, Footer), personalisierte Teile per AJAX nachladen. Performance messen mit Tools wie Shopware Profiler (zeigt DB-Queries, Ladezeiten) oder Blackfire.

Troubleshooting: Die häufigsten Fehler – einfach erklärt

Shopware 5 vs. Shopware 6: Kurzvergleich (für Umsteiger)

Fazit: Controller als „Tür" – und wann du sie wirklich öffnen solltest

Ein Shopware Controller ist der Einstiegspunkt für HTTP-Anfragen: Er nimmt Requests an, ruft Services auf und liefert HTML oder JSON. Technisch ist er mächtig – aber oft gar nicht nötig. Die wichtigste Erkenntnis: Shopware bietet Standard-Mittel – Erlebniswelten, Theme, Rule Builder, Store-API – die viele Anforderungen ohne Code abdecken. Erst wenn du eigene URLs, serverseitige Datenaufbereitung, komplexe Validierung oder spezielle AJAX-Endpunkte brauchst, lohnt sich Custom-Entwicklung.

Für Entscheider:innen: Kläre vor Beauftragung, ob Standard reicht, wer später pflegt, wie Tests/QA laufen. Custom Code ohne Tests ist riskant, und Wartung kostet. Rechne mit 2.000–10.000+ € je nach Komplexität – aber oft reicht CMS für 500–2.000 €. Wenn du Custom Code baust: Achte auf Security (CSRF, Auth, Rate-Limiting), Performance (Store-API, Caching) und Upgrade-Sicherheit (Tests, minimal-invasiv). So baust du Lösungen, die stabil laufen, wartbar sind und auch nach Updates funktionieren – ohne unnötigen Overhead.

Next Steps: Wenn du unsicher bist, ob dein Projekt einen Controller braucht: Sprich mit deiner Agentur oder einem Shopware-Entwickler. Ein 30-minütiges Beratungsgespräch spart oft Wochen Entwicklungszeit und Tausende Euro Budget. Und wenn Standard reicht: umso besser – dann kannst du selbst loslegen, ohne auf Code-Deployment zu warten. Falls du gerade vor größeren Änderungen oder einem Relaunch stehst, kann außerdem ein Shopware-Check helfen, Risiken und Quick Wins frühzeitig zu erkennen.