www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/e7c587f4-e7c4-40c2-bcdb-40a2286017a1/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

Doctrine\DBAL\Exception\DriverException: An exception occurred while executing a query: Expression #1 of SELECT list is not in GROUP BY clause and co…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache

Der MySQL/MariaDB-Server läuft mit sql_mode=only_full_group_by. Eine Abfrage auf sys_category_record_mm wählt uid_local (oder andere nicht-aggregierte Spalten) aus, ohne dass diese in der GROUP BY-Klausel auftauchen oder ein Aggregat (MIN, MAX, etc.) darum liegt. Das ist ein SQL-Standard-Verstoß, den MySQL seit 5.7 streng behandelt.

Der gezeigte Stack-Trace enthält nur die Exception-Handling-Kette (HTTP Kernel/Middleware). Die eigentliche fehlerhafte Query wird irgendwo tiefer im Application-Code gebaut – daher fehlt hier der entscheidende Frame mit der Query-Erstellung.

2. Fix (konkret)

Präferenz (richtig): Die auslösende Extension-Query anpassen.

• Alle nicht-aggregierten SELECT-Spalten in die GROUP BY-Klausel aufnehmen, oder
• uid_local durch ein Aggregat ersetzen (z. B. MIN(uid_local)), falls semantisch sinnvoll, oder
• Das GROUP BY ganz entfernen, falls keine Gruppierung nötig ist (oft genug bei MM-Tabellen).

Notbehelf (nicht empfohlen): ONLY_FULL_GROUP_BY aus dem MySQL/MariaDB sql_mode entfernen. Das verdeckt das Problem und kann zu undefinierten/inkonsistenten Ergebnissen führen.

Wenn du Zugriff auf die Query hast (z. B. via EXPLAIN oder DevLog), prüfe, ob die Extension ein Repository oder QueryBuilder-Statement nutzt und dort groupBy(...) erweitert.

3. Betroffene TYPO3 Extension

Aus den Frames allein nicht eindeutig bestimmbar. sys_category_record_mm ist eine Core-Tabelle, aber die fehlerhafte Query wird mit hoher Wahrscheinlichkeit von einer Drittanbieter-Extension gebaut, die Kategorien liest (typische Kandidaten: news, tt_address, sr_feuser_register, bootstrap_package, events2 oder eine Custom-Extension). Der TYPO3-Core selbst erzeugt diese spezifische fehlerhafte Form selten direkt.

4. Confidence

~65 % – Der Tabellenname und der Fehlertyp sind eindeutig, aber ohne den vollständigen Stack-Trace der Query-Erstellung (Extension-Key, File/Zeile) kann ich die betroffene Extension nicht mit Sicherheit benennen.

👉 Bitte poste den vollständigen Trace (ab der Query-Erstellung, nicht nur die HTTP-Middleware) – dann kann ich die Extension und die exakte Zeile benennen.