Bug: WooCommerce Bestellimport verliert Aufträge bei >20 neuen Bestellungen (fehlende Pagination + künstlicher ID-Filter)

[Avatarsia]

TL;DR

Der WooCommerce-Shopimporter verliert stillschweigend Bestellungen, wenn mehr als 20
neue Aufträge zwischen zwei Cron-Läufen eingehen. Zwei Ursachen: (1) kein Pagination-Loop
— nur die erste Seite der REST-Antwort wird gelesen, (2) ein künstlicher "fake"-ID-Filter
mit 800 hochgezählten IDs statt des offiziellen after-Datumsfilters. Fix ist ohne neue
Plugin-Abhängigkeiten mit Bordmitteln der WooCommerce-REST-v3 möglich.

---

Detaillierte Analyse (LLM-generiert, Claude Opus 4.7)

Problem

Der WooCommerce-Shopimporter kann bei größeren Bestellmengen Aufträge stillschweigend
verlieren. Zwei unabhängige Ursachen im Bestellimport-Flow:

1. Keine Pagination beim Bestellabruf

In shopimporter_woocommerce.php:

• ImportGetAuftraegeAnzahl (Zeile ~80) setzt per_page=100 und liest nur Seite 1.
• ImportGetAuftrag (Zeile ~138) setzt per_page=20 und liest nur Seite 1.

Wenn seit dem letzten Lauf mehr als 20 neue Bestellungen im passenden Status vorliegen,
werden nur die ersten 20 importiert. Die restlichen bleiben liegen — und werden beim nächsten
Lauf ebenfalls nicht zuverlässig abgeholt, weil der nachgelagerte ID-Filter (siehe 2.) sie
nicht unbedingt findet.

Ein Code-Kommentar im Modul selbst (Zeile 82-84) nennt das Problem bereits:

"We set per_page to 100 — this could lead to a situation where there are more than
100 new Orders, but we still only return 100."

2. Künstlicher ID-Filter statt Datumsfilter

Statt "neue Bestellungen seit letztem Import" via Datum abzufragen, baut der Code eine
include-Liste mit 800 künstlich hochgezählten Bestell-IDs (Zeile 99-113, 153-167):

• Eigener Kommentar bezeichnet das als "fake" "greater-than-id"-Filter.
• Bei mehr als 800 Bestellungen zwischen zwei Imports → ebenfalls Datenverlust.
• Die URL wird durch 800 IDs sehr lang und kann an Webserver-Limits (z.B. Nginx
  large_client_header_buffers, mod_security) scheitern.

Auswirkung

• Bei aktiven Shops mit mehr als 20 Bestellungen pro Import-Intervall: stiller Datenverlust.
• Kein Fehler im Log — der Importer meldet "fertig", Bestellungen fehlen einfach.
• Besonders kritisch bei Black-Friday-/Weihnachts-Peaks oder bei nach Ausfall nachgeholten Imports.

Vorgeschlagene Lösung

Die offizielle WooCommerce-REST-API wc/v3 bietet beides bereits — es werden lediglich nicht
genutzte Features aktiviert:

1. Pagination korrekt umsetzen:

   • Antwort-Header X-WP-TotalPages auswerten.
   • Über alle Seiten iterieren, bis alle neuen Bestellungen abgeholt sind.
   • Sinnvolle Obergrenze je Lauf konfigurierbar (z.B. max. 500/Lauf, Rest beim nächsten Cron).

2. after-Parameter statt ID-Liste:

   • WooCommerce kennt offiziell after=<ISO-8601> für Bestellungen.
   • "Timestamp des letzten erfolgreich importierten Auftrags" persistieren und beim
     nächsten Lauf als after setzen.
   • 800er-include-Liste entfällt komplett.

Vorteile

• Kein stiller Datenverlust mehr, auch bei Spitzenlast.
• Kürzere URLs, keine Nginx-/WAF-Probleme durch lange Query-Strings.
• Weniger Speicher, weil keine 800er-ID-Liste gehalten wird.
• Keine neuen Plugin-Abhängigkeiten, keine API-Version-Änderung — alles in wc/v3 bereits enthalten.

Abgrenzung zu bestehenden Issues

• Separat von [Feature] WooCommerce Webhook Support — Push statt Polling für Bestellimport #239 (Webhook-Support) — auch mit Webhooks bleibt Pagination für
  Recovery/Reconcile-Läufe relevant.
• Separat von Bug: WooCommerce Shop Importer - JSON ERROR bei Lagerzahlenübertragung #224 (JSON-Fehler in getKonfig) — anderes Code-Segment, andere Ursache.

Betrifft

• www/pages/shopimporter_woocommerce.php (Zeile 80-180 und 2370-zeilige Client-Klasse)
• Optional: Persistenz-Feld für "letzter erfolgreicher Import-Timestamp" in shopexport
  oder existierender Einstellungs-Struktur.

Umgebung

• OpenXE 1.12
• WooCommerce 10.x
• WordPress 6.x