www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/1f427e19-7011-4195-a187-bb29e98989c0/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

RuntimeException: Setup array has not been initialized. This happens in cached Frontend scope where full TypoScript is not needed by the system.

---

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers: "Setup array has not been initialized"¶

---

1. Ursache identifizieren¶

Der Fehler tritt im gecacheden Frontend-Kontext auf, wenn das System versucht, auf das TypoScript-Setup zuzugreifen, dieses aber nicht initialisiert wurde.

Konkrete Ursache:

• TYPO3 versucht, eine Seite im Frontend zu rendern, ohne dass das vollständige TypoScript geladen wird (z. B. bei gecachten Anfragen oder API-Calls).
• Der Fehler entsteht, weil ein Middleware oder eine Extension versucht, auf $GLOBALS['TSFE']->tmpl->setup zuzugreifen, bevor das TypoScript initialisiert wurde.
• Typische Auslöser:
  • Eigene Extensions, die im Frontend auf TypoScript zugreifen (z. B. in ext_localconf.php, ext_tables.php oder Middlewares).
  • Middleware-Stack, der vor der TypoScript-Initialisierung ausgeführt wird (z. B. VerifyHostHeader, NormalizedParamsAttribute).
  • Gecachte Anfragen, bei denen TYPO3 das TypoScript nicht neu lädt (z. B. bei eID-Skripten oder AJAX-Calls).

Stacktrace-Analyse:

• Der Fehler tritt in /public/index.php auf, wo der Request durch die Middleware-Kette läuft.
• Die Middlewares VerifyHostHeader und NormalizedParamsAttribute werden vor der TypoScript-Initialisierung ausgeführt.
• Irgendwo in dieser Kette wird versucht, auf das TypoScript-Setup zuzugreifen, obwohl es noch nicht geladen ist.

---

2. Fix beschreiben (konkret)¶

Lösungsansätze:

A) TypoScript-Loading erzwingen (falls nötig)¶

Falls eine Extension zwingend TypoScript benötigt, muss sichergestellt werden, dass es geladen wird.
Beispiel in einer Middleware:

public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
    // TypoScript manuell laden, falls nicht vorhanden
    if (!isset($GLOBALS['TSFE']->tmpl->setup)) {
        $GLOBALS['TSFE']->tmpl->start($GLOBALS['TSFE']->rootLine);
    }

    return $handler->handle($request);
}

B) Check vor TypoScript-Zugriff einbauen¶

Falls eine Extension auf TypoScript zugreift, sollte vorher geprüft werden, ob es initialisiert ist:

if (isset($GLOBALS['TSFE']->tmpl->setup)) {
    // TypoScript-Logik hier
} else {
    // Fallback oder Log-Eintrag
}

C) Middleware-Reihenfolge anpassen¶

Falls eine eigene Middleware den Fehler verursacht, sollte sie nach der TypoScript-Initialisierung laufen.
In ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['FE']['middlewares'][] = \Vendor\Extension\Middleware\MyMiddleware::class;

→ Problem: Die Reihenfolge ist nicht immer einfach steuerbar. Besser: Lazy Loading in der Middleware.

D) eID/AJAX-Calls anpassen¶

Falls der Fehler bei gecachedten eID-Skripten auftritt:

• TypoScript manuell laden:

  $tsfe = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::class);
  $tsfe->tmpl->start($tsfe->rootLine);
  

E) Cache-Verhalten prüfen¶

• config.no_cache = 1 für betroffene Seiten setzen (falls möglich).
• [FE][pageNotFoundOnCHashError] = 0 in LocalConfiguration.php prüfen (kann bei gecachten Anfragen helfen).

---

3. Betroffene TYPO3 Extension nennen¶

Der Fehler wird nicht von einer Core-Extension verursacht, sondern von:

• Einer eigenen Extension (oder einer Drittanbieter-Extension), die:
  • In ext_localconf.php/ext_tables.php auf TypoScript zugreift.
  • Eine Middleware registriert, die vor der TypoScript-Initialisierung läuft.
  • Ein eID-Skript oder AJAX-Handler nutzt, der TypoScript benötigt.

Mögliche Kandidaten:

• Extensions mit Middlewares (z. B. für Authentifizierung, Routing, API-Calls).
• Extensions, die TypoScript in ext_localconf.php parsen (z. B. für Konfiguration).
• Extensions mit Frontend-Plugins, die auf $GLOBALS['TSFE'] zugreifen.

Debugging-Tipp:

• typo3conf/ext/ nach tmpl->setup oder $GLOBALS['TSFE'] durchsuchen.
• Middleware-Stack prüfen (typo3/sysext/core/Configuration/RequestMiddlewares.php).
• Xdebug oder debug_backtrace() nutzen, um den genauen Auslöser zu finden.

---

4. Confidence (0-100%)¶

✅ 90% Confidence

• Die Ursache ist klar: TypoScript-Zugriff vor Initialisierung.
• Der Fix hängt von der genauen Extension ab, aber die Lösungsansätze sind standardisiert.
• 10% Unsicherheit, weil die genaue Extension ohne Code-Review nicht identifizierbar ist.

---

Zusammenfassung der nächsten Schritte¶

1. Extension-Code prüfen, die auf $GLOBALS['TSFE']->tmpl->setup zugreift.
2. Middleware-Reihenfolge analysieren (ggf. mit typo3/cms-core:dev-log debuggen).
3. TypoScript-Loading erzwingen (falls nötig) oder Lazy Loading implementieren.
4. Cache-Verhalten anpassen, falls der Fehler nur bei gecachten Anfragen auftritt.

Falls du den genauen Code der Extension teilen kannst, kann ich eine präzisere Lösung vorschlagen!