[Feature] Batch-Endpoints für WooCommerce Stock-Sync — 100× weniger Requests pro Lauf

[Avatarsia]

TL;DR

Der WooCommerce-Lagerbestands-Sync sendet aktuell zwei Einzel-Requests pro Artikel
(SKU-Suche + Update). Bei 1.000 Artikeln sind das 2.000 HTTP-Roundtrips pro Sync-Lauf.
WooCommerce bietet offiziell products/batch- und products/variations/batch-Endpoints,
die bis zu 100 Artikel in einem Request aktualisieren. Umstellung reduziert die
Request-Menge um Faktor ~100 und macht den Sync deutlich robuster gegen Timeouts und
Hoster-Rate-Limits.

---

Detaillierte Analyse (LLM-generiert, Claude Opus 4.7)

Problem

In www/pages/shopimporter_woocommerce.php, Methode ImportSendListLager (~Zeile 476–543),
aktualisiert der Lagerbestands-Sync jeden Artikel einzeln über zwei sequenzielle HTTP-Calls:

1. GET /wc/v3/products?sku=<sku> — SKU-zu-ID-Auflösung
2. PUT /wc/v3/products/{id} bzw. PUT /wc/v3/products/{parent_id}/variations/{id} — Update

Bei n Artikeln ergibt das 2n Roundtrips gegen den WooCommerce-Shop.

Kein Retry-Mechanismus, kein Batching. Ein einzelner Timeout oder ein 429-Response
bricht den gesamten Sync-Lauf ab — der restliche Lagerbestand bleibt stale.

Auswirkung

Shop-Größe	Requests	Ø 300 ms/Request	Laufzeit
100 Artikel	200	—	~1 Min
1.000 Artikel	2.000	—	~10 Min
5.000 Artikel	10.000	—	~50 Min

• Mittlere Hoster begrenzen oft auf 60–300 Requests/min → bei 1.000 Artikeln
  ist ein Rate-Limit-Abbruch nahezu sicher.
• Abbruch mittendrin: Rest-Bestand bleibt stale bis zum nächsten Cron-Lauf —
  potenziell Überverkäufe bei gleichzeitig eingehendem Bestellvolumen.
• Kein partielles Weiterführen nach Fehler — immer kompletter Neustart nötig.

Vorgeschlagene Lösung

Die WooCommerce REST API v3 bietet offizielle Batch-Endpoints
(Doku: https://woocommerce.github.io/woocommerce-rest-api-docs/#batch-update-products):

POST /wc/v3/products/batch
{
  "update": [
    { "id": 123, "stock_quantity": 42, "manage_stock": true },
    { "id": 456, "stock_quantity": 7,  "manage_stock": true },
    ...
  ]
}

Analog für Varianten:

POST /wc/v3/products/{parent_id}/variations/batch
{
  "update": [ { "id": 789, "stock_quantity": 15 }, ... ]
}

WooCommerce verarbeitet bis zu 100 Items pro Batch (konfigurierbares Default).

Umsetzungsschritte

1. SKU→ID-Auflösung vorverlegen: Statt pro Artikel ein GET products?sku=...
   abzusetzen, einmalig alle relevanten Produkte mit Pagination abrufen und eine
   lokale SKU-zu-ID-Map aufbauen. Spart die Hälfte aller Requests.

2. Artikel in 100er-Chunks aufteilen (einfache array_chunk-Schleife).

3. Pro Chunk einen POST .../batch-Request absetzen statt 100 Einzel-PUTs.

4. Partial-Error-Handling: Der Batch-Response enthält pro Item Success/Error.
   Nur fehlgeschlagene Items loggen, erfolgreiche als erledigt markieren — kein
   Abbruch des Gesamtlaufs.

Vorteile

• Geschwindigkeit: ~100× weniger Requests (2.000 → 20 bei 1.000 Artikeln).
• Resilienz: Ein Batch-Fehler verliert max. 100 Items statt den kompletten Sync.
• Rate-Limit-freundlich: Drastisch weniger Roundtrips → 429-Risiko minimal.
• Keine neuen Abhängigkeiten: Batch-Endpoints sind in wc/v3 seit WooCommerce 3.x
  stabil und bereits in der verwendeten API-Version enthalten.

Abgrenzung zu bestehenden Issues

• Separat von Bug: WooCommerce Bestellimport verliert Aufträge bei >20 neuen Bestellungen (fehlende Pagination + künstlicher ID-Filter) #262 (Pagination beim Bestellimport) — anderer Code-Pfad (ImportGetAuftrag
  vs. ImportSendListLager), anderer Bug-Typ.
• Separat von Bug: WooCommerce Shop Importer - JSON ERROR bei Lagerzahlenübertragung #224 (JSON-Fehler in getKonfig) — keine Überschneidung.

Betrifft

• www/pages/shopimporter_woocommerce.php — Methode ImportSendListLager, ggf.
  neue private Helper-Methoden für Batch-Chunking und SKU-Map-Aufbau.

Umgebung

• OpenXE 1.12
• WooCommerce 10.x (Batch-Endpoints seit WC 3.x stabil)
• WordPress 6.x