TYPO3-Extensions
Drei Anlässe führen auf diese Seite. Ihrer TYPO3-Website fehlt eine Funktion, die der Core nicht mitbringt. Eine vorhandene Extension soll etwas anders machen. Oder eine Extension steht dem Update auf v13 oder v14 im Weg. Die Sharpness Solutions GmbH aus Oldenburg hat TYPO3 seit 2004 im Haus. Wir entwickeln Extensions als Composer-Pakete gegen die Erweiterungspunkte, die TYPO3 dafür vorsieht, binden Fremdsysteme an, machen fremde Extensions für neue Versionen fit und übernehmen Eigenentwicklungen, deren Autor nicht mehr erreichbar ist. Aktuell ist TYPO3 v14, seit dem 21. April 2026 die Langzeitversion (LTS); v13 bekommt als vorherige LTS weiter Sicherheitsupdates. Stand dieser Seite: 31. Oktober 2026. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Die erste Frage ist trotzdem immer, ob überhaupt gebaut werden muss.
Anfragen zu TYPO3-Extensions kommen selten mit einer Spezifikation. Sie kommen mit der Fehlermeldung aus einem abgebrochenen Upgrade, mit einer Liste von Extensions, die niemand mehr erklären kann, oder mit dem Satz „das muss TYPO3 doch können“. Sechs Ausgangslagen kehren dabei immer wieder. Gemeinsam haben sie, dass die eigentliche Entscheidung vor der ersten Zeile Code fällt: Core, gepflegte Extension oder Eigenentwicklung. Wer sie überspringt, bezahlt sie beim nächsten Major-Release.
Im TER und auf Packagist finden sich mehrere Kandidaten. Jeder deckt einen Teil der Anforderung ab, einer hat seit Jahren kein Release mehr, ein anderer bringt zwanzig Optionen für Fälle mit, die Sie nicht haben. Alle zu kombinieren heißt, mehrere fremde Pflegezyklen in Ihr Projekt zu holen. Bevor wir etwas bauen, prüfen wir, ob ein Kandidat mit einer Anpassung reicht — oder ob der Core das längst kann.
Entweder bricht Composer ab, weil der Constraint der Extension typo3/cms-core in Version 14 nicht zulässt. Oder das Upgrade läuft durch, und Inhaltselemente, die bisher ein Plugin zeigten, geben nichts mehr aus. In v14 ist die häufigste Ursache die entfernte Plugin-Registrierung über list_type. Ein gelockerter Constraint hilft dann nicht: Die Extension braucht ein eigenes, angepasstes Release.
Die Extension läuft, die letzte Version stammt aus der Zeit von v11, im Issue-Tracker stehen unbeantwortete Fragen zu v13 und v14. Die Funktion sitzt in Ihrer Website, die Entscheidung über ihre Zukunft bei jemand anderem. Der Ausweg heißt Ersatz, Fork oder Neubau. Die GPL lässt den Fork zu — offen ist nur, wer ihn danach pflegt.
Eine frühere Agentur hat eine Extension gebaut, die zentrale Arbeit leistet. Sie liegt in typo3conf/ext, ohne Repository, ohne Dokumentation, ohne Tests. Sie läuft, aber niemand traut sich, sie anzufassen, und jedes Upgrade-Angebot enthält an dieser Stelle einen kräftigen Risikoaufschlag. Das ändert sich erst, wenn jemand den Code gelesen hat.
Fahrzeugbestand, Produktdaten, Stellenangebote oder Termine liegen in einem anderen System und werden für die Website von Hand abgetippt oder als Datei hochgeladen. Das kostet Zeit und erzeugt zwei Stände, die nie ganz übereinstimmen. Eine Schnittstellen-Extension löst das — wenn vorher feststeht, welches System welches Feld führt.
Um ein Verhalten zu ändern, wurde eine Core-Datei editiert oder eine Klasse per XCLASS ersetzt. Das funktioniert bis zum nächsten Update. Danach ist der Patch still verschwunden, oder die ersetzte Klasse passt nicht mehr zum Rest. Ein Eingriff, der Updates blockiert, ist ein Konstruktionsfehler, kein Schicksal. Reparieren lässt er sich — aber nicht nebenbei am Tag des Upgrades.
Der erste Blick geht in den Core, und er lohnt sich häufiger, als man denkt. TYPO3 bringt im Standard Formulare über das Form Framework mit, eine Verwaltung für Weiterleitungen, Kategorien, Mehrsprachigkeit über die Site-Konfiguration, eine Volltextsuche und den Scheduler für wiederkehrende Aufgaben. Seit v13 bündeln Site Sets TypoScript, Einstellungen und Abhängigkeiten zu Paketen, die sich je Site aktivieren lassen. Vieles, wofür früher eine kleine Extension geschrieben wurde, ist heute ein paar Zeilen Konfiguration oder ein angepasstes Fluid-Template. Bevor wir eine Extension schreiben, prüfen wir deshalb, ob TypoScript, ein Site Set oder der Core die Aufgabe schon lösen. Eine Extension, die nicht installiert wird, kostet nichts — weder beim Bau noch beim nächsten Update.
Der zweite Weg ist eine gepflegte Extension aus dem TER oder von Packagist. Für Nachrichten, Kalender, Karten, Cookie-Hinweise oder Suchanbindungen gibt es etablierte Lösungen, und eine Eigenentwicklung daneben wäre Verschwendung. Gepflegt heißt dabei konkret: ein Release für die aktuelle LTS, ein Maintainer, der auf Fehlermeldungen antwortet, ein öffentlicher Issue-Tracker und Sicherheitskorrekturen, die in der Vergangenheit zeitnah kamen. Wichtig ist auch, wie eine Extension mit neuen Major-Versionen umgeht: Die Extension news etwa unterstützt ab Version 14.0.0 kein TYPO3 v12 mehr — wer sie aktuell halten will, muss mitziehen. Liefert ein Autor bei einer Sicherheitslücke keinen Fix, entfernt das TYPO3 Security Team die betroffenen Versionen aus dem TER. Deckt eine gepflegte Extension Ihre Anforderung, empfehlen wir sie, richten sie ein und nehmen sie in die Wartung auf, statt dieselbe Funktion ein zweites Mal zu bauen.
Der dritte Weg ist die Eigenentwicklung. Sie bringt genau die Funktion, die Ihr Ablauf braucht, ohne Konfigurationsmasken für Fälle, die es bei Ihnen nicht gibt, und ohne fremde Roadmap. Dafür gehört die Pflege von Anfang an dazu. Jede Extension, ob geladen oder gebaut, ist eine Position im Betrieb: Jedes Patch-Update des Cores prüft sie mit, jedes Major-Upgrade verlangt ihre Anpassung, jede Sicherheitsmeldung zu ihr will bewertet werden. Wir rechnen die Wege deshalb über die Jahre gegeneinander, die Sie die Website betreiben wollen, nicht über den Angebotspreis. Und manche Anforderung ist gar keine Extension-Anforderung, sondern eine Redaktionsregel, die noch niemand aufgeschrieben hat. Die schreibt man auf, statt sie zu programmieren.
Eine Extension entsteht bei uns als Composer-Paket mit eigenem Vendor-Namespace und einer composer.json, die den Typ typo3-cms-extension, den Extension-Key und die unterstützten TYPO3-Versionen benennt. Ab v14 ist eine gültige composer.json ohnehin Pflicht, auch in Classic-Mode-Installationen. Projektspezifische Extensions liegen im Repository des Projekts, wiederverwendbare in einem eigenen; den Quellcode bekommen Sie in einem Git-Repository, das Ihnen gehört. Die Konfiguration steht in Dateien und damit in der Versionsverwaltung: TCA für Tabellen und Felder, ein Site Set für TypoScript und Einstellungen, Symfony Dependency Injection für die Services. Was ein Redakteur ändern darf, steht im Backend. Was Code ist, steht im Repository — und nirgends sonst.
Extbase und Fluid setzen wir dort ein, wo sie passen: bei Datensätzen mit Listen- und Detailansicht, bei Formularen mit Validierung, bei einem Domänenmodell, das mehr ist als eine Tabelle. Für einen JSON-Endpunkt, einen Teaser aus einer Fremd-API oder eine kleine Ausgabe ist Extbase Überbau; dann genügt ein schlanker Controller oder eine PSR-15-Middleware. Eigene Inhaltselemente bauen wir mit Content Blocks — einer Extension, nicht Teil des Cores — oder mit eigenen TCA-Definitionen und Fluid-Template, damit Redakteure sehen, was sie pflegen. Bei Eschen Nutzfahrzeuge ist der Fahrzeugbestand als strukturierte Datensätze angelegt, redaktionell pflegbar und mobil nutzbar. Strukturierte Datensätze lassen sich filtern, sortieren und an anderer Stelle wiederverwenden; Fließtext nicht. Was in kein Inhaltselement passt — eine Importübersicht, eine Freigabeliste —, bekommt ein eigenes Backend-Modul.
Eingegriffen wird über die Erweiterungspunkte, die TYPO3 dafür vorsieht. PSR-14-Events, um sich an Abläufe des Cores und anderer Extensions zu hängen. PSR-15-Middlewares für alles, was am Request oder an der Response geschieht, etwa ein eigener API-Endpunkt. Symfony Dependency Injection, um Services zu konfigurieren, statt sie per new zu erzeugen. TCA-Overrides, um vorhandene Tabellen um Felder zu erweitern. Und der DataHandler, wenn Datensätze programmatisch geschrieben werden — dann greifen Rechte, Protokoll, Referenzindex und Cache wie bei einer Eingabe im Backend. Nicht dazu gehören Core-Patches, die das nächste Composer-Update überschreibt, und XCLASS: Sie ersetzt eine Core-Klasse vollständig, pro Klasse greift nur eine, und jede Änderung am Original muss von Hand nachgezogen werden. Was über einen vorgesehenen Erweiterungspunkt eingreift, übersteht ein Major-Release in aller Regel. Was daran vorbeigreift, hat ein Ablaufdatum.
Viele Extensions haben eine einzige Aufgabe: Daten aus einem anderen System auf die Website zu bringen. Beim Autohaus Brüggemann — sechs Standorte von Rheine bis Rostock, acht Vertragsmarken, ein Bestand im vierstelligen Bereich — führt die TYPO3-Website alle Fahrzeuge in einer gemeinsamen Suche zusammen. Gespeist wird sie aus dem Händlersystem, nicht aus der Redaktion. Das ist das Muster: Was ein anderes System ohnehin führt, wird nicht ein zweites Mal von Hand gepflegt. Die Website zeigt denselben Stand wie das System dahinter, und niemand tippt Fahrzeugdaten ab. Damit das trägt, muss vorher geklärt sein, welche Daten in welche Richtung fließen, wie oft und was bei einem Fehler passiert.
Technisch läuft ein Import bei uns als Symfony-Console-Befehl, aufrufbar über vendor/bin/typo3 und zeitgesteuert über den Scheduler. Damit lässt er sich von Hand anstoßen, testen und auf der Kommandozeile nachvollziehen, statt in einem Frontend-Request zu laufen, der bei großen Datenmengen in ein Timeout gerät. Jeder Lauf schreibt ein Protokoll: wie viele Datensätze neu, geändert oder gelöscht wurden, welche abgelehnt und warum. Ein abgebrochener Lauf lässt sich ohne Schaden wiederholen, weil jeder Datensatz über einen eindeutigen Schlüssel aus dem Quellsystem zugeordnet wird und nicht über seine Position in einer Datei. Geschrieben wird über den DataHandler oder in eine klar abgegrenzte eigene Tabelle — nie per Direktzugriff auf Core-Tabellen, an dem Rechte und Cache vorbeilaufen.
Die entscheidende Frage ist keine technische: Wer führt welches Feld? Kommen Preis und Verfügbarkeit aus dem Fremdsystem, darf die Redaktion sie nicht überschreiben — sonst stimmt nach dem nächsten Import entweder die Website nicht, oder die Arbeit der Redaktion ist weg. Ergänzende Texte, Bilder oder Hervorhebungen dagegen bleiben redaktionell, in eigenen Feldern, die der Import nicht anfasst. Diese Datenhoheit je Feld legen wir schriftlich fest, bevor die erste Zeile Code entsteht. Eine Grenze ziehen wir dabei bewusst: Ein Shop gehört nicht als Extension ins CMS. Bei M&S Armaturen läuft der Unternehmensauftritt auf TYPO3, der Shopware-Shop ist angebunden. Ein Verkaufsprozess mit Preisregeln, Zahlarten und Retouren gehört in ein Shopsystem, und das bauen wir mit Shopware 6 daneben, statt es in eine CMS-Extension zu zwingen.
Bei einem Major-Upgrade ist selten der Core die Bremse, sondern die Extension-Liste. Deshalb beginnt jede Upgrade-Arbeit bei uns mit einem Inventar: Welche Extensions sind installiert, welche davon werden tatsächlich genutzt, wer pflegt sie, gibt es ein Release für die Zielversion? Ob eine Extension genutzt wird, zeigt die Datenbank, nicht das Gedächtnis — ein Plugin, das auf keiner Seite mehr eingebunden ist, muss nicht migriert werden, sondern entfernt. Am Ende steht für jede Extension ein Vermerk: aktualisieren, durch den Core ersetzen, durch eine gepflegte Extension ersetzen, portieren, neu bauen oder entfernen. Diese Liste ist meistens kürzer als befürchtet, und sie ist die Grundlage jeder ehrlichen Schätzung.
Für eine Extension ohne Release für die Zielversion gibt es drei Wege. Ersatz durch den Core oder eine gepflegte Alternative, auch wenn dabei Konfiguration und Daten umziehen müssen. Portierung, also die Übernahme des Codes in Ihr eigenes Repository und die Anpassung an die neue Version — die GPL, unter der TYPO3-Extensions stehen, erlaubt das; mit dem Fork kommt aber auch die Pflege dazu. Oder der Neubau der Funktion, oft mit kleinerem Umfang, weil sich zeigt, dass die Hälfte der Optionen nie benutzt wurde. Der Neubau hat einen Vorteil, der oft übersehen wird: Was die Funktion tun soll, lässt sich am laufenden System ablesen. Beide Zahlen, Portierung und Neubau, stehen in der Schätzung nebeneinander, auch wenn eine davon der kleinere Auftrag ist.
Für die Portierung selbst gibt es Werkzeuge, die einen Teil der Arbeit abnehmen. Der Extension Scanner im Install Tool findet im Code Aufrufe von API, die in der Zielversion entfernt oder als veraltet markiert ist. TYPO3 Rector schreibt einen Teil dieser Stellen automatisch um, Fractor erledigt dasselbe für TypoScript, FlexForms, YAML und Fluid. Was bleibt, ist Handarbeit: Geschäftslogik in Templates, Abhängigkeiten, deren Composer-Constraints kollidieren, und in v14 vor allem die Umstellung der Plugin-Registrierung von list_type auf eigene CTypes samt Upgrade-Wizard, damit vorhandene Inhaltselemente nach dem Upgrade weiter ausgegeben werden. Welche Breaking Changes v14 im Einzelnen mitbringt und wie ein Upgrade-Projekt abläuft, steht auf unserer Seite zum TYPO3-Update. Hier geht es um den Code, der dabei mitziehen muss.
Eigenentwicklungen einer früheren Agentur übernehmen wir, aber nicht blind. Vor einer Zusage steht ein Code-Review mit demselben Satz Fragen, jedes Mal. Gibt es eine composer.json, und an welche TYPO3-Version ist sie gebunden? Liegt der Code in einem Repository oder nur auf dem Server? Hängt sich die Extension über Events und Dependency Injection ein oder über XCLASS, veraltete Hooks und Direktzugriffe auf Core-Tabellen? Schreibt sie Datensätze über den DataHandler? Steht Geschäftslogik in Fluid-Templates oder in TypoScript? Was findet der Extension Scanner gegen die Zielversion? Existieren Tests, und laufen sie? Das ist Arbeit von Stunden bis Tagen und ein abgegrenztes Erstprodukt mit eigenem Preis, den wir vorher schriftlich nennen.
Am Ende steht ein Befundbericht: was die Extension tut, wo sie an Interna des Cores greift und was für die nächste Version zu tun ist, mit einer Risikoliste nach Priorität und dem Aufwand in Personentagen. Daneben steht die Alternative Neubau mit ihrer eigenen Zahl, damit Sie zwischen beiden Wegen entscheiden können, bevor Geld in den Code fließt. Und wir sagen ab, wenn eine Extension so gebaut ist, dass wir für ihr Verhalten nach dem nächsten Update nicht geradestehen können, oder wenn zentrale Teile ohne Quellcode ausgeliefert wurden — dann ist der Neubau der ehrlichere Auftrag. Wer fremden Code übernimmt, ohne ihn gelesen zu haben, übernimmt vor allem dessen Überraschungen.
Nach der Übernahme kommt zuerst Ordnung, dann Pflege. Der Code zieht in ein Git-Repository, das Ihnen gehört, bekommt eine composer.json, Versionsnummern nach Semantic Versioning und eine Dokumentation, die erklärt, was die Extension tut und wie sie konfiguriert wird. Kritische Abläufe bekommen Tests mit dem TYPO3 Testing Framework, bevor jemand sie ändert — sonst weiß niemand, ob eine Änderung etwas kaputt gemacht hat. Erst danach wird portiert oder erweitert. Die laufende Pflege übernehmen wir in der TYPO3-Wartung mit Service-Level-Vereinbarung, auf Wunsch zusammen mit dem Betrieb auf unseren eigenen Servern im Hetzner-Rechenzentrum Falkenstein. Die Extension steht wie TYPO3 selbst unter der GPL, der Quellcode gehört Ihnen, die Domain läuft auf Ihren Namen.
Ablauf
Wenn eine Funktion fehlt, beschreiben Sie den Ablauf, den sie ersetzen soll. Wenn eine Extension das Upgrade blockiert, genügt die Ausgabe von composer show oder die Liste der installierten Extensions. Sie bekommen eine schriftliche Einschätzung mit Weg, Aufwandsrahmen und der Alternative daneben — auch dann, wenn der Core oder eine gepflegte Extension genügt und wir sie nur einrichten. Sharpness Solutions GmbH, Edewechter Landstraße 161, Oldenburg. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Wir arbeiten bundesweit remote, Termine vor Ort im Nordwesten nach Absprache.
Zuerst klären wir, was passieren soll und an welcher Stelle — nicht, welche Technik dafür eingesetzt wird. Wer erledigt die Aufgabe heute, und wie? Welche Daten kommen woher? Gilt die Regel, die automatisiert werden soll, ohne Ausnahme? Eine Regel mit unbenannten Ausnahmen wird im Code nicht klarer, nur teurer.
Wir prüfen, ob Core, Site Set oder TypoScript die Aufgabe schon lösen, und sichten TER und Packagist nach gepflegten Extensions. Bei Kandidaten sehen wir nach Release für die aktuelle LTS, Pflegezustand und Erweiterungspunkten. Parallel klären wir, welche Events und APIs TYPO3 für Ihre Anforderung bereitstellt. Ergebnis ist eine kurze Liste realistischer Wege.
Nutzen, anpassen oder bauen — und was in die Extension gehört, was in die Konfiguration und was Redaktionsarbeit bleibt. Sie bekommen eine Aufwandsschätzung in Personentagen mit getrennten Posten, einen Festpreis für klar abgegrenzte Teile und die benannte Liste dessen, was erst am Testsystem entschieden werden kann.
Gearbeitet wird in einem Git-Repository, das Ihnen gehört, gegen eine Staging-Instanz, nie im Livebetrieb. Die Extension hängt sich über Events, Middlewares, Dependency Injection und TCA ein, nicht über XCLASS oder Core-Patches. Tests und statische Analyse laufen bei jedem Commit mit.
Sie testen am Staging-System gegen eine Abnahmeliste. Vor der Freigabe läuft ein Update-Test: Installation, Datenbankabgleich und ein Patch-Update des Cores mit aktiver Extension. Das Deployment geht über den vereinbarten Weg, mit Backup unmittelbar davor und einem festgelegten Rückweg.
Danach zieht die Extension mit jedem Release mit. Vor jedem Major-Upgrade läuft der Extension Scanner gegen die Zielversion, Anpassungen kommen, bevor sie drängen. Die Pflege läuft in der TYPO3-Wartung mit Service-Level-Vereinbarung: 24, 8 oder 4 Stunden Reaktionszeit, als Monatspauschale netto, auf Wunsch mit Betrieb auf unseren Servern in Deutschland.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Im ganzen Nordwesten
Wir arbeiten für Unternehmen von Wuppertal und Münster über das Emsland und Ostfriesland bis Hamburg und Hannover. Termine vor Ort nach Absprache, die laufende Arbeit remote. Zu jeder Region gibt es eine eigene Seite.
Eine TYPO3-Extension wird nach Aufwand kalkuliert, in Personentagen mit getrennten Posten; Paketpreise gibt es nicht. Den Aufwand bestimmen vier Größen: wie viele eigene Datenstrukturen und Inhaltselemente entstehen, ob ein Backend-Modul dazugehört, ob ein Fremdsystem angebunden wird und wie viele TYPO3-Versionen die Extension unterstützen soll. Eine Extension, die ein Inhaltselement mit drei Feldern bereitstellt, ist ein anderer Posten als ein Import mit Protokoll und Datenhoheit je Feld. Eine belastbare Zahl steht nach der Anforderungsklärung; klar abgegrenzte Teile bieten wir zum Festpreis an. Den Stundensatz nennen wir auf Anfrage.
Oft ja, und dann empfehlen wir sie, statt dieselbe Funktion neu zu bauen. Bevor wir entwickeln, prüfen wir, ob der Core, ein Site Set oder TypoScript die Aufgabe schon lösen, und sichten danach TER und Packagist. Eine fremde Extension taugt, wenn sie ein Release für die aktuelle LTS hat, ein Maintainer auf Fehlermeldungen antwortet und Sicherheitskorrekturen in der Vergangenheit zeitnah kamen. Dazu gehört eine nüchterne Rechnung: Jede installierte Extension prüft jedes Update mit. Drei halb passende Extensions sind deshalb oft teurer als eine eigene, die genau passt.
Mit einem eigenen Release, nicht mit einem gelockerten Composer-Constraint. Zuerst findet der Extension Scanner im Install Tool die Aufrufe entfernter oder veralteter API, dann schreibt TYPO3 Rector einen Teil davon automatisch um; Fractor erledigt dasselbe für TypoScript, FlexForms und Fluid. Der Rest ist Handarbeit. In v14 betrifft das vor allem Plugins, die noch über list_type registriert sind: Sie werden als eigener CType registriert und bekommen einen Upgrade-Wizard, damit vorhandene Inhaltselemente weiter ausgegeben werden. Außerdem ist eine gültige composer.json Pflicht. Die Breaking Changes im Einzelnen stehen auf unserer Seite zum TYPO3-Update.
Häufig ja: Eine Extension kann im Composer-Constraint beide LTS-Versionen zulassen, solange sie nur API nutzt, die in beiden vorhanden ist. Wo das nicht geht, braucht es zwei Release-Linien mit getrennten Branches und getrennten Tests — das kostet eher so viel wie ein Major-Sprung als wie ein Bugfix. Ob sich das lohnt, hängt davon ab, wo die Extension läuft. Läuft sie nur auf Ihrer eigenen Website, reicht eine Linie für die Version, die Sie betreiben. TYPO3 v13 bekommt kostenlose Sicherheitsupdates bis zum 31. Dezember 2027; spätestens dann hat sich die zweite Linie ohnehin erledigt.
Es gibt drei Wege: Ersatz durch den Core oder eine gepflegte Alternative, Übernahme des Codes als Fork in Ihr eigenes Repository oder Neubau der Funktion. Rechtlich ist der Fork bei TYPO3-Extensions selten das Problem, denn sie stehen unter der GPL. Mit dem Fork kommt aber die Release-Verantwortung zu Ihnen, und damit die Pflege, die wir in der Wartung übernehmen. Welcher Weg günstiger ist, entscheidet der Funktionsumfang, den Sie wirklich nutzen. Oft zeigt sich beim Inventar, dass die Hälfte der Optionen nie benutzt wurde; dann ist der Neubau kleiner, als die alte Extension vermuten lässt.
Ja, nach einem Code-Review. Wir sehen uns composer.json und Versions-Constraint an, ob der Code in einem Repository liegt, wie sich die Extension einhängt — Events und Dependency Injection oder XCLASS, veraltete Hooks und Direktzugriffe auf Core-Tabellen —, ob Datensätze über den DataHandler geschrieben werden, ob Geschäftslogik in Templates steht und ob Tests existieren. Dazu ein Lauf des Extension Scanners gegen die Zielversion. Ergebnis ist ein Befundbericht mit Aufwand und der Alternative Neubau daneben. Danach folgen Dokumentation und laufende Pflege. Manchmal sagen wir ab, etwa wenn zentrale Teile ohne Quellcode ausgeliefert wurden.
Ja, in den meisten Fällen über eine eigene, kleine Begleit-Extension. Sie hängt sich an die PSR-14-Events der fremden Extension, konfiguriert deren Services über Dependency Injection um, ergänzt Felder per TCA-Override und überschreibt einzelne Fluid-Templates über zusätzliche Template-Pfade in TypoScript. Die fremde Extension bleibt unverändert und lässt sich weiter aktualisieren. Die Grenze prüfen wir vorher: Wenn eine Extension keine Events anbietet und ihre Logik in Klassen kapselt, die sich nicht austauschen lassen, sagen wir das, bevor Sie beauftragen — dann sind Fork oder Neubau der ehrlichere Weg.
Über eine Schnittstellen-Extension, die die Daten zeitgesteuert importiert und als strukturierte Datensätze ablegt. Bei uns läuft ein solcher Import als Symfony-Console-Befehl, gestartet über den Scheduler, mit Protokoll für jeden Lauf und einem eindeutigen Schlüssel je Datensatz, damit ein abgebrochener Lauf ohne Schaden wiederholt werden kann. Vorher wird festgelegt, welches System welches Feld führt. Beim Autohaus Brüggemann führt die TYPO3-Website so alle Fahrzeuge aus sechs Standorten in einer gemeinsamen Suche zusammen, gespeist aus dem Händlersystem statt aus der Redaktion.
Weil beides das nächste Update gefährdet. Ein Patch an einer Core-Datei wird beim nächsten Composer-Update überschrieben, oft ohne dass es jemand bemerkt. XCLASS ersetzt eine Core-Klasse vollständig; jede Änderung, die TYPO3 am Original vornimmt, muss von Hand nachgezogen werden, und pro Klasse greift nur eine XCLASS. Für fast jede Anforderung gibt es einen vorgesehenen Weg: PSR-14-Events, PSR-15-Middlewares, Symfony Dependency Injection, TCA-Overrides und den DataHandler. XCLASS bleibt der letzte Ausweg, wenn keiner davon trägt — dann dokumentiert und mit einem Termin für den Rückbau.
Einen Shop als Extension in TYPO3 bauen wir nicht, sondern koppeln den TYPO3-Auftritt mit Shopware 6. Es gibt Shop-Extensions für TYPO3, aber ein Verkaufsprozess mit Preisregeln, Zahlarten, Retouren und ERP-Anbindung gehört in ein Shopsystem. Inhalte, Seitenstruktur und Redaktion bleiben in TYPO3, Warenkorb und Bestellung laufen in Shopware. So ist es bei M&S Armaturen gelöst: Der Unternehmensauftritt läuft auf TYPO3, mehrsprachig und redaktionell selbst pflegbar, der Shopware-Shop ist angebunden. Eine Extension, die einen Shop nachbaut, würde jedes TYPO3-Upgrade zu einem eigenen Projekt machen.
Der Quellcode gehört Ihnen und steht wie TYPO3 selbst unter der GPL. Wir entwickeln in einem Git-Repository, das Ihnen gehört; Domain, Lizenzen und Accounts laufen auf Ihr Unternehmen. Die GPL verpflichtet nicht dazu, eine Extension zu veröffentlichen, die nur auf Ihrer Website läuft — sie regelt, was gilt, wenn die Extension weitergegeben wird. Ob eine Eigenentwicklung als Open Source ins TER geht, entscheiden Sie. Für eine Extension, die genau eine Website bedient, bringt das selten etwas außer zusätzlichem Aufwand für Anfragen Dritter.
Das übernehmen wir in der TYPO3-Wartung mit Service-Level-Vereinbarung. Die Stufen reichen von 24 über 8 bis 4 Stunden Reaktionszeit, als Monatspauschale netto; Rufbereitschaft außerhalb der Geschäftszeiten gibt es nur mit SLA. Ohne SLA bearbeiten wir Anfragen innerhalb von 48 Stunden in den Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Vor jedem Major-Upgrade prüfen wir die Extension mit dem Extension Scanner gegen die Zielversion, damit Anpassungen geplant kommen und nicht am Tag des Updates. Auf Wunsch betreiben wir die ganze Installation auf unseren eigenen Servern in Deutschland.
Anfrage
Beschreiben Sie kurz, was die Extension tun soll oder welche vorhandene Ihnen im Weg steht. Ob der Core oder eine gepflegte Extension das schon kann, prüfen wir mit — und wenn ja, sagen wir es.