Gestern war ich schockiert, als ich einen etablierten TYPO3-Experten sagen hörte: „Kennst du das, wenn du eine TYPO3-Website aktualisierst und dann ruft der Kunde an, weil die Website nicht mehr läuft".
Auch wenn dieser Mensch das Problem vermutlich selbst nicht hat, weil er ein bekannter Profi ist, und er das Argument nur benutzt hat, um seinen Newsletter zu bewerben, legt es ein tieferes und sehr reales Problem offen: Leute, die CM-Systeme aufsetzen, haben oft keine Ahnung, wie man eine vernünftige Entwicklungsumgebung oder ein CI/CD-System einrichtet!
Das ist nicht nur ein TYPO3-Problem. Es gibt es genauso bei WordPress, Drupal und wie sie alle heißen.
Wie es oft gemacht wird und warum das falsch ist!
Auch 2025 gibt es „Entwickler" da draußen, die ein CMS über irgendeine „Ein-Klick-Installation" installieren oder einfach den Basiscode auf ihre Server schieben und dann über die eingebauten Extension-Manager, -Repos und -Stores Extensions und Templates auf einem Live-Produktivsystem installieren, ohne sie vorher zu testen.
Für deine private Website, deinen Verein oder das Rezepteblog deiner Mutter kann das gutgehen, aber für eine professionelle Firmenwebsite, die Geld verliert, wenn sie offline geht, funktioniert das definitiv nicht.
Man testet einfach nicht in Produktion!
Und nein, eine „Stage- oder Firewall-Extension" macht das nicht sicherer! Wenn du Sachen auf einem Live-System installierst, testest du immer noch auf einem Live-System!
Wie lösen wir das?
Indem du grundlegende Prinzipien der Softwareentwicklung anwendest, wirst du (fast) nie wieder das Problem haben, dass deine Live-Website ausfällt, weil du nur mal „schnell diese Extension ausprobieren" oder „nur ein Update machen" wolltest.
In diesem Blogpost zeige ich dir die Grundlagen, wie du eine kugelsichere TYPO3-Umgebung aufsetzt, die sich aktualisieren lässt und getestet ist, bevor du live gehst.
Lokale Entwicklung
Da wir Dinge nicht auf Produktion ausprobieren wollen, brauchen wir eine lokale Entwicklungsumgebung. Dafür empfehle ich:
- Docker
- Composer
- PhpStorm
- Git und GitLab
- Xdebug
- PHPUnit
Wenn du mit Docker nicht vertraut bist, kannst du für die lokale Entwicklung auch DDEV nehmen, aber ich bin davon kein großer Fan (warum, erkläre ich vielleicht in einem anderen Beitrag).
Stage
Wir fahren einen Drei-Stufen-Ansatz. Die erste Stufe ist unsere lokale Entwicklung, die zweite die eigentliche Stage und die letzte das Live-System.
Das Stage-System bekommt eine Kopie der Live-Datenbank (sofern keine sensiblen Daten darin sind) und dient als unser Testgelände. Alle Einstellungen und Konfigurationen sollten dieselben sein wie in der Produktionsumgebung.
Du kannst ein anderes Log-Level fahren, das beim Debuggen hilft
Testen
1. Automatisiertes Testen
Testen ist etwas, das jeder Entwickler hasst. Da wir hier höchstwahrscheinlich nicht über die Entwicklung von Extensions oder anderem Core-Code auf hoher Ebene reden, brauchst du vermutlich keine Unit- oder Integrationstests.
Es ist aber gute Praxis, zumindest eine Art Funktionstests zu haben und sie beim Deployment laufen zu lassen. Die können so einfach sein wie: eine Route aufrufen und prüfen, ob der Rückgabecode 200 ist.
public function testBasicRoute()
$crawler = $client->request('GET', '/');
$this->assertStatusCode(200, $client);
}
2. Manuelles Testen
Wenn du keine automatisierten Tests schreiben willst, dann lass deinen Kunden/Stakeholder/wen auch immer das System für dich testen. Genau dafür ist die Stage nämlich da. Schick ihnen einen Link zum Stage-Server, auf dem sie deine Änderungen sehen und überprüfen können, und lass sie draufschauen.
Ich empfehle immer, das nicht deine Kollegen oder dich selbst machen zu lassen. Du bist womöglich zu nah am Code und am Problem und siehst Probleme gar nicht, die normale Nutzer haben werden. Lass immer jemanden testen, der eher Nutzer als Entwickler ist.
Deployment
Um endgültig sicherzustellen, dass nach Änderungen nichts kaputtgeht, solltest du ein ordentliches Deployment aufsetzen. Dafür kannst du nehmen, was du magst — von GitLab-Pipelines über Deployer bis hin zu einem Bash-Skript.
Der Punkt ist: Automatisier es! Stell sicher, dass du keine notwendigen Schritte vergisst, und stell auch sicher, dass das Deployment abbricht, wenn dabei etwas kaputtgeht, statt deine Website mit runterzureißen.
Wie du siehst, muss es bei meinen Deployments nicht mal besonders kompliziert sein. Nachdem auf der Stage und dem dev-Branch getestet wurde, merge ich dev direkt in master, und das löst ein automatisches Deployment der neuesten Änderungen aus.
Backups
Uuuund zu guter Letzt: Du brauchst Backups! Da die meisten CMS nicht sonderlich kompliziert sind, musst du höchstwahrscheinlich nur deine Datenbank und dein Dateisystem sichern. Dein Provider sollte irgendeine Backup-Option haben. Wenn nicht: such dir einen anderen.
Aber selbst wenn dein Provider so etwas hat, solltest du trotzdem dein eigenes machen — für alle Fälle. Es ist nicht schwer: alle Dateien herunterladen und eine Kopie der Datenbank ziehen. Die kannst du dann sogar für die lokale Entwicklung nutzen.
Kein Backup — kein Mitleid!
Fazit
Dieser Beitrag war nur ein sehr oberflächlicher Überblick über ein paar Dinge, die du tun solltest, um deine TYPO3-Entwicklung und -Wartung sicherer zu machen. Ein echter Deep Dive in die Details wäre für dieses kleine Blog viel zu lang. Wenn du oder deine Agentur mit diesem Prozess kämpfst, kann ich dabei helfen und dir eine passgenaue DevOps-Lösung bauen, die alles abdeckt — von deiner lokalen Umgebung mit Docker über den Server bis zur Live-Website. Melde dich einfach, dann reden wir.