Bugsink: https://bugsink.cytrus.de/issues/issue/1c42b07d-534d-4bb9-8799-798eb643939d/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

ApacheSolrForTypo3\Solr\System\Solr\SolrCommunicationException: Invalid query. Solr returned an error: 400 Bad Request

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des SolrCommunicationException¶

1. Ursache identifizieren¶

Die ApacheSolrForTypo3\Solr\System\Solr\SolrCommunicationException mit dem Status 400 Bad Request zeigt, dass die EXT:solr (Apache Solr for TYPO3) eine fehlerhafte Query an den Apache Solr Server sendet.

Klassische Ursachen für 400 Bad Request in EXT:solr:

⚠️ Wichtige Einschränkung: Der vorliegende Stacktrace zeigt ausschließlich den TYPO3-CMS-Request-Handling-Stack (Middleware-Pipeline). Die eigentliche Fehlerstelle in EXT:solr fehlt im Trace – das Wrappen der Exception passiert typischerweise tiefer im SolrService/Query/SearchRequest Aufruf.

2. Konkrete Fix-Schritte¶

Schritt 1 – Solr Response-Logs prüfen¶

# In Solr Docker/Server:
docker logs solr 2>&1 | grep -i "undefined field\|sort field\|parse error"

→ Die Antwort enthält die genaue fehlerhafte Query/Das Feld.

Schritt 2 – Schema-Validierung¶

# Im Site-Root:
./vendor/bin/typo3 solr:schema:generate
# Anschließend Schema reloaden:
curl "http://localhost:8983/solr/<core>/schema?wt=json"

Schritt 3 – Typische Bugfixes in der Solr-Config¶

// typo3conf/sites/<site>/config.yaml oder
// in der EXT:solr Plugin-Konfiguration:
plugin.tx_solr.search.query.allowEmptyQuery = 1
plugin.tx_solr.search.results.resultsPerPage = 10

// Falls Facette/Sort-Feld fehlt:
// In config.yaml:
search:
  sorting:
    options:
      -
        field: title        # ← muss in schema.xml existieren
        direction: ASC

Schritt 4 – Debug aktivieren¶

// localconf.php / AdditionalConfiguration.php
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['solr']['logging'] = [
    'queryStringBuilder' => true,
    'search' => true,
    'searchResponse' => true,
];

Pfad: typo3temp/var/log/typo3-solr.log

Schritt 5 – Index neu aufbauen¶

./vendor/bin/typo3 solr:indexqueue:indexworkspace

3. Betroffene TYPO3 Extension¶

• EXT:solr (apache-solr-for-typoc3/solr)
• Sekundär betroffen: EXT:solr-fal / EXT:solr-news (falls dort Facetten/Sortierungen konfiguriert sind, die nicht im Schema existieren)

4. Diagnose-Code (zur Lokalisierung)¶

Falls der Fehler reproduzierbar ist, in AdditionalConfiguration.php ergänzen:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['solr']['afterRequest'][] = function($request, $response) {
    file_put_contents(
        TYPO3_VAR_PATH . 'log/solr-query.log',
        $request->getUri() . "\n\n" . $response->getRawResponse() . "\n---\n",
        FILE_APPEND
    );
};

5. Confidence¶

Confidence: 55%

Begründung: Die Fehlermeldung selbst (Solr 400 Bad Request) ist eindeutig, aber der Stacktrace zeigt nicht die relevante Stelle in EXT:solr, sondern nur den TYPO3-Middleware-Stack. Ohne:

• das Solr-Server-Log,
• den konkreten Such-URL/Query-String,
• die Site-Config,
• die schema.xml,

ist eine praxistaugliche Ursacheneingrenzung nur generisch möglich. Für eine definitive Diagnose (Confidence >90%) wird mindestens das Solr-Server-Response-Log benötigt, das das fehlerhafte Feld/Query konkret benennt.

Nächster Schritt: Solr-Log + reproduzierbares Request-Beispiel nachliefern, dann kann auf 95% Confidence eingegrenzt werden.