Warum kann ein kleines TYPO3-Projekt teuer sein?

Wenn eine Website nur 20 oder 30 Seiten hat, klingt ein TYPO3-Update erstmal nach einem kleinen Projekt. Das kann stimmen. Es kann aber genauso gut sein, dass hinter diesen wenigen Seiten deutlich mehr Technik steckt als bei einer Website mit mehreren tausend normalen Inhaltsseiten.

Der Grund ist einfach: Die sichtbare Größe einer Website sagt nur wenig darüber aus, wie aufwendig ihr Update wird. Entscheidend ist, was im Hintergrund passiert. Individuelle Extensions, externe Schnittstellen, spezielle Formulare, Imports, Loginbereiche, alte Templates oder technisch überholte Strukturen können auch ein kleines Projekt schnell aufwendig machen.

Ein kleiner Seitenbaum sagt wenig über den technischen Aufwand aus

TYPO3 speichert Inhalte im Backend und gibt sie im Frontend wieder aus. Auf den ersten Blick wirkt das simpel. Der Weg dazwischen kann aber sehr unterschiedlich aussehen.

Bei einer einfachen Website bestehen die Seiten vielleicht fast nur aus Standard-Inhaltselementen. Dann ist es für das Update oft kaum relevant, ob davon 50 oder 5.000 Seiten vorhanden sind.

Bei einer kleinen Website kann dagegen zwischen Backend und Frontend viel eigene Logik liegen: spezielle Templates, Conditions, eigene Datenmodelle, APIs oder Funktionen, die Inhalte verarbeiten, bevor sie ausgegeben werden.

Ein dicker Seitenbaum ist nicht automatisch teuer. Eine einzelne Spezialfunktion kann es aber sein.

Custom Extensions können den größten Teil des Updates ausmachen

Eigene Extensions sind einer der häufigsten Gründe dafür, dass ein kleines Projekt technisch größer wird als erwartet. Dabei ist nicht entscheidend, wie viele Extensions vorhanden sind, sondern wie viel Funktionalität darin steckt.

In vielen Projekten ist besonders das Sitepackage über die Jahre sehr voll geworden. Dort landet dann nicht nur die Grundkonfiguration der Website, sondern oft auch projektspezifische Logik, eigene Content-Elemente, ViewHelper, Templates, TypoScript, Datenverarbeitung und andere Anpassungen.

Eine einzige umfangreiche Custom Extension kann deshalb mehr Arbeit verursachen als der komplette TYPO3-Core-Updateprozess.

Wenn der Code schon mehrere TYPO3- und PHP-Versionen alt ist, muss geprüft werden, welche APIs noch funktionieren, welche Klassen angepasst werden müssen und ob verwendete Funktionen inzwischen anders umgesetzt werden.

Externe APIs und Schnittstellen können überraschend viel Arbeit machen

Eine kleine Website kann technisch stark mit anderen Systemen verbunden sein. Typische Beispiele sind CRM-Systeme, Newsletterdienste, Zahlungsanbieter, externe Datenbanken oder andere APIs.

Solange diese Anbindungen funktionieren, sieht man ihnen im Frontend oft nicht an, wie viel Technik dahintersteckt.

Bei einem Update kann sich das ändern. Besonders bei Zahlungsanbietern werden Bibliotheken und APIs aus Sicherheitsgründen regelmäßig angepasst. Ich habe beispielsweise erst kürzlich eine Stripe-Anbindung aktualisiert, bei der sich die Nutzung der API gegenüber der alten Implementierung deutlich verändert hatte.

Dann reicht es nicht, nur TYPO3 zu aktualisieren. Die Schnittstelle selbst muss ebenfalls geprüft, angepasst und anschließend getestet werden.

Komplexe Formulare sind oft aufwendiger als sie aussehen

Formulare sind ein gutes Beispiel für Funktionen, die im Frontend sehr unspektakulär wirken können und technisch trotzdem Arbeit verursachen.

Gerade bei größeren Versionssprüngen können sich Templates und Strukturen von Extensions wie Powermail verändern. Wenn ein Projekt eigene Formular-Templates besitzt, reicht es nicht immer, einfach die neue Extension-Version zu installieren.

Dann muss man die alten individuellen Templates mit den neuen Standard-Templates vergleichen, die Änderungen der Extension nachvollziehen und anschließend die projektspezifischen Anpassungen sauber auf die neue Version übertragen.

Ein Formular mit drei Feldern kann im Frontend klein aussehen und trotzdem mehrere individuell angepasste Templates und Logik im Hintergrund besitzen.

Shop- und Payment-Funktionen brauchen besondere Aufmerksamkeit

Auch kleine Shop- oder Payment-Funktionen können ein Update deutlich vergrößern. Zahlungsanbieter verändern regelmäßig ihre APIs, Bibliotheken und Sicherheitsanforderungen.

Wenn eine alte Integration mehrere Jahre nicht angefasst wurde, kann der Sprung auf eine aktuelle Version entsprechend größer ausfallen.

Gerade bei Zahlungsfunktionen reicht außerdem kein kurzer Sichttest. Der komplette Ablauf muss geprüft werden: Anfrage, Rückmeldung des Zahlungsanbieters, Fehlerfälle und die Verarbeitung im eigenen System.

Alte Technik kann aus einem Update eine kleine Modernisierung machen

Manchmal ist nicht eine einzelne Funktion das Problem, sondern die technische Grundlage des Projekts.

Ein Beispiel ist ein älteres Projekt, das noch auf Strukturen basiert, die in modernen TYPO3-Versionen nicht mehr sinnvoll oder gar nicht mehr unterstützt werden. Dann kann im Rahmen des Updates ein Umbau notwendig werden.

Dazu können zum Beispiel Migrationen von älteren Content-Element-Lösungen auf Fluid-basierte Strukturen gehören. Auch beim Rendering kann ein Wechsel von älteren Konfigurationen wie FLUIDTEMPLATE auf modernere Ansätze wie PAGEVIEW sinnvoll oder notwendig werden.

Wie groß dieser Aufwand ist, hängt stark vom Projekt ab. Bei einer kleinen, einfachen Website ist das schnell erledigt. Wenn viele Templates, Layouts und Sonderfälle daran hängen, wird daraus ein eigener Teil des Updates.

Ein Update ist dann nicht teuer, weil die Website viele Seiten hat, sondern weil ein Teil ihrer technischen Grundlage modernisiert werden muss.

Schlechter Code schlägt Projektgröße

Wenn ich zwischen zwei Projekten wählen müsste, wäre mir ein großes Projekt mit sauberer Struktur lieber als ein kleines Projekt mit schlechtem, schwer nachvollziehbarem Code.

Saubere Strukturen machen Änderungen berechenbar. Man sieht schneller, wo eine Funktion herkommt, welche Abhängigkeiten existieren und was angepasst werden muss.

Bei schlechtem Code passiert das Gegenteil. Änderungen greifen unerwartet an anderen Stellen, Funktionen sind miteinander vermischt und man braucht deutlich länger, um überhaupt zu verstehen, was der vorhandene Code macht.

Das ist einer der Gründe, warum man den Aufwand eines TYPO3-Updates nicht anhand der Anzahl der Seiten kalkulieren sollte.

Fehlende Dokumentation ist bei kleinen Projekten nicht automatisch ein Problem

Bei großen Legacy-Systemen kann fehlende Dokumentation sehr teuer werden. Bei einer kleinen Website mit überwiegend Standardfunktionen ist sie dagegen oft weniger kritisch.

Wenn die Installation klar aufgebaut ist und hauptsächlich TYPO3-Standard verwendet, lässt sich vieles direkt aus dem System und dem Code nachvollziehen.

Sobald jedoch eigene Logik, Schnittstellen oder spezielle Workflows vorhanden sind, wird Dokumentation wieder wichtiger. Dann spart es viel Zeit, wenn klar beschrieben ist, warum eine Funktion existiert und wie sie verwendet wird.

Deshalb schaue ich vor einem Angebot zumindest kurz ins System

Ob eine kleine Website wirklich ein kleines Update ist, lässt sich von außen kaum zuverlässig erkennen.

Deshalb brauche ich für eine vernünftige Einschätzung zumindest einen kurzen Blick ins TYPO3-Backend und – je nach Projekt – auch in die technische Struktur. Oft reichen schon 20 bis 30 Minuten, um zu sehen, welche Extensions installiert sind, welche Versionen verwendet werden und ob individuelle Funktionen vorhanden sind.

Bei kleinen, gepflegten Projekten bestätigt sich dann häufig der erste Eindruck und das Update lässt sich schnell kalkulieren.

Manchmal zeigt sich aber auch das Gegenteil: Hinter einer kleinen Website steckt eine alte Eigenentwicklung, eine komplexe Formularlogik oder eine externe Schnittstelle, die beim Update berücksichtigt werden muss.

Genau dafür ist die technische Ersteinschätzung da. Sie soll nicht aus einem kleinen Projekt künstlich ein großes machen, sondern verhindern, dass der Aufwand erst während des Updates überraschend sichtbar wird.

Was macht ein kleines TYPO3-Projekt teuer?

Nicht die Seitenzahl. Teuer wird es dann, wenn hinter wenigen sichtbaren Seiten viel individuelle Technik steckt.

Typische Gründe sind:

• umfangreiche Custom Extensions
• externe APIs und Schnittstellen
• Imports und Exports
• komplexe Formulare
• Shop- oder Payment-Funktionen
• Login- und Benutzerbereiche
• individuelle Middlewares
• alte Templates und Rendering-Strukturen
• technisch notwendige Modernisierungen
• schwer nachvollziehbarer Code

Eine kleine Website kann deshalb ein sehr günstiges Update sein – oder technisch deutlich anspruchsvoller als eine wesentlich größere Installation.

Bevor ich einen Preis nenne, schaue ich deshalb lieber kurz ins Projekt, statt die Kosten anhand des Seitenbaums zu raten.