Von Symfony, Pimcore oder Shopware zu TYPO3

Ein potenzieller Kunde kommt selten mit einem Briefing, das sagt: „Wir wollen TYPO3." Stattdessen beschreibt er die Website, die er braucht.

Sie muss vielleicht mehrere Marken, Websites, Märkte oder Sprachen unterstützen. Verschiedene Redaktionsteams brauchen möglicherweise sorgfältig gesteuerte Berechtigungen und Freigabe-Workflows. Die Plattform muss sich eventuell mit Produktdaten, CRM, Commerce oder anderen Geschäftssystemen integrieren. Sie muss ein vollständig individuelles Design ermöglichen, über Jahre wartbar bleiben und vermeiden, die Organisation an eine proprietäre Plattform zu binden.

Das ist die Art umfangreicher Enterprise-Website, für die TYPO3 eine der stärksten Open-Source-CMS-Optionen sein kann.

Viele Agenturen ziehen TYPO3 jedoch nie in ihre Bewertung ein. Nicht, weil die Plattform ungeeignet wäre, sondern weil sie noch kein TYPO3-Wissen im Team haben.

Infolgedessen empfiehlt eine Agentur womöglich die Plattform, die sie bereits kennt, statt der Plattform, die am besten zum Projekt passt. Sie versucht vielleicht, ein Commerce- oder Datenmanagement-System weiter ins Content-Management auszudehnen, baut teure Redaktionsfunktionen selbst oder wählt ein CMS, das mit wachsenden Anforderungen einschränkend wird.

Das fehlende Teil ist nicht zwingend eine andere Plattform. Es ist der Zugang zur richtigen Expertise.

Ihr braucht keine TYPO3-Abteilung, um TYPO3 vorzuschlagen

Wenn eure Entwickler:innen bereits mit Symfony, Pimcore, Shopware oder einem anderen Symfony-basierten System arbeiten, ist der Umstieg auf TYPO3 ein kleinerer Schritt, als es zunächst scheint.

TYPO3 hat seine eigene Architektur und CMS-spezifische Konzepte, aber seine moderne Entwicklungsumgebung teilt viele Grundlagen mit dem breiteren Symfony-Ökosystem: Composer, Dependency Injection, Service-Konfiguration, Console Commands, Symfony-Routing-Komponenten, Doctrine DBAL und ereignisgesteuerte Erweiterungspunkte.

Eure Entwickler:innen fangen nicht wieder bei null an. Mit einem erfahrenen TYPO3-Partner, der die Architektur und die erste Umsetzung begleitet, kann ein bestehendes PHP-Team bereits mitarbeiten, während es die plattformspezifischen Konzepte von TYPO3 in der Praxis lernt.

Genau das sollte aus unserer Sicht ein offizieller TYPO3 Consultant Partner für Agenturen leisten. Unsere Mission bei Digital Zombies ist es nicht, die Entwickler:innen, Designer:innen oder Kundenbeziehungen einer Agentur zu ersetzen. Es geht darum, TYPO3 zu einer realistischen Option zu machen, wenn es die richtige Wahl für das Projekt ist.

Wir liefern das Spezialwissen, das für die unmittelbare Arbeit nötig ist, arbeiten mit dem bestehenden Team zusammen und geben Wissen weiter, damit dessen Entwickler:innen zunehmend sicher mit TYPO3 werden. So kann eine Agentur die richtigen Enterprise-Chancen verfolgen, ohne vor dem ersten Projekt eine ganze TYPO3-Abteilung einzustellen.

Wann gehört TYPO3 auf die Shortlist?

Nicht jede Website braucht ein Enterprise-CMS. TYPO3 wird besonders überzeugend, wenn sich die Komplexität nicht auf das Frontend beschränkt. Es verdient ernsthafte Beachtung, wenn ein Projekt mehrere der folgenden Punkte umfasst:

mehrere Websites, Marken, Geschäftsbereiche oder regionale Auftritte;
mehrsprachige Inhalte und Lokalisierungs-Workflows;
Redakteur:innen mit unterschiedlichen Rollen, Rechten und Verantwortlichkeiten;
Prüf- und Freigabeprozesse vor der Veröffentlichung;
strukturierte Inhalte, die über eine große Plattform hinweg konsistent bleiben müssen;
individuelle Integrationen mit Geschäftssystemen und externen Diensten;
eine lange erwartete Plattform-Lebensdauer;
Anforderungen an Erweiterbarkeit und kontrollierte, wartbare Releases;
eine Präferenz für professionelle Open-Source-Software und weniger Vendor-Lock-in.

TYPO3 wurde für inhaltsreiche Umgebungen gebaut, in denen Governance ebenso wichtig ist wie das Publizieren. Multisite-Management, Lokalisierung, granulare Zugriffsrechte und Workspaces sind keine nachträglichen Ergänzungen, die eine Agentur für jedes Enterprise-Projekt neu bauen muss.

Gleichzeitig ist TYPO3 hochgradig erweiterbar. Es kann die Content-Plattform innerhalb eines größeren technischen Ökosystems sein, statt jedes spezialisierte Geschäftssystem drumherum ersetzen zu wollen. Diese Unterscheidung ist für Agenturen wichtig, die bereits mit Pimcore oder Shopware arbeiten.

Pimcore kann für Produktinformationen, digitale Assets oder Stammdaten zuständig bleiben. Shopware kann die Commerce-Plattform bleiben. TYPO3 kann die Verantwortung für komplexe redaktionelle Erlebnisse, Unternehmensinhalte, mehrere Sites und die zugehörigen Workflows übernehmen. Die richtige Architektur zwingt nicht eine Plattform, jedes Problem zu lösen.

Von einem unbekannten CMS zu einer benachbarten Fähigkeit

Für eine Agentur, die bereits mit Symfony-basierten Plattformen baut, sollte TYPO3 nicht als völlig getrennte technische Welt betrachtet werden.

Ein Pimcore-Team versteht Composer-Projekte, Symfony-Services, Controller, Events und strukturierte Daten. Ein Shopware-Team versteht Symfony-basierte Extension-Entwicklung, Dependency Injection, Console Commands und komplexe Integrationen. Ein Symfony-Anwendungsteam arbeitet bereits mit vielen der zugrunde liegenden Komponenten, die TYPO3 nutzt. Mehrere technische Konzepte fühlen sich von Anfang an vertraut an.

Composer-basiertes Projektmanagement

Professionelle TYPO3-Projekte werden mit Composer installiert und gepflegt. Abhängigkeiten sind explizit, Extensions lassen sich sauber paketieren, und die Projektkonfiguration gehört in die Versionskontrolle. Für Teams, die Symfony, Pimcore oder Shopware gewohnt sind, ist das normale Anwendungsentwicklung — kein CMS, das über manuelle Uploads und Änderungen auf dem Produktivsystem gepflegt wird.

Dependency Injection und Services

TYPO3 nutzt die DependencyInjection-Komponente von Symfony und unterstützt Service-Konfiguration über Services.yaml. Constructor Injection ist der empfohlene Ansatz. Entwickler:innen können weiterhin fokussierte, testbare Services mit expliziten Abhängigkeiten schreiben. Die umgebenden Konventionen sind nah genug an Symfony, dass das mentale Modell schnell übertragbar ist.

Console Commands

TYPO3 nutzt die Symfony-Console-Komponente für Kommandozeilen-Funktionalität. Eigene Commands für Importe, Synchronisation, geplante Prozesse und Wartungsaufgaben nutzen eine API, die Symfony-orientierte Entwickler:innen bereits kennen.

Routing

TYPO3 fügt CMS-spezifische Aufgaben wie seitenbasierte URLs und Route Enhancements hinzu, aber sein Frontend-Routing ist mit Symfony-Routing-Komponenten umgesetzt. Die Plattform führt eine content-bewusste Schicht ein, ohne vertraute technische Grundlagen aufzugeben.

Doctrine DBAL

TYPO3 stellt Datenbankverbindungen und einen QueryBuilder auf Basis von Doctrine DBAL bereit. Entwickler:innen mit Doctrine-Erfahrung erkennen den Stil wieder, auch wenn TYPO3 keine typische Symfony-und-Doctrine-ORM-Anwendungsarchitektur reproduziert.

Events und Erweiterungspunkte

TYPO3 stellt PSR-14-Events bereit, um Core- und Third-Party-Verhalten zu erweitern. Die API unterscheidet sich vom EventDispatcher von Symfony, aber das architektonische Prinzip ist vertraut: auf definierte Events über Listener reagieren, statt Core-Code zu ändern.

Diese Ähnlichkeiten machen TYPO3 nicht identisch mit Symfony, Pimcore oder Shopware. Sie machen es zugänglich.

Individuelles Design, ohne auf ein ausgereiftes CMS zu verzichten

Ein hartnäckiges Missverständnis über Enterprise-Content-Management-Systeme ist, dass stärkere redaktionelle Fähigkeiten zwangsläufig weniger kreative Freiheit bedeuten. Bei TYPO3 muss das nicht so sein.

TYPO3 gibt nicht vor, wie eine Website aussehen soll. Sein Fluid-Templating-System gibt Frontend-Entwickler:innen die Flexibilität, ein vollständig individuelles Design umzusetzen, während TYPO3 die Inhalte, Berechtigungen, Lokalisierung und redaktionellen Workflows dahinter verwaltet.

Wiederverwendbare Content-Elemente lassen sich um die visuelle Sprache des Projekts herum gestalten, statt das Design in ein vordefiniertes Theme oder einen generischen Page-Builder zu zwingen. Redakteur:innen erhalten praktische Flexibilität, während das Designsystem die nötigen Leitplanken bietet, um Konsistenz über die Website hinweg zu wahren.

Besonders gut funktioniert das aus unserer Erfahrung in der Zusammenarbeit mit design- und UX-geführten Agenturen. In einem solchen Projekt erstellte die Agentur das komplette Design und die User Experience, während Digital Zombies die TYPO3-Umsetzung übernahm. Wir übersetzten das Design der Agentur in wiederverwendbare Fluid-Komponenten und redakteursfreundliche Content-Elemente, ohne das beabsichtigte Erlebnis zu verwässern.

Die Aufgabenteilung funktionierte selbstverständlich. Die Agentur behielt die Verantwortung für Strategie, Design und Kundenbeziehung. Wir lieferten die TYPO3-Architektur und Entwicklungsexpertise hinter der Umsetzung. Das Ergebnis war kein Kompromiss zwischen einer individuellen Website und einem Enterprise-CMS. Es war ein individuelles digitales Erlebnis, gestützt von einer ausgereiften Content-Plattform.

Fluid und Extbase bieten einen strukturierten Weg zu bauen

Designfreiheit ist nur nützlich, wenn die Umsetzung wartbar bleibt.

Fluid ist die Templating-Engine von TYPO3. Sie unterstützt Layouts, Templates, Partials und wiederverwendbare ViewHelper und gibt Frontend-Entwickler:innen einen strukturierten Weg, ein komponentenbasiertes Design in TYPO3 zu übertragen.

Für individuelle Anwendungsfunktionalität bietet Extbase TYPO3-orientierte MVC-Konzepte wie Controller, Repositories, Domain-Modelle und Validierung. Es ist nicht Symfony, und Entwickler:innen sollten nicht versuchen, Symfony-Muster in jedes TYPO3-Problem zu zwingen. Aber erfahrene PHP-Entwickler:innen erkennen die Trennung der Verantwortlichkeiten und finden viele Konzepte zugänglich.

TYPO3 verlangt auch nicht, dass jede individuelle Funktion Extbase nutzt. Entwickler:innen können direkt mit den Core-APIs und Services von TYPO3 arbeiten, wenn das die bessere architektonische Wahl ist.

Der wichtige Punkt ist, dass individuelle TYPO3-Entwicklung denselben Engineering-Werten folgen kann, die ein starkes Symfony-Team bereits anwendet: Trennung der Zuständigkeiten, explizite Abhängigkeiten, Code Review, Testing, Versionskontrolle und automatisiertes Deployment.

Wissen kann weitergegeben werden — nicht hinter einer Mauer gehalten

Unsere zweite Agentur-Erfahrung zeigt, warum diese Vertrautheit wichtig ist.

Die Agentur hatte TYPO3-Projekte zu pflegen und zu erweitern, aber intern nicht mehr genügend TYPO3-Kapazität. Zunächst lieferten wir das Spezialwissen und die Umsetzungskapazität, um diese Projekte am Laufen zu halten.

Unsere Rolle ging über das Abarbeiten von Tickets hinaus. Wir arbeiteten Seite an Seite mit den Entwickler:innen der Agentur, erklärten die relevanten TYPO3-Konzepte und -Konventionen, prüften Umsetzungen und halfen ihnen, die bestehende Codebasis zu verstehen. Da die Entwickler:innen bereits solide PHP- und Symfony-nahe Erfahrung hatten, konnten sie unbekannte TYPO3-Konzepte mit Engineering-Prinzipien verbinden, die sie schon kannten.

Mit der Zeit konnten sie beitragen, statt dauerhaft von einem externen TYPO3-Team abhängig zu bleiben.

Das ist eine wichtige Überlegung für Agentur- und Technologie-Verantwortliche. Einen Spezialpartner hinzuzuziehen sollte nicht bedeuten, eine neue Blackbox zu schaffen. Der Partner sollte die unmittelbare Lieferung sichern und zugleich das eigene Team der Agentur leistungsfähiger machen.

Was eure Entwickler:innen dennoch lernen müssen

Es wäre irreführend zu behaupten, Symfony-Erfahrung nehme die TYPO3-Lernkurve vollständig weg. Entwickler:innen begegnen plattformspezifischen Konzepten:

TCA definiert, wie Datensätze im TYPO3-Backend strukturiert, dargestellt und verwaltet werden.
TypoScript konfiguriert das Rendering von Inhalten und Aspekte des Site-Verhaltens.
Fluid ersetzt den Twig-basierten Templating-Ansatz, der von Symfony-Plattformen bekannt ist.
Extbase stellt ein TYPO3-spezifisches MVC-Framework für die Extension-Entwicklung bereit.
Sitepackages und Extensions enthalten projektspezifische Konfiguration, Präsentation und Funktionalität.
Der Seitenbaum, Workspaces, Berechtigungen und das Lokalisierungsmodell spiegeln die Anforderungen von Redakteur:innen und größeren Organisationen wider.

Diese Konzepte sind keine unnötigen Hürden. Sie sind Teil davon, wie TYPO3 Content-Management-Probleme löst, die eine maßgeschneiderte Symfony-Anwendung sonst selbst lösen müsste.

Der schnellste Weg ist nicht, jede vertraute Konvention wörtlich zu übertragen. Es ist zu verstehen, welche Prinzipien direkt übertragbar sind, welche TYPO3-APIs genutzt werden sollten und wo das CMS bereits die richtige Abstraktion bietet. Genau hier macht erfahrene Begleitung den größten Unterschied.

Ein praktischer Weg, TYPO3 zu evaluieren

Eine Agentur muss ein großes Kundenprojekt nicht einer unbekannten Plattform anvertrauen, ohne die Passung vorher zu testen. Eine fokussierte technische Evaluation kann klein genug sein, um sie ohne langwierige interne Initiative abzuschließen:

Wählt ein realistisches Enterprise-Briefing oder einen abgegrenzten Teil eines kommenden Projekts.
Identifiziert die Anforderungen, die wirklich ein CMS brauchen: Inhaltsstruktur, Sprachen, Berechtigungen, Workflows und Integrationen.
Installiert ein aktuelles TYPO3-Projekt mit Composer.
Baut ein Sitepackage, statt Third-Party-Code zu verändern.
Setzt eine echte Design-Komponente als individuelles, redakteursfreundliches Content-Element um.
Fügt einen kleinen Service, eine Integration oder ein Console Command hinzu.
Lasst sowohl Entwickler:innen als auch Redakteur:innen das Ergebnis bewerten.

Das zeigt weit mehr als eine generische Produktdemonstration. Es zeigt, ob TYPO3 zu den Entwicklungspraktiken der Agentur passt, wie viel Designfreiheit erhalten bleibt und was die redaktionelle Erfahrung werden kann, wenn sie bewusst gestaltet wird.

Mit einem beteiligten TYPO3-Spezialisten kann die Evaluation außerdem eine solide Architektur etablieren, statt einen Proof of Concept zu produzieren, der später verworfen werden muss.

Was ein offizieller TYPO3 Consultant Partner leisten sollte

Für uns ist der Status als offizieller TYPO3 Consultant Partner nicht einfach ein Gütesiegel. Er beschreibt die Rolle, die wir im Ökosystem einnehmen wollen.

Agenturen sollten TYPO3 vorschlagen können, wenn es die richtige Plattform für ihre Kunden ist — auch wenn sie noch nicht die gesamte nötige Erfahrung intern haben.

Unsere Aufgabe ist es, diese Lücke zu schließen. Wir können eine Evaluation begleiten, die Architektur gestalten, das Projekt umsetzen, eine bestehende Plattform pflegen oder im Hintergrund als Teil des Lieferteams der Agentur arbeiten. Ebenso wichtig: Wir teilen unser Wissen, damit die Entwickler:innen der Agentur mit Zuversicht mehr Verantwortung übernehmen können.

Das unmittelbare Ziel ist ein erfolgreiches Projekt. Das langfristige Ziel ist ein leistungsfähigeres und selbstbewussteres Agenturteam.

Wenn eure Agentur mit Symfony, Pimcore, Shopware oder einer anderen modernen PHP-Plattform arbeitet, ist TYPO3 euren bestehenden Fähigkeiten vielleicht viel näher, als ihr denkt. Und wenn ein Enterprise-Briefing nach TYPO3 aussieht, aber die fehlende Expertise euch bremst, ist das genau das Gespräch, das wir gerne führen würden.

Denkt ihr für ein Enterprise-Projekt über TYPO3 nach?

Sprecht mit Digital Zombies über das Projekt, die technischen Anforderungen oder eine fokussierte TYPO3-Evaluation.

Gespräch beginnen

Das Enterprise-CMS, für das euer Symfony-Team vielleicht schon bereit ist