Was ist neu an Sulu 3.0?
Sulu 3.0 ist kein gewöhnliches Feature-Update, sondern eines der größten Architektur-Updates in der Geschichte des CMS. 153.471 neue Zeilen Code ersetzen nun 265.104 gelöschte. Du brauchst kein PHPCR und Jackrabbit mehr, sondern kannst einfach SQL oder DQL verwenden. Für Entwickler:innen bedeutet das vor allem: weniger Spezialwissen, mehr vertraute Symfony-Standards und eine deutlich bessere Basis für Debugging, Wartung und zukünftige Weiterentwicklung.
Sulu 3.0 und moderne Content Management Systeme = bessere Developer Experience
In früheren Versionen mussten Teams zusätzlich zu Symfony auch PHPCR, Jackrabbit und eigene Konzepte rund um Content Storage verstehen. Das war mächtig, aber nicht immer intuitiv, vor allem für neue Entwickler:innen in einem bestehenden Sulu-Projekt.
Mit Sulu 3.0 wird vieles vertrauter. Inhalte können über Doctrine Entities, SQL, DQL und bekannte Datenbank-Tools analysiert werden. Das erleichtert nicht nur das Debugging, sondern auch Tests, Code Reviews und langfristige Wartung. Wenn etwas nicht funktioniert, muss man nicht mehr tief in ein separates Content-Repository eintauchen, sondern kann näher an den Werkzeugen arbeiten, die Symfony-Teams ohnehin täglich nutzen.
Gleichzeitig sollte das Update nicht unterschätzt werden. Sulu 3.0 bringt Breaking Changes mit sich, vor allem bei Projekten mit viel Custom-Code, direkten PHPCR-Abhängigkeiten, eigenen Bundles oder individuellen Templates. Das Upgrade ist also weniger ein schneller Composer-Befehl, sondern eine kontrollierte Migration auf eine modernere technische Basis.
Die wichtigsten Neuerungen in Sulu 3.0: Content Storage, Performance und neues Suchsystem
Neues Content Storage System: Von PHPCR zu Doctrine ORM
Der größte technische Wechsel in Sulu 3.0 ist der Abschied von PHPCR und Jackrabbit. Bisher wurden Inhalte über PHPCR verwaltet. Das konnte viele CMS-Anforderungen wie Hierarchien, Mehrsprachigkeit und Versionierung gut abbilden, war aber für viele Symfony-Entwickler:innen aber ungewohnt.
In Sulu 3.0 liegen Inhalte nun als Doctrine-ORM-Strukturen mit JSON-Feldern in der relationalen Datenbank. Pages, Articles und Snippets werden damit zu Doctrine Entities. Das macht den Content Storage zugänglicher und transparenter, dennInhalte lassen sich mit bekannten Tools abfragen, analysieren und debuggen.
Besonders relevant ist dabei auch das neue Konzept der „Dimensions“. Damit verwaltet Sulu unterschiedliche Zustände eines Inhalts, zum Beispiel Sprache, Version, Draft und Live-Status. Gerade bei mehrsprachigen Websites schafft das eine flexiblere und besser nachvollziehbare Grundlage für komplexe Content-Strukturen.
Performance Improvements
Der neue Content Storage bringt auch spürbare Performance-Vorteile. Laut Sulu-Benchmarks erreicht Sulu 3.0 im Vergleich zur bisherigen PHPCR-basierten Speicherung ungefähr den doppelten Durchsatz und etwa die halbe Latenz. Gerade bei größeren Projekten, vielen Inhalten oder komplexeren Content-Strukturen schafft das eine deutlich stabilere technische Grundlage.
Developer Experience
Für Entwickler:innen wird Sulu 3.0 vor allem nachvollziehbarer. Inhalte liegen nun in bekannten Datenbankstrukturen, können mit SQL, DQL und Doctrine-Tools analysiert werden und sind dadurch leichter zu debuggen. Für neue Entwickler im Projekt sinkt die Einstiegshürde, weil weniger Sulu-spezifisches Spezialwissen rund um PHPCR und Jackrabbit nötig ist.
Weitere wichtige Neuerungen
Flysystem 3 für flexiblere Media Storage
Sulu 3.0 aktualisiert Flysystem von Version 1 auf Version 3. Dadurch stehen deutlich mehr Storage-Adapter zur Verfügung. Medien können flexibler lokal, in Cloud-Storage oder in anderen angebundenen Systemen gespeichert werden. Bei Migrationen sollten bestehende Storage-Konfigurationen deshalb früh geprüft und angepasst werden.
Neu geschriebene Bundles
Alle Bundles, die bisher stark von PHPCR abhängig waren, wurden grundlegend überarbeitet. Dazu gehören unter anderem PageBundle, ArticleBundle, SnippetBundle und CustomURLBundle. Sie folgen nun moderneren Symfony-Strukturen, was die Architektur sauberer macht. Gleichzeitig kann Custom-Code brechen, wenn er alte Klassen, Services oder Namespaces direkt verwendet.
ArticleBundle ohne zwingendes Elasticsearch
Das ArticleBundle ist in Sulu 3.0 Teil des Core-Pakets und benötigt nicht mehr zwingend Elasticsearch. Für kleinere oder mittelgroße Projekte reduziert das die Infrastruktur-Komplexität deutlich, weil Artikel auch ohne zusätzliche Such-Infrastruktur genutzt werden können. Wer Elasticsearch weiterhin braucht, kann es separat anbinden.
Neues Suchsystem mit SEAL und Loupe
Auch die Suche wurde modernisiert. MassiveSearchBundle und ZendSearch fallen weg; stattdessen setzt Sulu 3.0 auf SEAL, die Search Engine Abstraction Layer. Standardmäßig kann Loupe genutzt werden, eine PHP-basierte Suchlösung mit SQLite. Für größere Projekte lassen sich weiterhin Systeme wie Elasticsearch, Meilisearch, Algolia oder Solr anbinden.
Neue Anforderungen an Umgebung und Dependencies
Mit Sulu 3.0 ändern sich auch technische Mindestanforderungen und Abhängigkeiten. Unterstützt werden neuere PHP- und Symfony-Versionen, außerdem können bei Custom Admin Builds oder CKEditor-Anpassungen aktualisierte Node-Setups relevant werden. Bei den Migrationen sollen Dependencies also nicht blind auf einmal aktualisiert werden, sondern Schritt für Schritt.
Migration auf Sulu 3.0
Sulu 3.0 sollte nicht wie ein klassisches Minor-Update behandelt werden. Dafür ändert sich unter der Haube zu viel: Content Storage, Bundles, Suche, Namespaces, Templates und teilweise auch eigene Projektlogik. Der beste Weg ist deshalb keine schnelle In-place-Migration, sondern ein kontrollierter, wiederholbarer Prozess.
Empfohlener Migrationsansatz
1. Projekt zuerst analysieren
Bevor die eigentliche Migration startet, sollte klar sein, wie stark das Projekt von alten Sulu- und PHPCR-Strukturen abhängt. Besonders wichtig ist die Frage, ob Custom-Code direkt auf PHPCR, Jackrabbit, DocumentManager, alte Bundle-Klassen, eigene Twig-Funktionen, Search-Konfigurationen oder Headless-APIs zugreift. Je individueller das Projekt aufgebaut ist, desto wichtiger wird diese Voranalyse.
2. Nicht direkt im bestehenden Projekt migrieren
Führe die Migration nicht direkt im bestehenden Projekt durch. Besser ist es, das Projekt zu klonen und eine separate Sulu-3.0-Umgebung aufzusetzen, während der bestehende Sulu-2.6-Stand unverändert bleibt. So kann die Migration mehrfach getestet, verglichen und bei Bedarf wiederholt werden.
Das hat den großen Vorteil, dass sich Fehler nachvollziehbar beheben lassen, ohne das produktive Projekt zu gefährden. Außerdem bleibt ein klarer Vergleich zwischen altem und neuem Stand möglich.
3. Zuerst auf den neuesten Sulu-2.6-Stand bringen
Vor dem Wechsel auf Sulu 3.0 sollte das bestehende Projekt auf die aktuelle Sulu-2.6-Version gebracht werden. Dazu gehören auch alle relevanten Bundles, PHPCR-Migrationen und ein Cleanup des PHPCR-Repositories.
Ein sauberer 2.6-Ausgangspunkt reduziert spätere Migrationsfehler deutlich. Je weniger Altlasten im Projekt liegen, desto leichter lässt sich erkennen, welche Änderungen tatsächlich durch Sulu 3.0 entstehen.
4. Dependencies und Bundles aufräumen
Mit Sulu 3.0 ändern sich einige Abhängigkeiten grundlegend. Alte Pakete wie das separate ArticleBundle, MassiveSearchBundle, ZendSearch oder Jackrabbit-spezifische Dependencies müssen geprüft und entfernt werden, wenn sie nicht mehr gebraucht werden. Gleichzeitig kommen neue oder aktualisierte Komponenten hinzu, etwa für SEAL, Loupe oder Flysystem.
Wichtig ist, diese Änderungen nicht blind gesammelt durchzuführen, sondern Schritt für Schritt. So lassen sich Composer-Konflikte, inkompatible Bundles oder falsche Versionen deutlich schneller identifizieren.
5. Konfiguration, Routen und Templates anpassen
Auch Konfigurationsdateien, Bundle-Registrierungen, Routen und Templates müssen geprüft werden. Einige Klassen liegen in neuen Namespaces, alte Routing-Definitionen können wegfallen und bestimmte Template-Eigenschaften haben sich geändert.
Besonders bei Projekten mit eigenen Templates, Artikelstrukturen, Navigationen oder Custom Routes lohnt sich ein systematischer Vergleich mit dem aktuellen Sulu-Skeleton. So wird sichtbar, welche Konfigurationen in Sulu 3.0 anders gelöst werden.
6. Datenmigration mit dem Sulu PHPCR Migration Bundle ausführen und testen
Die eigentliche Content-Migration erfolgt über das Sulu PHPCR Migration Bundle. Dabei werden Inhalte aus PHPCR in die neue Doctrine-ORM-Struktur übertragen. Dazu gehören unter anderem Pages, Articles, Snippets und Custom URLs.
Entscheidend ist aber nicht nur, dass die Migration technisch durchläuft. Entscheidend ist, ob echte Inhalte danach korrekt funktionieren. Deshalb sollte die Migration mit realistischen Produktionsdaten getestet werden, idealerweise mehrmals. Fehler können behoben und die Migration kann anschließend erneut ausgeführt werden, bis das Ergebnis stabil und nachvollziehbar ist.
7. Ergebnis systematisch testen
Nach der Migration sollte nicht nur der Admin starten. Es muss geprüft werden, ob Inhalte, URLs, Navigationen, Snippets, Artikel, Mehrsprachigkeit, Draft/Live-Stände, Suche, Rechte und Headless-Ausgaben weiterhin korrekt funktionieren.
Besonders hilfreich ist ein automatisierter Vergleich. Eine Sitemap kann vor und nach der Migration gecrawlt werden, um HTML-Output, Statuscodes und sichtbare Unterschiede zu prüfen. So fallen auch Probleme auf, die beim manuellen Durchklicken leicht übersehen werden.
8. Erst live gehen, wenn die Migration wiederholbar ist
Eine Migration ist erst dann bereit für den Go-live, wenn sie nicht nur einmal funktioniert hat, sondern zuverlässig wiederholbar ist. Im Idealfall wurde der Ablauf mehrfach mit denselben Produktionsdaten getestet, dokumentiert und geprüft. Dann ist der eigentliche Go-live kein Experiment mehr, sondern ein bekannter Prozess.
Typische Probleme und Lösungen bei der Migration auf Sulu 3.0
1. Composer- und Dependency-Konflikte
Ein häufiges Problem entsteht bereits beim Update der Abhängigkeiten. Sulu 3.0 bringt neue Anforderungen an PHP, Symfony, Doctrine, Search-Komponenten und verschiedene Bundles mit. Dadurch können Composer-Konflikte entstehen, vor allem wenn viele Projektbundles oder ältere Paketversionen im Einsatz sind.
Die Lösung ist ein schrittweises Vorgehen. Zuerst sollte das Projekt auf einen stabilen Sulu-2.6-Stand gebracht werden. Danach werden Dependencies gezielt aktualisiert, alte Pakete entfernt und projektindividuelle Bundles auf Sulu-3-Kompatibilität geprüft. Große Versionssprünge sollten nicht alle gleichzeitig passieren.
2. Custom-Code nutzt alte PHPCR- oder DocumentManager-Klassen
Viele ältere Sulu-Projekte enthalten Custom-Code, der direkt mit PHPCR, Jackrabbit oder dem DocumentManager arbeitet. Da Sulu 3.0 auf Doctrine ORM umstellt, können solche Stellen brechen oder fachlich nicht mehr korrekt funktionieren.
Hier reicht es nicht, nur Imports auszutauschen. Der Code sollte systematisch nach PHPCR, Jackalope, DocumentManager und alten Content-Klassen durchsucht werden. Anschließend muss geprüft werden, ob die Logik künftig über Doctrine Entities, Repositories, neue Services oder Domain Events abgebildet werden sollte.
3. Twig Templates funktionieren nicht mehr wie vorher
Auch in Twig kann es zu Problemen kommen, weil einige Funktionen umbenannt oder stärker aufgeteilt wurden. Alte Funktionen wie sulu_content_load müssen je nach Kontext durch spezifischere Varianten ersetzt werden, etwa für Pages oder Articles. Auch Navigation- und Content-Funktionen können andere Namen oder Parameter haben.
Die Lösung ist ein systematischer Template-Check. Alle alten Twig-Funktionen sollten gesucht, ersetzt und anschließend in echten Seitentypen getestet werden. Besonders wichtig sind Navigationen, Breadcrumbs, Snippets, Content-Teaser und dynamische Listen.
4. Artikel-URLs oder Blog-Pfade sind nach der Migration falsch
Bei Artikeln kann es passieren, dass URLs nach der Migration nicht mehr wie erwartet aufgebaut werden. Ein typisches Beispiel ist ein fehlender Blog-Prefix bei neu angelegten Artikeln. Der Grund liegt häufig in geänderten Template- oder route_schema-Konfigurationen.
Deshalb sollten Artikel-Templates besonders genau geprüft werden. Wichtig ist nicht nur, bestehende Inhalte aufzurufen, sondern auch neue Artikel nach der Migration anzulegen und zu veröffentlichen. Manche Probleme zeigen sich erst bei neuem Content.
5. Die Suche liefert falsche oder unvollständige Ergebnisse
Mit Sulu 3.0 fallen MassiveSearchBundle und ZendSearch weg. Das neue Suchsystem basiert auf SEAL, standardmäßig kann Loupe genutzt werden. Projekte mit bestehender Suchfunktion müssen ihre alte Search-Konfiguration daher aktiv ersetzen.
Löse dieses Problem, indem du alte Search-Dependencies und Konfigurationen enfernst, SEAL sauber einrichtest und je nach Projektgröße den passenden Adapter wählst. Für kleinere Projekte kann Loupe ausreichend sein, größere Setups können weiterhin Elasticsearch, Meilisearch, Algolia oder Solr anbinden. Nach der Migration sollte der Index neu aufgebaut und die Suche mit realen Suchbegriffen getestet werden.
6. SmartContent filtert Tags oder Kategorien falsch
Dynamische Content-Listen können nach der Migration anders reagieren, vor allem wenn sie nach Tags, Kategorien oder Template-Gruppen filtern. Das betrifft zum Beispiel Artikelübersichten, Related Content oder automatisch generierte Listen.
Hier hilft ein gezielter Test aller SmartContent-Blöcke. Besonders wichtig sind Seiten, auf denen Inhalte nicht manuell ausgewählt, sondern automatisch gefiltert werden. Wenn Filter nicht greifen oder zu viele Inhalte angezeigt werden, sollte zuerst auf die aktuelle Sulu-3-Patch-Version aktualisiert und danach die jeweilige Konfiguration geprüft werden.
7. Textfelder mit JSON, Code oder Sonderzeichen werden beschädigt
Bei Migrationen können Textfelder problematisch sein, wenn sie JSON, Codeblöcke oder Sonderzeichen enthalten. Werden Inhalte falsch decodiert oder interpretiert, können sie nach der Migration beschädigt sein, obwohl die Seite auf den ersten Blick normal wirkt.
Deshalb sollten entsprechende Felder gezielt geprüft werden. Besonders sinnvoll sind automatisierte Diff-Tests zwischen altem und neuem HTML-Output. So fallen auch kleine Abweichungen auf, die visuell leicht übersehen werden.
8. Berechtigungen fehlen oder greifen anders
In Sulu 3.0 ändern sich einige Strukturen rund um Artikel, Snippets und Template Groups. Dadurch kann es passieren, dass Rollen nach der Migration nicht mehr dieselben Rechte haben oder bestimmte Bereiche im Admin nicht wie erwartet sichtbar sind.
Die Lösung ist ein gezielter Rollen- und Permission-Test. Admin-User, Redakteur:innen und eingeschränkte Rollen sollten separat geprüft werden. Wichtig ist auch, neue Template Groups, Snippet Areas und Permission-Kontexte sauber zu konfigurieren.
9. Headless-Frontends zeigen andere Daten als vorher
Bei Headless-Projekten betrifft die Migration nicht nur Sulu selbst, sondern auch das angebundene Frontend. APIs, URLs, SEO-Felder, Media-Ausgaben, Teaser, Snippets oder Draft/Live-Stände können sich anders verhalten als zuvor.
Hier sollte man API-Responses vor und nach der Migration vergleichen. Zusätzlich lohnt sich ein Crawl der wichtigsten URLs sowie ein Snapshot-Vergleich im Frontend. Gerade bei Headless-Setups ist wichtig, nicht nur den Sulu-Admin zu testen, sondern den gesamten Ausgabekanal.
10. Custom Admin Builds oder CKEditor-Plugins brechen
Wenn ein Projekt eigene Admin-Anpassungen, Custom Views oder CKEditor-Plugins nutzt, können nach dem Update Build-Probleme auftreten. Neue Versionen und Build-Anforderungen können dazu führen, dass der Admin zwar grundsätzlich startet, einzelne Felder oder Editor-Funktionen aber nicht korrekt funktionieren.
Die Lösung ist ein vollständiger Admin-Test. Der Build sollte neu ausgeführt, die Node-Version geprüft und jede eigene Admin-Erweiterung aktiv getestet werden. Besonders wichtig sind Formulare, Blöcke, Media-Felder, Rich-Text-Felder und eigene CKEditor-Plugins.
Testing-Strategie für eine sichere Migration
Eine Sulu-3.0-Migration ist nicht automatisch erfolgreich, nur weil Composer durchläuft, die Datenmigration keine Fehler ausgibt und der Admin wieder erreichbar ist. Erfolgreich ist sie erst dann, wenn echte Inhalte, echte URLs und echte Redaktionsprozesse zuverlässig funktionieren.
Wann ist eine Migration erfolgreich?
Eine Migration kann als erfolgreich gelten, wenn folgende Punkte geprüft wurden:
1. Die wichtigsten URLs funktionieren wie vorher
Startseite, Landingpages, Artikelseiten, Detailseiten, Snippets, Custom URLs und zentrale Navigationspunkte sollten nach der Migration erreichbar sein. Dabei geht es nicht nur um den Statuscode, sondern auch darum, ob der sichtbare Output plausibel ist.
Besonders sinnvoll ist ein Vergleich der Sitemap vor und nach der Migration. So lässt sich prüfen, ob URLs fehlen, Weiterleitungen falsch greifen oder Seiten plötzlich anders ausgeliefert werden.
2. Der HTML-Output wurde verglichen
Ein manueller Klicktest reicht bei größeren Projekten selten aus. Besser ist ein automatisierter Vergleich, bei dem jede relevante URL vor und nach der Migration abgerufen und der HTML-Output miteinander verglichen wird.
Nicht jede Abweichung ist automatisch ein Fehler. Aber unerwartete Unterschiede werden dadurch sichtbar, wie beispielsweise fehlende Snippets, veränderte Teaser, falsche Links, andere Canonicals oder Probleme bei dynamischen Listen.
3. Mehrsprachigkeit und Content-Dimensionen funktionieren
Gerade bei mehrsprachigen Sulu-Projekten sollte jede Sprache gezielt getestet werden. Dazu gehören Sprachversionen, Fallbacks, übersetzte URLs, Navigationen, SEO-Felder und der Wechsel zwischen Draft- und Live-Ständen.
4. Redaktionsprozesse funktionieren im Admin
Eine Migration ist erst dann wirklich stabil, wenn Redakteur:innen weiterhin mit dem System arbeiten können. Deshalb sollte nicht nur bestehender Content geprüft werden. Es sollten auch neue Inhalte angelegt, bearbeitet, gespeichert, veröffentlicht und wieder deaktiviert werden.
Dabei sollten typische Content-Elemente getestet werden wie Textfelder, Blöcke, Medien, Snippets, Teaser, Artikel, Kategorien, Tags und Rich-Text-Felder.
5. Suche, Filter und dynamische Inhalte liefern korrekte Ergebnisse
Wenn das Projekt eine Suchfunktion nutzt, muss der Suchindex neu aufgebaut und mit realistischen Suchbegriffen getestet werden. Auch dynamische Content-Listen, Related Content, Tag-Filter, Kategorie-Filter und SmartContent-Blöcke sollten gezielt geprüft werden.
Falls ein Projekt keine Suche oder keine dynamischen Listen nutzt, kann dieser Teil entsprechend kleiner ausfallen. Die Testing-Strategie sollte immer zur tatsächlichen Website passen.
6. Rollen und Berechtigungen wurden geprüft
Bei Projekten mit mehreren Rollen reicht ein Test mit einem Admin-User nicht aus. Redakteur:innen, eingeschränkte Rollen und projektindividuelle Berechtigungen sollten separat getestet werden.
Besonders wichtig sind Rechte für Artikel, Snippets, Template Groups, Medien und Veröffentlichungsprozesse. Wenn nur ein Admin-User existiert, ist dieser Test weniger relevant. Sobald aber mehrere Rollen im Einsatz sind, sollte er fix eingeplant werden.
7. Headless- oder API-Ausgaben bleiben stabil
Bei Headless-Projekten muss zusätzlich geprüft werden, ob das Frontend weiterhin die erwarteten Daten erhält. Dafür sollten API-Responses vor und nach der Migration verglichen werden.
Wichtig sind vor allem URLs, SEO-Daten, Medien, Teaser, Snippets, Navigationen, Draft/Live-Stände und sprachabhängige Inhalte. Eine Migration kann im Sulu-Admin korrekt aussehen und trotzdem im Frontend Unterschiede erzeugen.
8. Logs und Migration Output sind sauber
Nach der Migration sollten Logs, Deprecations, Fehlerausgaben und Migration Reports geprüft werden. Warnungen sind nicht immer kritisch, sollten aber verstanden und dokumentiert werden.
Eine stabile Migration bedeutet nicht nur, dass keine sichtbaren Fehler auftreten, sondern auch, dass im Hintergrund keine unerklärten Probleme liegen bleiben.
Woher weiß ich, dass wirklich alles funktioniert?
Absolute Sicherheit gibt es bei komplexen Migrationen selten. Aber man kann das Risiko stark reduzieren, wenn die Migration wiederholbar, dokumentiert und mit echten Daten getestet wurde.
Besonders hilfreich ist dabei ein strukturierter Testplan:
- Sitemap vor und nach der Migration crawlen
- HTML-Output vergleichen
- zentrale Seitentypen manuell prüfen
- neue Inhalte im Admin anlegen und veröffentlichen
- Mehrsprachigkeit testen
- Redirects, Canonicals und SEO-Felder prüfen
- Suche und Filter testen, falls vorhanden
- Rollen und Berechtigungen testen, falls relevant
- Headless- oder API-Ausgaben vergleichen, falls im Einsatz
- Logs und Migration Output prüfen
Je komplexer das Projekt ist, desto wichtiger werden automatisierte Tests und Vergleichsskripte. Bei kleineren Websites reicht oft ein schlankerer Testplan. Die ersten beiden Punkte „Sitemap crawlen“ und „Output vergleichen“ sollten aber in fast jeder Migration fix eingeplant werden.
Fazit
Sulu 3.0 ist ein großer Schritt nach vorne: moderner Content Storage, vertrautere Symfony-Workflows, bessere Wartbarkeit, Flexibilität und eine technische Basis, die für kommende Projekte deutlich mehr Spielraum schafft. Gleichzeitig ist der Umstieg kein Update, das man nebenbei erledigt. Wer ein bestehendes Sulu-Projekt migriert, sollte Abhängigkeiten, Custom-Code, Templates, Datenmigration und Testing sauber planen.
Genau hier lohnt sich Erfahrung. Wir begleiten Sulu-Projekte nicht nur technisch, sondern denken auch an Redaktion, Betrieb, Performance und langfristige Wartbarkeit mit. Wenn ihr wissen wollt, ob und wie euer Projekt bereit für Sulu 3.0 ist: Schreibt uns. Wir schauen uns das gerne gemeinsam mit euch an.
