Bug #300
offen[Bugsink] TYPO3\CMS\Form\Exception: There is no page with an index of -1
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/5b9262c1-018e-4561-b8a5-db672799e428/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
TYPO3\CMS\Form\Exception: There is no page with an index of -1
Automatisch erstellt durch n8n
KI-Analyse:
1. Ursache
Die Exception TYPO3\CMS\Form\Exception: There is no page with an index of -1 wird aus TYPO3\CMS\Form\Domain\Model\PageRepository::getPageByIndex() geworfen. Diese Methode prüft, ob der übergebene Index innerhalb des gültigen Bereichs [0, count($pages)-1] liegt. Ein Wert von -1 bedeutet, dass der Code versucht, auf eine Form‑Seite zuzugreifen, obwohl entweder
- das Formular keine Seiten definiert hat (die interne
$pages‑Liste ist leer), oder - ein Formular‑Element (z. B. ein
fieldset, einfieldoder ein Custom‑Finisher) die aktuelle Seite mit einem ungültigen Index-1anspricht (z. B. über ein falsch konfiguriertespage‑Property in FlexForm, TypoScript oder über eine vom Entwickler gesetztecurrentPage‑Variable).
Der Stack‑Trace zeigt, dass die Exception während des normalen HTTP‑Request‑Flows (Middleware‑Dispatcher) auftritt – also beim Rendern einer Seite, die ein Formular aus der Core‑Extension Form enthält.
2. Konkret zu beschreibender Fix
| Schritt | Beschreibung |
|---|---|
| a. Formular‑Definition prüfen | Im Backend → Form → betroffenes Formular öffnen und sicherstellen, dass mindestens eine Seite (Tab) definiert ist. Wenn das Formular absolut keine Seiten hat, entweder eine Seite hinzufügen oder das Formular löschen/ neu anlegen. |
| b. Ungültige Seitenreferenzen entfernen | Untersuche alle Formular‑Elemente (Felder, Fieldsets, Finishers) auf Eigenschaften wie page, pageUid oder currentPage. Diese dürfen niemals -1 sein. Setze sie auf eine existierende Seiten‑Index (z. B. 0 für die erste Seite) oder entferne die Eigenschaft, falls sie nicht benötigt wird. |
| c. Cache leeren | Nach Änderungen das System‑Cache (typo3temp/var/cache/) und insbesondere den Form‑Cache (typo3temp/var/cache/Form/) leeren, damit das Formular neu eingelesen wird. |
| d. Eigene Erweiterungen überprüfen | Falls ein eigenes Extension‑ oder TypoScript‑Snippet das Formular‑Rendering beeinflusst (z. B. über formFactory, FormViewHelper oder einen eigenen Finisher), stelle sicher, dass es nicht $form->setCurrentPage(-1) oder ähnliche Aufrufe setzt. |
| e. Fallback‑Logik prüfen | Wenn das Formular dynamisch erzeugt wird (z. B. über ein Plugin, das Formulare aus einer Datenbank baut), stelle sicher, dass die erzeugte Formular‑Definition immer mindestens eine Seite enthält, bevor sie an den Form‑Renderer übergeben wird. |
Kurzfassung des Fixes:
Stelle sicher, dass das betroffene Formular mindestens eine Seite besitzt und dass keinerlei Code versucht, auf einen Seiten‑Index -1 zuzugreifen. Nach Korrektur den Cache leeren.
3. Betroffene TYPO3‑Extension
Die Ausnahme stammt aus der Core‑Extension form (TYPO3\CMS\Form). Deshalb ist die betroffene Extension die Form‑Extension (System‑Extension, nicht eine Dritt‑Party‑Extension).
4. Confidence
90 % – Der Fehler ist eindeutig in PageRepository::getPageByIndex() verortet und die üblichen Ursachen (leere Seitenliste oder ungültiger Index) erklären zu 100 % die beobachtete Exception. Der geringe Unsicherheitsfaktor ergibt sich daraus, dass die genaue Stelle, wo der -1‑Index gesetzt wird (Backend‑Formular‑Editor, eigenes Typoscript/Skript oder eine Dritt‑Party‑Extension), ohne weitere Projektspezifika nicht direkt aus dem Stack‑Trace ersichtlich ist. Mit den genannten Prüfungen lässt sich das Problem jedoch sicher beheben.
Nichts anzuzeigen