www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/7f8af95f-b3b5-415c-aa4b-c2b026b07907/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

TYPO3\CMS\Extbase\Persistence\Generic\Storage\Exception\SqlErrorException: An exception occurred while executing a query: Incorrect DATE value: '2026…

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers:

Der Fehler mysqli_sql_exception: Incorrect DATE value: '2026-(,)"bmo-znf' deutet auf ein Problem mit einer Datumsangabe hin, die versucht wird, in eine Datenbankspalte mit dem Typ DATE einzufügen oder davon zu lesen. Der Wert '2026-(,)"bmo-znf' ist kein gültiges Datum und weist auf eine fehlerhafte Verarbeitung oder Generierung eines Datumswerts hin.

1. Ursache identifizieren¶

Die Ursache ist eine fehlerhafte Eingabe oder Verarbeitung eines Datumswerts, der Versuch wird, diesen Wert direkt oder über eine TYPO3-Extension in eine Datenbanktabelle mit einer DATE-Spalte zu schreiben.

• Der Wert 2026-(,)"bmo-znf" ist kein gültiges SQL-Datum (Format: YYYY-MM-DD) und weist Zeichen hin, die typisch für eine fehlerhafte Stringmanipulation oder Injection sind.
• Dies könnte durch:
  • Eine fehlerhafte Formularverarbeitung in einer Extension
  • Ein fehlerhaftes Migration- oder Update-Skript
  • Eine fehlerhafte Konfiguration (z. B. ein dynamisch generiertes Datum)
  • Eine fehlerhafte Datenbankabfrage (z. B. in einem Hook, einer Middleware oder einem Plugin)

ausgelöst worden sein.

Zudem wird deutlich, dass der Fehler vor der eigentlichen Anwendungslogik (also bereits in der Initialisierung der Anwendung) auftritt — erst ab der zweiten Zeile von index.php und weiter über die Kernmiddleware-Klassen von TYPO3.

Das bedeutet:
➡️ Der Fehler tritt bereits beim Starten der Anwendung auf, nicht innerhalb einer konkreten Extension-Logik.
➡️ Es liegt höchstwahrscheinlich an einer Middleware, die versucht, ein Datum zu verarbeiten oder zu validieren.

Betrachten wir den Stacktrace genauer:

- /public/index.php:21 -> 
- /public/index.php:20 -> {closure:/public/index.php:17}
...
/vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.php:55
/vendor/typo3/cms-core/Classes/Middleware/NormalizedParamsAttribute.php:44

Diese Middleware-Klassen verarbeiten z. B. Host-Header und generalisierte Parameter, aber keine Datenbanklogik. Also ist sehr unwahrscheinlich, dass der Fehler direkt hier entsteht.

➡️ Höchstwahrscheinlich wird dieser Wert dynamisch generiert und versucht, in die Datenbank geschrieben zu werden – vermutlich durch eine Extension, die versucht, ein Datum (z. B. ein Ablaufdatum) zu setzen.

2. Fix beschreiben (konkret)¶

Mögliche Ursache: Feuerwehr-Einsatz- oder Baustellen-Tool oder ähnliche Extension¶

Ein häufiger Fall ist, dass solche Datumswerte aus einer Extension stammen, die ein Datum aus einer Eingabe (z. B. via GET/POST), einer Konfiguration oder einem Skript generiert hat.

Konkreter Fix-Vorschlag:¶

1. Eingabevalidierung für Datumswerte erzwingen:

   $inputDate = $_GET['date'] ?? null;
   
   if ($inputDate) {
       try {
           $date = new \DateTime($inputDate);
       } catch (\Exception $e) {
           // Ungültiges Datum abfangen
           throw new \InvalidArgumentException("Ungültiges Datum: " . htmlspecialchars($inputDate));
       }
   }
   

2. Verwendung von TYPO3-eigenen Helfern (GeneralUtility::makeInstance, Typo3QuerySettings, etc.), um sicherzustellen, dass alle Eingaben validiert sind.

3. Datenbankabfragen mit Prepared Statements nutzen:

   $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)->getQueryBuilderForTable('tx_myextension_domain_model_entry');
   $queryBuilder->insert('tx_myextension_domain_model_entry')
       ->values([
           'date_field' => $date->format('Y-m-d'), // Validiertes Datum!
       ])
       ->execute();
   

4. Falls Migration oder Cron-Job betroffen ist: Prüfe alle Skripte, die INSERT oder UPDATE-Operationen mit Datumsfeldern durchführen.

5. Loggen und Debuggen aktivieren:
   In typo3conf/LocalConfiguration.php:

   'LOG' => [
       'TYPO3' => [
           'CMS' => [
               'level' => 'debug',
           ],
       ],
   ],
   

3. Betroffene TYPO3 Extension nennen¶

Basierend auf dem gegebenen Kontext ist keine konkrete Extension eindeutig benannt, da der Fehler innerhalb der TYPO3-Kerninfrastruktur auftritt. Allerdings:

Wenn der Wert dynamisch generiert wurde (z. B. 2026-(,)"bmo-znf"), könnte dies auf folgende Extensions hindeuten:

• mask / mask_export – falls dynamische Inhalte oder Datenbankfelder automatisch generiert werden.
• Custom Extensions mit Formularen oder Webhooks, die Benutzereingaben direkt in die DB schreiben.
• Migrationen oder Tasks, die falsche Datumswerte generieren.

🔍 Typische Extensions, die diesen Fehler verursachen können:

• gridelements
• mask
• bootstrap_package
• filelist
• Eigenentwickelte Extensions mit Datenbankzugriff

Wenn du weitere Infos zu installierten Extensions hast (z. B. aus typo3conf/ext/), kann ich genauer eingrenzen.

✅ Zusammenfassung¶

Wenn du möchtest, kann ich dir auch helfen, gezielt nach der Extension zu suchen, die diesen Wert generiert – sag einfach Bescheid mit z. B. einer Liste der installierten Extensions oder einem Auszug aus dem Code, wo das Datum verarbeitet wird.