Was sich mit TYPO3 14.3.1 und 13.4.29 ändert — beide Releases vom 12.05.2026 im Betreiberüberblick

TL;DR

Zwei parallele Maintenance-Releases, kein Security-Advisory, eine PHP-relevante Pflicht-Änderung und mehrere Backend-Quality-of-Life-Fixes.

TYPO3 14.3.1

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.

TYPO3 13.4.29

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.

Kein Sicherheits-Update

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.

Worum es bei diesen Releases geht

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.

TYPO3 14.3.1 — die wichtigsten Bugfixes

Die 14.3.1 enthält rund 90 Commits seit 14.3.0. Wir gruppieren nach Wirkung.

Memory-Limit angehoben (Pflicht-Beachtung)

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.

Drag-and-Drop im langen Pagetree wieder nutzbar

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.

Scheduler — drei Fixes

• 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.

Setup und Encryption-Key

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.

Form-Framework — Stabilitätspaket

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).

Frontend, Routing und Cache

• 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.

TypoScript-Stabilität

• 6077b85063f — Leere Reference-Outputs in TypoScript verhindert.
• a9900a55684 — Multibyte-Characters in TypoScript korrekt behandelt.
• 3603a7db34c — Condition-Matcher hat tree immer verfügbar.

Install-Tool, Backend-UX und Entwickler-relevant

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).

TYPO3 13.4.29 — die wichtigsten Bugfixes und das einzige Feature

Die 13.4.29 enthält rund 30 Commits seit 13.4.28. Kürzer, fokussierter, mit einer interessanten Feature-Backport-Entscheidung.

Das einzige Feature: f:render.text Backport

Commit 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.

Drag-and-Drop-Fix (geteilt mit 14.3.1)

Commit ddac158c5e4 ist der Backport des Drag-and-Drop-Fixes für lange Pagetree-Views.

Composer und Fluid Updates

• 47b16738012 — Composer Update auf 2.9.7.
• d9b156f6317 — Fluid Standalone Update auf 4.6.1.

TypoScript-Stabilität (geteilt mit 14er)

• d000a936049 — Empty Reference Output verhindert.
• 1acb4681598 — Multibyte-Characters korrekt.
• 9e843def85f — SysTemplateTreeBuilder behandelt nullable Set-TypoScript korrekt.

Backend-UX und Frontend

• 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.

Image-Processing, Logging und Files

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).

Extbase / DomainObject

• 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.

Was hat sich an der Sicherheit geändert?

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.

Wer ist betroffen?

Drei Profile mit unterschiedlicher Priorität:

Profil A — Aktive 14.3-Betreiber

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.

Profil B — LTS-Betreiber auf 13.4

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.

Profil C — Sitepackage- und Extension-Maintainer

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.

Betreiberempfehlung

Maintenance-Releases verdienen Disziplin, kein Drama. Reihenfolge:

Operational Decision Block

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.

Quick-Check vor dem Update

# 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

Was wir bewusst nicht tun

• Kein Notfall-Rollout am Wochenende. Beide Releases sind reine Wartung. Wir schieben sie ins nächste reguläre Fenster.
• Keine Datenbank-Migration ungeprüft fahren. Die Release-Notes sagen „no database updates necessary“ — wir verifizieren das pro Site mit vendor/bin/typo3 upgrade:list und nehmen das schwarz auf weiß.
• Kein 13.4-Upgrade auf 14.3 mit diesem Wartungs-Update vermischen. Major-Wechsel bekommt ein eigenes Fenster, eigene Testbasis und eigenen Rollback-Pfad.

Was wir bei Moselwal konkret tun

Unsere TYPO3-Stack-Strategie folgt zwei Linien parallel: moselwal.de und ole-hartwig.eu laufen auf 14.x (aktuell 14.3.x), während wir bei Kunden je nach Vertragsbasis auch 13.4 LTS supporten.

Moselwal-Kunden sind bereits aktualisiert

Wir rollen TYPO3-Maintenance-Releases automatisch in unsere 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 Moselwal-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 uns kurz an.

Bei uns selbst

• 14.3.0 → 14.3.1 wird in der nächsten Wartungs-Iteration eingespielt. Wir nutzen das Update, um gleichzeitig das PHP-Memory-Limit pro Container auf 512 MB zu heben (FrankenPHP-Worker-Mode profitiert davon ohnehin).
• Drag-and-Drop-Fix nehmen wir mit Erleichterung mit — die Page-Module-Ansicht ist auf moselwal.de durch die TOC- und Spine-Struktur regelmäßig lang.
• Scheduler läuft bei uns sub-minütlich für mehrere Mini-Tasks (RSS-Feed-Rebuild, semantic-delivery-Refresh). Die Log-Entlastung ist konkret messbar.
• CI-seitig schauen wir uns die Playwright-Migration an — unsere moselwal/sitepackage-base-Tests laufen noch gegen die alte Acceptance-Pipeline; das wandert im nächsten Quartal mit.

Bei Kunden auf 13.4

• 13.4.29 wird wo möglich in dieselbe Wartungs-Iteration gehängt, in der wir ohnehin Composer-Updates fahren.
• f:render.text kommt in unseren moselwal/content-blocks-collection-Templates dort zum Einsatz, wo wir bislang <f:format.raw> mit Subselects kombiniert hatten — saubere Vereinheitlichung.

Fazit

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.