TYPO3 Extbase: Verborgene Datensätze mitladen

Ein Datensatz steht im Backend auf „verborgen“, soll aber trotzdem geladen werden — für eine Vorschau etwa, oder für eine Auswertung. Extbase filtert ihn von sich aus heraus. Abschalten lässt sich das über die Einstellungen der Abfrage.

Im Repository

public function findeAuchVerborgene(int $uid): ?Objektname
{
    $abfrage = $this->createQuery();
    $abfrage->getQuerySettings()
        ->setIgnoreEnableFields(true)
        ->setEnableFieldsToBeIgnored(['disabled']);
    $abfrage->matching($abfrage->equals('uid', $uid));
    return $abfrage->execute()->getFirst();
}

Beide Zeilen gehören zusammen: setIgnoreEnableFields(true) schaltet die Prüfung ab, setEnableFieldsToBeIgnored() grenzt sie wieder auf einzelne Spalten ein. Ohne die erste Zeile bleibt die zweite wirkungslos — so steht es in der Schnittstelle, und so verhält es sich auch.

Der Unterschied ist erheblich: Ohne die Einschränkung auf disabled ignoriert Extbase auch Start- und Stoppdatum sowie die Zugriffsrechte der Frontend-Benutzergruppen. Für eine Vorschau ist das selten gewollt. Gelöschte Sätze bleiben in beiden Fällen außen vor; dafür gibt es setIncludeDeleted().

Was aus der alten Anleitung geworden ist

Die erste Fassung dieses Beitrags tauschte über Extbase\Object\Container\Container und registerImplementation() die QueryFactory gegen eine eigene aus, die für ein bestimmtes Modell immer alles lud. Diesen Weg gibt es nicht mehr: Der Object Container von Extbase ist entfallen, Extbase verwendet den Dependency-Injection-Container von Symfony. Die QueryFactory ist heute readonly und bekommt ihre Abhängigkeiten über den Konstruktor.

Wer wirklich jede Abfrage auf ein Modell umstellen will, kann die Klasse weiterhin ersetzen — dann über einen Alias in der Configuration/Services.yaml. Das wirkt aber auf alle Extensions der Installation, nicht nur auf die eigene. In den allermeisten Fällen ist die Einstellung an der einzelnen Abfrage der ruhigere Weg.

Geprüft mit TYPO3 14.