www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/e5eb7a35-5be6-4f34-972a-5c59b08dc7c9/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

ErrorException: Warning: Trying to access array offset on null

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers: "Trying to access array offset on null"¶

1. Ursache identifizieren¶

Der Fehler ErrorException: Warning: Trying to access array offset on null tritt auf, wenn versucht wird, auf ein Array-Element zuzugreifen, das null ist (also kein Array). Dies passiert typischerweise in folgenden Szenarien:

• Fehlende Initialisierung eines Arrays (z. B. $config = null statt $config = []).
• Datenbankabfrage oder API-Response liefert null, aber der Code erwartet ein Array.
• Middleware oder Request-Handling greift auf nicht gesetzte Server-Variablen zu (z. B. $_SERVER, $_GET, $_POST).
• TYPO3-Konfiguration oder Extension-Code liest ein nicht existierendes Array-Feld (z. B. $GLOBALS['TYPO3_CONF_VARS']['EXTENSIONS']['my_ext']['setting']).

Konkrete Einordnung im Stacktrace:

• Der Fehler tritt in der Middleware-Kette von TYPO3 auf, insbesondere in:
  • VerifyHostHeader.php (Zeile 55)
  • NormalizedParamsAttribute.php (Zeile 44)
• Beide Middlewares greifen auf Request-Parameter oder Server-Variablen zu, die möglicherweise nicht gesetzt sind (z. B. $_SERVER['HTTP_HOST'], $_SERVER['SERVER_NAME'] oder $request->getServerParams()).

Häufige Auslöser in TYPO3:

• Fehlende oder falsche Host-Konfiguration in typo3conf/LocalConfiguration.php (z. B. SYS/trustedHostsPattern).
• CLI-Aufrufe oder Cronjobs, bei denen $_SERVER-Variablen nicht gesetzt sind.
• Extensions, die auf nicht initialisierte Request-Parameter zugreifen (z. B. in ext_localconf.php oder Controllern).

2. Fix beschreiben (konkret)¶

Mögliche Lösungen:

A) Host-Header-Prüfung anpassen (VerifyHostHeader.php)¶

• Problem: Die Middleware VerifyHostHeader prüft $_SERVER['HTTP_HOST'], aber dieser Wert ist in CLI-Kontexten oder bei bestimmten Proxy-Konfigurationen nicht gesetzt.
• Fix:
  • In typo3conf/LocalConfiguration.php die trustedHostsPattern korrekt konfigurieren:

    'SYS' => [
        'trustedHostsPattern' => '.*', // Nur für Entwicklung! In Produktion spezifischer setzen.
    ],
    

  • Oder die Middleware deaktivieren (nicht empfohlen für Produktion):

    $GLOBALS['TYPO3_CONF_VARS']['SYS']['features']['security.frontend.allowInsecureHostHeader'] = true;
    

B) Null-Checks in Middlewares einbauen¶

• Problem: NormalizedParamsAttribute oder VerifyHostHeader greifen auf nicht gesetzte Variablen zu.
• Fix:
  • Patch für VerifyHostHeader.php (Zeile 55):

    // Vorher:
    $host = $request->getServerParams()['HTTP_HOST'];
    
    // Nachher:
    $serverParams = $request->getServerParams();
    $host = $serverParams['HTTP_HOST'] ?? '';
    if (empty($host)) {
        throw new \TYPO3\CMS\Core\Exception('Host-Header fehlt im Request.', 1518472182);
    }
    

  • Patch für NormalizedParamsAttribute.php (Zeile 44):

    // Vorher:
    $scriptName = $request->getServerParams()['SCRIPT_NAME'];
    
    // Nachher:
    $scriptName = $request->getServerParams()['SCRIPT_NAME'] ?? '';
    

C) Extension-Code prüfen¶

• Falls der Fehler in einer eigenen Extension auftritt:
  • Null-Checks vor Array-Zugriffen einbauen:

    // Vorher:
    $value = $config['some_key'];
    
    // Nachher:
    $value = $config['some_key'] ?? null;
    if ($value === null) {
        throw new \RuntimeException('Konfiguration fehlt: some_key', 1620000000);
    }
    

  • Arrays initialisieren:

    // Vorher:
    $data = $someService->getData(); // Kann null sein
    
    // Nachher:
    $data = $someService->getData() ?? [];
    

3. Betroffene TYPO3 Extension nennen¶

Der Fehler stammt aus dem TYPO3 Core, genauer aus den Middlewares:

• TYPO3\CMS\Core\Middleware\VerifyHostHeader
• TYPO3\CMS\Core\Middleware\NormalizedParamsAttribute

Mögliche Auslöser in Extensions:

• Extensions, die auf $_SERVER oder Request-Parameter zugreifen (z. B. SEO-Extensions, Routing-Extensions).
• Extensions mit eigener Middleware, die nicht auf null-Werte prüfen.
• Extensions, die GeneralUtility::_GP() oder ähnliche Funktionen nutzen, ohne Default-Werte zu setzen.

Typische Kandidaten:

• ext:seo (falls Host-Header für Canonical-URLs genutzt wird)
• ext:realurl oder ext:routing (falls Request-Parameter falsch verarbeitet werden)
• Eigene Extensions mit Middleware oder Request-Handling.

4. Confidence (0-100%)¶

• 90% – Der Fehler ist klar auf fehlende Null-Checks in TYPO3-Core-Middlewares zurückzuführen.
• 10% Unsicherheit – Falls der Fehler durch eine spezifische Extension ausgelöst wird, die nicht im Stacktrace sichtbar ist.

Zusammenfassung der nächsten Schritte¶

1. Prüfen, ob der Fehler in CLI oder Web-Kontext auftritt (CLI hat oft keine $_SERVER-Variablen).
2. trustedHostsPattern in LocalConfiguration.php anpassen (siehe Fix A).
3. Null-Checks in den betroffenen Middlewares einbauen (siehe Fix B).
4. Extensions mit Request-Handling prüfen (siehe Punkt 3).
5. TYPO3-Log (var/log/typo3_*.log) auf weitere Hinweise analysieren.

Falls der Fehler nach diesen Schritten weiterhin auftritt, wäre ein Debugging mit Xdebug oder ein Minimal-Beispiel (z. B. leere TYPO3-Installation mit nur der betroffenen Extension) hilfreich.