Sulu CMS 3 für mehrsprachige Firmenwebsites
Eine Firmenwebsite in mehreren Sprachen ist mehr als eine übersetzte Seite. Jede Sprache braucht eigene Adressen, die gleichen Inhaltsbausteine und eine Redaktion, die nicht bei jeder Änderung an drei Stellen suchen muss. Wir setzen solche Websites mit Sulu um, einem Content-Management-System auf Basis von Symfony. Diese Website ist selbst ein Beispiel dafür: Sie läuft mit Sulu 3 in Deutsch, Englisch und Türkisch.
Warum Sulu?
Sulu ist ein vollwertiges Symfony-Projekt. Alles, was über das Pflegen von Seiten hinausgeht – ein Kontaktformular mit Validierung, ein eigener Controller, eine Anbindung an ein CRM –, schreiben wir im gewohnten Framework, mit denselben Werkzeugen für Tests und statische Analyse. Es gibt keine Plugin-Welt, die man erst verstehen muss, und keinen Bruch zwischen CMS und Anwendung.
Gleichzeitig bringt Sulu eine Redaktionsoberfläche mit, die mehrsprachige Inhalte von Grund auf kennt. Eine Seite existiert einmal und hat je Sprache eine eigene Fassung.
Sprachen und Adressen
Die Sprachen legen wir im Webspace fest. Deutsch ist die Standardsprache und kommt ohne Präfix aus, Englisch und Türkisch erhalten /en und /tr. Wichtiger ist aber, dass jede Sprache eigene sprechende Adressen bekommt: /leistungen, /en/services und /tr/hizmetler sind dieselbe Seite. Suchmaschinen finden so in jeder Sprache Begriffe, nach denen dort gesucht wird, und Besucher sehen Adressen, die sie lesen können.
In Sulu 3 heißt der zugehörige Feldtyp route. Wer von Sulu 2 kommt, kennt ihn noch als resource_locator – eine der Stellen, an denen alte Templates angepasst werden müssen.
Templates als Vertrag
Seitenvorlagen beschreibt Sulu in XML. Jede Eigenschaft einer Vorlage steht im Twig-Template unter demselben Namen zur Verfügung. Genau darin liegt ein Risiko: Benennt jemand ein Feld auf einer Seite um, bricht die andere Seite still.
Wir halten deshalb in einem Property-Vertrag fest, welche Felder es gibt, welchen Typ sie haben und wie das Frontend sie darstellt. Backend, Frontend und Inhalt arbeiten gegen dieses Dokument, und Umbenennungen passieren nur gemeinsam.
Bausteine statt Sonderseiten
- Block-Bibliothek: Text, Kacheln, Listen, Kennzahlen, Ablauf, FAQ und weitere Bausteine, die sich auf jeder Seite kombinieren lassen. Jeder Block hat einheitliche Einstellungen für Farbe, Abstand und Ausrichtung.
- Snippets: Kopf- und Fußbereich werden einmal je Sprache gepflegt und überall eingebunden.
- Excerpt: Titel, Kurzbeschreibung und Icon für Teaser kommen aus Sulus Auszugsdaten. Listen und Navigation brauchen dafür keine zusätzlichen Felder.
Inhalte als Code
Für den Start einer Website legen wir Seitenbaum, Texte, Rechtstexte, SEO-Angaben und Blogbeiträge nicht von Hand im Admin an. Sie stehen als Daten im Projekt und werden per Konsolenbefehl eingespielt. Das hat mehrere Vorteile: Alle drei Sprachen haben nachweislich dieselbe Struktur, automatische Tests prüfen Vollständigkeit und Längen von Meta-Angaben, und eine Korrektur erreicht jede Umgebung auf demselben Weg wie Code. Danach übernimmt die Redaktion im Admin.
Blog und Suche
Blogbeiträge verwaltet Sulu als Artikel mit eigener Vorlage. Die Übersichtsseite ist eine normale Seite, die einen eigenen Controller nutzt.
Die Suche läuft über SEAL mit dem Loupe-Adapter. Der Index liegt als Dateien auf dem Server. Es gibt keinen zusätzlichen Suchdienst, der betrieben oder bezahlt werden muss, und keine Suchanfrage verlässt den Server.
Frontend und Betrieb
Die Ausgabe entsteht mit Twig. Für Styles nutzen wir Tailwind CSS 4, gebaut mit Vite. Tailwind durchsucht die Templates nach Klassennamen; nach Änderungen gehört deshalb immer ein neuer Build dazu. Schriften liefern wir selbst aus, sodass keine Anfragen an fremde Server gehen.
Ein paar Eigenheiten sollte man kennen:
- Drei Konsolen. Sulu trennt Admin-, Website- und generischen Kernel. Migrationen laufen über die Admin-Konsole, Caches müssen für Admin und Website getrennt geleert werden.
- MariaDB ist nicht MySQL. Die Datenbankverbindung muss die MariaDB-Version angeben. Sonst erzeugt Doctrine SQL, das MariaDB ablehnt.
- Konfiguration wird gecacht. Nach Änderungen an Webspace oder Vorlagen sind beide Caches zu leeren.
Ausgeliefert wird mit Deployer. Das Einspielen der Inhalte ist dabei ein eigener Schritt, den man bewusst auslöst.
Für wen sich das lohnt
Sulu passt besonders gut, wenn eine Website mehrere Sprachen hat, redaktionell gepflegt wird und später um eigene Funktionen wachsen soll. Für eine reine Visitenkarte ohne Pflegebedarf ist der Aufwand oft zu groß. Wo die Grenze liegt, klären wir im Gespräch.