PHP 8.4 und strict_types: Typfehler in TYPO3 systematisch beseitigen

Christopher Zechendorf

27.03.2026

Share:

PHP 8.4 deckt versteckte Typfehler auf, die in älteren Versionen still funktionierten. Wir zeigen die häufigsten Muster in TYPO3-Extensions und wie man sie behebt.

Wenn PHP plötzlich streng wird

Die Herausforderung

Mit dem Upgrade auf PHP 8.4 und der konsequenten Nutzung von declare(strict_types=1) treten in vielen TYPO3-Projekten plötzlich TypeError-Exceptions auf — an Stellen, die jahrelang problemlos liefen. Der Grund: PHP akzeptierte in früheren Versionen stillschweigend falsche Typen und konvertierte sie automatisch. Unter strict_types ist damit Schluss.

In einem unserer TYPO3-Projekte führte das zu Produktionsausfällen: Nutzer konnten keine Bilder mehr hochladen, Stammdaten nicht bearbeiten und Events nicht aktualisieren. Die Fehler traten erst im Live-Betrieb auf, weil die betroffenen Code-Pfade in der Entwicklungsumgebung nicht vollständig durchlaufen wurden.

Die häufigsten Muster

Wir haben die Fehler analysiert und fünf wiederkehrende Muster identifiziert, die in fast jeder gewachsenen TYPO3-Extension vorkommen:

1. findByUid() erhält einen String statt int

Das häufigste Problem. Werte aus $GLOBALS['TSFE'], Request-Argumenten oder TypoScript-Settings sind immer Strings — findByUid() erwartet aber einen int.

// Vorher — crasht unter strict_types
$storage = $this->storageRepository->findByUid('1');
$user = $this->userRepository->findByUid($GLOBALS['TSFE']->fe_user->user['uid']);
$event = $this->eventRepository->findByUid($eventUid); // aus explode()

// Nachher
$storage = $this->storageRepository->findByUid(1);
$user = $this->userRepository->findByUid((int)$GLOBALS['TSFE']->fe_user->user['uid']);
$event = $this->eventRepository->findByUid((int)$eventUid);

2. date('U') statt time()

date('U') gibt einen Unix-Timestamp zurück — aber als String. Wird dieser Wert in eine Datenbankspalte vom Typ int geschrieben, knallt es.

// Vorher
$object->setTstamp(date('U'));

// Nachher
$object->setTstamp(time());

3. Doctrine DBAL execute() gibt kein Array mehr zurück

In Doctrine DBAL 3 (ab TYPO3 12) liefert QueryBuilder->execute() bei SELECT-Queries ein Result-Objekt statt eines Arrays. Wird dieses direkt an ein Fluid <f:form.select> übergeben, kommt es zum Fehler.

// Vorher
$regions = $queryBuilder->execute();
$this->view->assign('regions', $regions);

// Nachher
$regions = $queryBuilder->executeQuery()->fetchAllAssociative();
$this->view->assign('regions', $regions);

4. Bool vs. Int bei Settern

Setter-Methoden mit bool-Typdeklaration erhalten oft int-Werte (0 oder 1) aus der Datenbank oder Formularen.

// Vorher
$object->setDataForwarding((int)$value);

// Nachher
$object->setDataForwarding((bool)$value);

5. Solr Queue erwartet int-Timestamps

Die EXT:solr Queue::updateItem() erwartet int als $forcedChangeTime — bekommt aber häufig Strings aus Datenbankfeldern oder date()-Aufrufen.

// Vorher
$queue->updateItem($item, $indexConfig, $record['tstamp']);

// Nachher
$queue->updateItem($item, $indexConfig, (int)$record['tstamp']);

Das Ergebnis

Insgesamt haben wir über 15 Typ-Korrekturen in einem einzigen Controller durchgeführt — und ähnliche Muster in weiteren Klassen gefunden. Die Crashes im Live-Betrieb waren sofort behoben, und die Nutzer konnten die betroffenen Funktionen wieder normal verwenden.

Fazit

PHP 8.4 mit strict_types ist kein Feind — es ist ein Verbündeter. Die Typfehler waren schon immer da, nur hat PHP sie bisher stillschweigend geschluckt. Wer den Umstieg systematisch angeht und die fünf häufigsten Muster kennt, kann ein ganzes Projekt in kurzer Zeit absichern.

Im nächsten Beitrag zeigen wir, wie wir diesen Prozess mit einem KI-gestützten Tool automatisiert haben.

Sie planen ein PHP-Upgrade oder kämpfen mit Typfehlern in Ihrem TYPO3-Projekt? Sprechen Sie uns an — wir unterstützen Sie gerne bei der Migration.