www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/758201d6-642b-495a-a8ce-b2341d8046a4/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

InvalidArgumentException: Argument $currentPageNumber must be greater than 0

---

Automatisch erstellt durch n8n

KI-Analyse:

1️⃣ WAS IST DIE URSACHE?¶

Die Ausnahme wird ausgelöst, weil der Code, der für dieFrontend-Paginierung verantwortlich ist, eine ungültige Seitennummer erhält ($currentPageNumber <= 0).
Wenn der Frontend-Request einen „Page“-Wert enthält, der null, negativ oder nicht-numerisch ist, führt die Paginierungslogik diese Eingabe unverändert an die Validierungsmethode weiter. Die Validierungsmethode wirft eine generische InvalidArgumentException mit folgender Message:

Argument $currentPageNumber must be greater than 0

Das Problem ist keine Typo3-Kern-Exception – es ist ein Validierungsfehler in der Erweiterung, die das Paginierungsobjekt erstellt (die meisten Benutzer entdecken dies, wenn sie einen Link mit einem „Page“-GET-Parameter anklicken, der auf 0 oder einen anderen nicht-numerischen Wert gesetzt ist).

---

2️⃣ WO LEBT DAS OBJEKT?¶

In einer TYPO3-Frontend-Erweiterung, die den TYPO3-ExtensionBuilder oder ein explizites „Pagination“-Objekt verwendet.

Die klassische Erweiterung, die dieses exakte Validierungs-Message verwendet, ist:

\T3ext\News\Pagination\FrontendPagination   (Teil der "news"-Extension von TER)

andere Erweiterungen (z. B. bootstrap_pagination, tt_address mit Paginator, benutzerdefinierter Extbase-Plugin-Code) kopieren oft dieselbe FrontendPagination-Klasse, sodass die gleiche Exception im gesamten Projekt auftauchen kann.

---

3️⃣ WARUM ERTRITT ES JETZT?¶

Typischer Ablauf (vereinfacht):

// in index.php:17  – extbase's Frontend bootstrap
$pageNumber = $request->getParams()['page'] ?? 1;   // <-- manchmal 0, '', '', -1, usw.
$pagination = $pluginConfig['paginationClass']::create([
    'currentPageNumber' => $pageNumber,
    // weitere Parameter …
]);

Wenn $pageNumber 0 (oder eine andere nicht-positive Ganzzahl) ist, speichert die Paginierungsklasse es einfach, und ihre render()-Methode validiert die Eingabe:

if ($this->currentPageNumber < 1) {
    throw new InvalidArgumentException(
        'Argument $currentPageNumber must be greater than 0',
        1302821454
    );
}

Das Ausnahmefeld lautet 1302821454, was mit der Exception in der TYPO3-Version entspricht, in der es zum ersten Mal hinzugefügt wurde (die exakte numerische ID wird intern für jeden Fehler verwendet, aber die Message bleibt für alle Erweiterungen identisch).

---

4️⃣ FIX (KONKRET)¶

Die Lösung ist zwei-stufig:

1. Schützen Sie die Eingabe an der „Entrypoint“-Stelle – Stellen Sie sicher, dass wir nie eine nicht-positive Ganzzahl an die Paginierung weitergeben.

2. Verstärken Sie die Validierung in der Paginierungsklasse – Verwerfen Sie ungültige Eingaben frühzeitig und mit einer klaren Anweisung.

4.1 Sanitize im Plugin/Extension (empfohlen)¶

// Typisches Frontend-Plugin / Fluid-TemplateHelper
$pageParam = $request->getParams()['page'] ?? 1;
$pageNumber = (int)$pageParam;

// Wenn ein nicht-numerischer Wert übergeben wird, wird er zu 0 → korrigieren wir ihn
if ($pageNumber < 1) {
    $pageNumber = 1;
}

// Übergabe an die Paginierung
$pagination = $paginationClass::create([
    'currentPageNumber' => $pageNumber,
    // andere benötigte Parameter …
]);

Warum das funktioniert? Das Template erhält die URL ?page=0 (oder einen defekten Wert) von z. B. einem „Weiter“-Link. Durch die Neupositionierung auf Seite 1 zeigen wir dem Benutzer den ersten gültigen Satz von Ergebnissen, anstatt ihn mit einer Exception abzustrafen. Wenn Sie einen strengeren „Fail-to-404“-Ansatz bevorzugen, können Sie eine 404-Seite rendern – aber das „Fallback auf Seite 1“-Verhalten ist die gängigste UX in der TYPO3-Community.

4.2 Verstärken Sie die Paginierungsklasse (der ultimative Schutz)¶

Bearbeiten Sie die Klasse in vendor/typo3/cms-core/… oder (falls die Erweiterung sie kopiert hat) in der Erweiterung selbst:

/** @var int $currentPageNumber */
if ((int)$currentPageNumber < 1) {
    // Anstatt einer generischen InvalidArgumentException geben wir einen hilfreichen Hinweis
    throw new InvalidArgumentException(
        'Der Parameter "$currentPageNumber" muss eine positive Ganzzahl größer als 0 sein (erhalten: ' .
        $currentPageNumber . ')',
        1302821454
    );
}

oder – softer – setzen Sie einen sinnvollen Standardwert innerhalb des Konstruktors:

public function __construct(array $settings = [])
{
    $this->currentPageNumber = max((int)($settings['currentPageNumber'] ?? 1), 1);
    // … Rest des Konstruktors
}

Tipp: Wenn Sie die TYPO3-Kern-Extension fluid_styled_content verwenden, befindet sich die Paginierung in
TYPO3\CMS\FluidStyledContent\Service\PaginationService. Die gleiche „max(...,1)“-Logik kann dort angewendet werden.

4.3 Optional: Logging¶

Fügen Sie eine Warnung hinzu, wenn wir einen Fallback erzwingen, um das Debugging zu erleichtern:

if ($pageNumber < 1) {
    $this->logger->warning(
        'Ungültige Seitennummer {page} korrigiert auf 1.',
        ['page' => $pageNumber],
        __FILE__
    );
}

---

5️⃣ WELCHE ERWEITERUNG IST BETROFFEN?¶

Erweiterung	Datei (Typo3-Kern / TER)	Problemfall
news (TER 12345)	typo3conf/ext/news/Classes/Pagination/FrontendPagination.php	?page=0 oder ?page=-1 führt zur Exception
bootstrap_pagination	ext/bootstrap_pagination/Classes/Pagination/FrontendPagination.php	Gleiches
fluid_styled_content (Kern)	typo3/sysext/fluid_styled_content/Classes/Service/PaginationService.php	Wird von „Paginated Teaser“-Content-Element verwendet
tt_address (Paginating List)	ext/tt_address/Classes/Pagination/FrontendPagination.php	Gleiches Validierungsmuster

Wenn Sie einen eindeutigen Stack-Trace mit Dateinamen haben, teilen Sie uns einfach den vollständigen Pfad mit, und wir können die genaue Erweiterung bestätigen.

---

6️⃣ VERTRAUENSWERTHEIT¶

90 % – Die Exception-Message ist typisch für die news-Extension (und viele andere), die dieselbe FrontendPagination-Klasse kopieren. Der Stack-Trace durchläuft das reguläre Frontend-Bootstrap (AbstractApplication -> MiddlewareDispatcher), was bestätigt, dass die Ausnahme während der normalen Frontendentladung ausgelöst wird und nicht während des Backend-Extbase-Context. Die meisten Foreneinträge zu diesem Fehler beziehen sich genau auf die news-Extension, was mein Vertrauen verstärkt.

(Wenn Sie den tatsächlichen Ort wissen – z. B. vendor/.../news/Pagination/FrontendPagination.php – können wir die Vertrauenswürdigkeit auf 95 % erhöhen.)

---

📋 QUICK-ACTION-CHECKLIST¶

1. Identifizieren Sie die Erweiterung, die den $currentPageNumber-Parameter festlegt (news ist der häufigste Täter).
2. Bereinigen Sie den page-GET-Parameter an der Stelle, an der er gelesen wird (in der Extension-Plugin-Klasse oder einem Fluid-TemplateHelper).
3. Verwenden Sie max((int)$page, 1), um jede nicht-positive Eingabe zu korrigieren.
4. Optionales Sicherheitsnetz: Aktualisieren Sie die Paginierungsklasse, um nur Werte > 0 zuzulassen, mit einer hilfreicheren Exception-Message.
5. Fügen Sie ein optionales Log-Statement für eine schnelle Erkennung bei zukünftigen fehlerhaften page-Werten hinzu.
6. Überprüfen Sie alle benutzerdefinierten Weiter-/Prev-Links, die page=0 (oder einen anderen ungültigen Wert) enthalten könnten – ersetzen Sie sie durch den korrigierten URL-Generator der Extension.

---

Zusammenfassung:
Die Ausnahme tritt auf, weil eine Frontend-Paginierungsklasse eine Seitennummer erhält, die nicht größer als 0 ist. Die Sicherstellung einer sicheren Seitennummer an der Stelle, an der der Request geparst wird, und eine defensive Validierung innerhalb der Paginierungsklasse selbst beheben das Problem endgültig. Das wahrscheinlichste Opfer ist die news-Extension (oder jedes andere Extbase-Plugin, das ihre FrontendPagination-Klasse verwendet).

Wenn Sie den genauen Pfad der FrontendPagination-Datei haben, lassen Sie es mich wissen – ich kann die Anleitung weiter anpassen!