TYPO3-v14.3-Workspaces: wenn Entwurfsinhalte in der Suche unsichtbar bleiben – und der Patch dazu

Wer in TYPO3-Workspaces arbeitet, kennt die Situation: Eine Seite oder ein Datensatz wurde im Entwurf angelegt, existiert also noch gar nicht im Live-Stand – und trotzdem soll er in der Record-List-Suche, im Suggest-Wizard oder bei der Slug-Eindeutigkeitsprüfung auftauchen. In TYPO3 v14.3 tun das reine Workspace-Entwürfe jedoch nicht zuverlässig, weil feldgefilterte Backend-Abfragen nur versionierte Datensätze einschließen, die bereits ein Live-Gegenstück haben. Das führt zu fehlenden Vorschlägen, doppelten Slugs und verwirrenden Suchergebnissen mitten im Redaktionsalltag.

Das Composer-Paket webconsulting/typo3-workspace-overlay-patch behebt beide zugrunde liegenden Regressionen über reine Patch-Dateien – ohne eigenen PHP-Runtime-Code im Produktivsystem. Die Patches werden mit cweagans/composer-patches v2 eingespielt und lassen sich über einen einzelnen TSconfig-Schalter granular steuern.

Inhaltsverzeichnis  

Überblick  

TYPO3 Workspaces erlauben es Redakteur:innen, Inhalte zu erstellen und zu bearbeiten, bevor diese online gehen. Ein „reiner Workspace-Entwurf" ist dabei ein Datensatz, der ausschließlich in einer Workspace-Version existiert – es gibt noch kein Live-Gegenstück mit einer positiven UID. Genau diese Datensätze werden von feldgefilterten Backend-Abfragen in v14.3 systematisch übersehen, da die zugrundeliegenden SQL-Restrictions nur versionierte Zeilen mit einem bekannten Live-Pendant einschließen.

Das zweite Problem betrifft Datensätze, die direkt via BackendUtility::workspaceOL() oder PageRepository::versionOL() geladen werden: Die zurückgegebene Workspace-Row behält die Workspace-UID (t3ver_oid) statt der Live-UID, was Folgeverarbeitungen wie Relation-Auflösungen oder UID-Vergleiche korrumpiert. Beide Probleme existieren unabhängig voneinander und betreffen unterschiedliche Code-Pfade.

Das Patch-Bundle adressiert beide Fälle koordiniert: Ein neuer QueryBuilder::addWorkspaceRestriction()-Helper kapselt die korrigierte Abfragelogik, und die zentrale Methode WorkspaceRestriction::shouldIncludeAllVersionedRecordsForBackendQuery() entscheidet anhand der TSconfig-Einstellung, ob reine Entwürfe einbezogen werden sollen. Verifiziert an TYPO3 14.3.1, PHP 8.3.30 und MariaDB 10.11; fünf Upstream-Functional-Tests laufen ohne Modifikation durch.

Funktionen im Detail  

Das Bundle enthält zwei Patch-Dateien: eine für typo3/cms-backend, die die 5 Abfrage-Stellen anpasst, und eine für typo3/cms-core, die den QueryBuilder-Helper sowie die 2 Overlay-Korrekturen einführt.

Die gesamte Funktionalität lässt sich über einen einzigen TSconfig-Schalter steuern :

options.workspaces.includeAllVersionedRecordsInQueries = 1

Der Schalter ist standardmäßig deaktiviert (opt-in): Bestehende Installationen erhalten durch das Einspielen der Patches kein verändertes Verhalten, bis die TSconfig-Zeile explizit gesetzt wird. Das erlaubt einen kontrollierten Rollout — erst in der Staging-Umgebung testen, dann in der Produktion aktivieren.

Installation  

composer config repositories.typo3-workspace-overlay-patch vcs https://github.com/dirnbauer/typo3-workspace-overlay-patch.git
composer require webconsulting/typo3-workspace-overlay-patch:^1.0

Häufige Fragen  

Fazit  

Wer in TYPO3 v14.3 aktiv mit Workspaces arbeitet und auf vollständige Suchergebnisse im Backend angewiesen ist, wird die beiden behobenen Regressionen in der Praxis schnell bemerken. Das Patch-Bundle hält den Eingriff so klein wie möglich – kein eigener PHP-Code zur Laufzeit, ein einziger TSconfig-Schalter, klare Verifikation gegen eine definierte Umgebung. Die fehlende CI ist ein ehrlicher Hinweis auf die Grenzen des Ansatzes: Jedes TYPO3-Patch-Release erfordert eine manuelle Prüfung. Für Teams, die diesen Aufwand in Kauf nehmen, ist das Bundle eine pragmatische Überbrückung bis ein offizieller Upstream-Fix vorliegt.