Am 12. Mai 2026 hat das TYPO3-Core-Team zwei Maintenance-Releases parallel veröffentlicht: 14.3.1 für die aktuelle Linie und 13.4.29 für die LTS-Linie. Beide tragen reine Bugfix- und Wartungsänderungen — kein Sicherheitsadvisory, keine Datenbank-Migration nötig, Caches sollten geleert werden.
Hinweis für meine Kunden: Ihre Installationen haben die Updates bereits automatisch über meine Wartungsroutine erhalten — 14.3.1 auf den 14er-Stacks, 13.4.29 auf den LTS-Stacks. Caches sind geleert, Smoketests gelaufen. Kein Handlungsbedarf Ihrerseits.
Was hat sich geändert? In 14.3.1 dominiert ein Memory-Limit-Lift (256 MB Minimum / 512 MB empfohlen), ein wieder nutzbares Drag-and-Drop in langen Pagetree-Views und eine deutliche Reduktion des Scheduler-Logging-Lärms. 13.4.29 bringt einen Feature-Backport (f:render.text), Composer 2.9.7 und ein Fluid-Standalone-Update. Wer ist betroffen? Alle Betreiber von TYPO3-14- und TYPO3-13-Installationen. Was sollten Sie heute lesen? Die Bugfix-Highlights pro Release, den Operational Decision Block für die Update-Reihenfolge und den knappen Quick-Check, ob Ihre PHP-Konfiguration die neue Memory-Limit-Empfehlung schon erfüllt.
Zwei parallele Maintenance-Releases, kein Security-Advisory, eine PHP-relevante Pflicht-Änderung und mehrere Backend-Quality-of-Life-Fixes.
Memory-Limit auf 256/512 MB angehoben, Drag-and-Drop im Pagetree wieder verlässlich, Scheduler-Logs nicht mehr für jede Task-Execution, Page-Cache-Invalidation bei Project-Path-Wechsel, sauberer Encryption-Key während Setup, viele Form/FormEngine-Fixes, CI-Migration von Codeception zu Playwright.
Backport f:render.text (Fluid-ViewHelper für Text-Rendering), Composer 2.9.7, Fluid Standalone 4.6.1, Drag-and-Drop-Fix (gemeinsam mit 14er), Scheduler-Korrekturen, imageMagickExec-Precedence-Fix, mehrere TypoScript-Stabilitätsfixes.
Beide Versionen sind explizit als „bugfix and maintenance release“ deklariert. Keine TYPO3-Core-CVE in diesem Release-Zyklus.
Drei Sätze für Betreiber: Die Memory-Limit-Anhebung in 14.3.1 ist die einzige Pflicht-Änderung mit Außenwirkung auf die PHP-Konfiguration. Drag-and-Drop und Scheduler-Logging sind operative Erleichterungen, die in produktiven Installationen sofort spürbar sind. Den f:render.text-Backport in 13.4.29 sollten Sitepackage-Maintainer kennen, weil er Fluid-Templates konsistenter macht.
TYPO3 14.3.1 ist die erste Wartungs-Iteration der 14.3-Linie. Die 14er-Reihe ist noch keine LTS-Version — das wird erst 14.4 — aber 14.3 ist die Linie, auf der das Core-Team aktuell die nächste LTS vorbereitet. 13.4.29 ist die laufende LTS-Linie und bekommt regelmäßig Bugfix-Wartung, bis die nächste LTS sie ablöst.
Beide Releases sind am selben Tag (12.05.2026) erschienen — das gemeinsame TYPO3-News-Ticket spricht von „maintenance releases published“. Wichtig: weder die offizielle TYPO3-News-Seite noch die Release-Notes nennen eine Security-Advisory-Nummer. Das ist im aktuellen Mai-Zyklus eine Pause vom letzten 8.5.-CVE-Block, keiner der Commit-Logs trägt einen [SECURITY]-Tag.
Wer derzeit noch auf 14.3.0 oder 13.4.28 läuft, bekommt mit dem Update keine Datenbank-Migration — der Upgrade-Pfad ist composer update typo3/cms-* --with-dependencies plus einmal Cache löschen.
Drei Profile mit unterschiedlicher Priorität:
Wer auf 14.3.0 läuft, sollte 14.3.1 als Standard-Wartungs-Update einplanen. Hauptmotivation: Memory-Limit-Empfehlung anpassen, Drag-and-Drop-Regression eliminieren, Scheduler-Logs entlasten. Kein Notfall, aber das nächste sinnvolle Wartungsfenster ist die richtige Stelle.
Wer noch auf 13.4.28 oder älter sitzt, sollte 13.4.29 mitnehmen — vor allem wegen f:render.text-Backport (für Sitepackage-Maintainer), des imageMagickExec-Precedence-Fix und der DI-Verbesserungen. Auch hier kein Notfall.
Die CI-Migration von Codeception zu Playwright in 14.3.1 ist für eigene Acceptance-Test-Suites relevant. Wer Testing-Framework-basierte Tests pflegt, sollte die neuen Beispiele aus dem Core anschauen, bevor das nächste TYPO3-Major die alten Codeception-Konstrukte streicht.
Wer auf 14.0, 14.1 oder 14.2 sitzt, sollte ohnehin auf 14.3 wechseln — diese Zwischenversionen bekommen keine Wartung mehr.
Kurz: nichts.
Beide Release-Notes deklarieren explizit „bugfix and maintenance release“. Es gibt keine Security-Advisory-Nummer in diesem Zyklus, kein [SECURITY]-Tag in den Commit-Logs, und das gemeinsame News-Statement spricht nur von Wartung. Wer in TYPO3-Mailinglisten oder im offiziellen Security-Feed nach einem Mai-Advisory sucht, das parallel zum 12.05.2026-Release fallen würde, findet keines.
Das bedeutet nicht, dass diese Updates unwichtig sind. Die Memory-Limit-Anhebung und die Backend-Stabilitätsfixes sind operativ relevant. Aber die Dringlichkeit ist „normales Wartungsfenster“, nicht „Notfall-Patch“. Wer einen geplanten Maintenance-Window in den nächsten ein bis zwei Wochen hat, kann die Updates dort sauber einsortieren.
Die 14.3.1 enthält rund 90 Commits seit 14.3.0. Wir gruppieren nach Wirkung.
Commit e8387fb0a47 hebt das von TYPO3 empfohlene PHP-Memory-Limit an: 256 MB Minimum, 512 MB empfohlen. Das ist keine harte Versionsanforderung, sondern eine offizielle Empfehlung — wer noch auf 128 MB läuft, bekommt in Backend-Modulen unter Last (Install-Tool, Image-Crop, große Pagetrees) zunehmend Fehler. Konkret: vor dem Update php -i | grep memory_limit ausführen und gegebenenfalls in der Container-PHP-Config, php.ini oder im .user.ini/.htaccess (mod_php) anheben.
Commit c31f5414bd8 repariert ein Regressions-Verhalten in der Page-Module-Ansicht: bei sehr langen Listen war Drag-and-Drop nicht mehr nutzbar. Wer große Sites mit vielen Inhaltselementen pro Seite betreut, wird das sofort merken.
7fbff9eeb93 — Scheduler loggt nicht mehr jede einzelne Task-Execution. Wer den Scheduler oft laufen lässt (sub-minütliche Tasks), bekommt damit deutlich entlastete Log-Dateien.d64f8b97ab2 — Tasks können ihre Execution wieder zuverlässig aktualisieren.607313c3f3f — Undefined-Array-Key task_group im Task-Form repariert.Commit 96f69e1f334 sorgt dafür, dass beim initialen Setup der Encryption-Key auch tatsächlich gesetzt wird. In bestimmten Konfigurationen blieb er leer und musste manuell nachgetragen werden. Commit b17c5e85aeb verschiebt das Package-Setup ans Ende der Setup-Phase — relevant für Composer-Distributionen, die auf einen sauberen Setup-Abschluss prüfen.
Vier Bugfixes für ext:form: Duplicate <br> aus den deny-Tags entfernt (dbdc26e49e6), verbesserte Lösch-Bestätigung beim Entfernen von Formularen (7cbc58473cc), fluidAdditionalAttributes wird sauber aufgeräumt, wenn ein Feld auf optional gesetzt wird (72876bda838), Avatar-Upload in den User-Settings funktioniert wieder mit partitioned Field-Names (4a38385df11).
b8a5f2fed90 — Site-Route-Matching für Slugs, die mit dem Site-Pfad identisch sind, wieder korrekt.74519b0fb1b — Berechnete Cache-Lifetime größer 24 Stunden ist jetzt zulässig.62275b71af6 — Page-Cache wird invalidiert, wenn der Projekt-Pfad sich ändert (relevant für Container-Setups mit wechselnden Mount-Points).8494a04bc80 — LinkResult-Type wird für Page-Links korrekt auf page gesetzt.fece7a3ca52 — Menü-Data-Processors honorieren if-Bedingungen.6077b85063f — Leere Reference-Outputs in TypoScript verhindert.a9900a55684 — Multibyte-Characters in TypoScript korrekt behandelt.3603a7db34c — Condition-Matcher hat tree immer verfügbar.Drei Install-Tool-Fixes: kein Crash mehr beim Login-Warning-Mail (77b10c59269), Auto-Passwort nicht mehr verstümmelt ausgegeben (41b50e628c2), Cache-Compression-Option toleriert Non-Bool-Werte (f691d5b2fb0). Backend-UX: gelockerte Size-Constraints im Page-Creation-Wizard (350d91db56e), Button-Group-Vertikalausrichtung wiederhergestellt (6b50b4ac0ff), Extension-Settings-Save-Button besser sichtbar (0688c51a687). Plus rund 12 Commits zur CI-Migration von Codeception auf Playwright — die Codeception-Pipeline wird entfernt (649719a5060), das Testing-Framework geht auf Playwright-Sharding (a50cee2476c). Erwähnenswert noch: DataHandler meldet keine falsch-positive „Version einer Version“ mehr (27665e6de14), Public-Folder im Classic-Mode wieder erlaubt (770c5383930), PageInformation-Klasse verliert ihr Experimental-Flag (a6b8e264882).
Die 13.4.29 enthält rund 30 Commits seit 13.4.28. Kürzer, fokussierter, mit einer interessanten Feature-Backport-Entscheidung.
f:render.text BackportCommit 8cd458abac4 portiert den Fluid-ViewHelper f:render.text aus der 14er-Linie zurück in die 13er-LTS. Das macht Fluid-Templates konsistenter: Statt unterschiedlicher Konstrukte für „rendere diesen Text mit Variablen-Substitution“ gibt es jetzt auch in 13.4 die direkte f:render.text-Form. Wer Sitepackages für beide Linien parallel pflegt, kann jetzt einen einheitlichen Templating-Stil fahren.
Commit ddac158c5e4 ist der Backport des Drag-and-Drop-Fixes für lange Pagetree-Views.
47b16738012 — Composer Update auf 2.9.7.d9b156f6317 — Fluid Standalone Update auf 4.6.1.d000a936049 — Empty Reference Output verhindert.1acb4681598 — Multibyte-Characters korrekt.9e843def85f — SysTemplateTreeBuilder behandelt nullable Set-TypoScript korrekt.6ad9ae2992f — returnUrl-Handling im PageLayoutController gestrafft.1c340dcfab7 — Grid-Column-Width im LanguageComparisonMode korrekt.39290a9fe7c — PreviewUriBuilder::withRootLine gibt das modifizierte Objekt zurück.20fabd4cf3f — Site-Route-Matching für identische Slugs (gemeinsamer Fix mit 14er).301b3fdc504 — isSubMenu schließt Link-Pages nicht mehr von Menu-Children aus.Commit 4d658b18a05 korrigiert die Operator-Precedence in imageMagickExec. Klingt klein, ist aber relevant — falsche Precedence in einer Image-Pipeline kann zu verfehlten Konvertierungen führen. Log-Rotation respektiert die Einstellung max files = 0 korrekt (a4c1fa9f3aa), Package-Cache-Identifier kombiniert mtime und filesize (b1b7a6fa847), IRRE/Files-Toggle-Switch für invertStateDisplay korrekt (9b22afc1d88).
c3eb0c99e48 — DomainObjectInterface ist nicht mehr @internal. Wer es in eigenen Extensions gegen das Interface implementiert hat (und sich dabei einen Internal-Warnhinweis gefangen hat), kann das jetzt sauber tun.b70d592678c — DI-Probleme bei DatabaseCompare gemildert.Maintenance-Releases verdienen Disziplin, kein Drama. Reihenfolge:
Wenn Sie auf TYPO3 14.3.0 sind und Composer-managed — dann
ziehen Sie 14.3.1 im nächsten regulären Wartungsfenster (kein Notfall). Vorher PHP-Memory-Limit prüfen und mindestens auf 256 MB anheben, idealerweise 512 MB.
Wenn Sie auf TYPO3 13.4.28 sind und unter LTS — dann
planen Sie 13.4.29 in derselben Wartungs-Iteration. f:render.text-Backport prüfen, ob Ihre Sitepackages den ViewHelper jetzt nutzen können statt Workarounds.
Wenn Sie eigene Scheduler-Tasks mit hoher Frequenz schreiben — dann
prüfen Sie nach dem Update das Log-Volumen; mit 14.3.1 fällt deutlich weniger Lärm an, das kann Monitoring-Schwellwerte verschieben.
Wenn Sie eigene Acceptance-Tests gegen typo3/testing-framework pflegen — dann
schauen Sie sich vor 14.3.1 die migrierten Playwright-Tests im Core an; Codeception wird mittelfristig nicht mehr gewartet.
Wenn Sie einen Container-managed Setup mit wechselnden Project-Paths haben — dann
ist der Page-Cache-Invalidation-Fix in 14.3.1 für Sie relevant; nach dem Update einmalig den Cache komplett räumen.
# PHP-Memory-Limit prüfen
php -i | grep memory_limit
# TYPO3-Version prüfen
vendor/bin/typo3 --version
# Composer-Update simulieren
composer update typo3/cms-* --with-dependencies --dry-run
# Nach dem Update: Cache räumen
vendor/bin/typo3 cache:flush
vendor/bin/typo3 upgrade:list und nehme das schwarz auf weiß.Meine TYPO3-Stack-Strategie folgt zwei Linien parallel: meine eigenen Sites laufen auf 14.x (aktuell 14.3.x), während ich bei Kunden je nach Vertragsbasis auch 13.4 LTS supporte.
Ich rolle TYPO3-Maintenance-Releases automatisch in die Kunden-Installationen aus, sobald sie freigegeben sind — ohne dass Sie als Kunde dafür ein Ticket öffnen müssen. 14.3.1 und 13.4.29 sind am 12.05.2026 erschienen und bei allen von mir betriebenen Installationen am selben Tag eingespielt worden. Caches sind geleert, Smoketests gelaufen, Sentry- und Uptime-Alerts grün. Sie müssen nichts tun. Wenn Sie wissen wollen, welche TYPO3-Version Ihre Installation gerade fährt, finden Sie das im Backend unter System → Konfiguration → TYPO3_CONF_VARS oder fragen mich kurz an.
moselwal/sitepackage-base-Tests laufen noch gegen die alte Acceptance-Pipeline; das wandert im nächsten Quartal mit.f:render.text kommt in meinen moselwal/content-blocks-collection-Templates dort zum Einsatz, wo ich bislang <f:format.raw> mit Subselects kombiniert hatte — saubere Vereinheitlichung.Nein. Beide Release-Notes stellen explizit fest: „No database updates are necessary.“ Es empfiehlt sich, nach dem Update einmal alle Caches zu räumen (Install-Tool → Important Actions → Flush Cache, oder per CLI vendor/bin/typo3 cache:flush).
TYPO3 14.3.1 migriert die zentrale Acceptance-Test-Pipeline von Codeception zu Playwright. Die Codeception-Acceptance-Pipeline wird entfernt. Wer eigene Acceptance-Tests gegen das TYPO3-Testing-Framework schreibt, sollte mittelfristig auf Playwright wechseln — das ist die neue Referenz im Core.
Zwei Änderungen in 14.3.1 betreffen den Scheduler direkt: Es wird nicht mehr jede Task-Execution geloggt (Lärm-Reduktion in den Logs), und Tasks können ihre Execution wieder zuverlässig aktualisieren. Wenn Sie eigene Tasks geschrieben haben, die Execution-Updates schreiben oder die hohe Log-Frequenzen erzeugen, wird das spürbar — meist positiv, aber Monitoring-Schwellwerte sollten angepasst werden.
Ja, ein einziges: den Fluid-ViewHelper f:render.text als Backport aus der 14er-Linie. Sitepackage-Maintainer, die ihre Templates für beide TYPO3-Linien parallel pflegen, können damit ein einheitliches Text-Rendering ohne Sonderfall verwenden.
TYPO3 14.3.1 hebt die offizielle Empfehlung auf 256 MB Minimum / 512 MB empfohlen. Das ist keine harte Versionsanforderung, sondern eine Empfehlung. Wer noch auf 128 MB läuft, bekommt unter Last (Install-Tool, große Pagetrees, Image-Processing) Fehler. Vor dem Update mit php -i | grep memory_limit prüfen und in der PHP-Konfiguration (Container, php.ini, .user.ini) anheben.
Nein. Es gibt keine Sicherheitsadvisory in diesem Release. Wer auf 14.3.0 läuft, kann 14.3.1 in das nächste reguläre Wartungsfenster einsortieren. Wichtig ist nur, vor dem Update das PHP-Memory-Limit zu prüfen und gegebenenfalls auf mindestens 256 MB zu heben.
TYPO3 14.3.1 und 13.4.29 sind klassische Maintenance-Releases — keine Schlagzeile, kein Security-Notfall, aber eine Handvoll Änderungen, die im täglichen Betrieb spürbar sind. Der Memory-Limit-Lift ist die einzige Pflicht-Aufgabe an die PHP-Konfiguration. Der Drag-and-Drop-Fix und die Scheduler-Log-Entlastung sind die größten Wohltaten für Redaktion und Operations. Der f:render.text-Backport in 13.4.29 ist die elegante Geste, die zeigt, dass die LTS-Linie nicht nur Bugfixes bekommt, sondern auch ausgewählte Konsistenz-Verbesserungen.
Wer beide Linien betreibt, hängt die Updates ins nächste reguläre Wartungsfenster. Wer auf älteren Wartungsständen sitzt, nutzt das Release als Anlass für den nächsten ohnehin fälligen Roll-up. Und wer auf 14.0, 14.1 oder 14.2 stehen geblieben ist, sollte 14.3.x als Pflicht-Ziel definieren — diese Zwischenversionen bekommen keine Wartung mehr.
TYPO3-Updates ohne Drama — operative Disziplin statt Bauchgefühl
Ich betreibe TYPO3-14- und TYPO3-13-Installationen mit klarer Update-Routine: Wartungsfenster, Rollback-Pfad, Cache-Verifikation, Sitepackage-Tests. Wenn du deine TYPO3-Wartung von „kommt-irgendwann“ auf „kommt-jeden-Monat-pünktlich“ heben willst, sprich mich an.
Programmiert seit 2002 – autodidaktisch gelernt, 2012 mit KO-Web selbständig gemacht. Über 100 Projekte, Fokus auf Security, Performance, Automatisierung und Qualität. Heute freiberuflich: DevSecOps-Beratung, Schulungen und Softwareentwicklung.