[Refactor] WooCommerce-Client als Composer-Dependency statt Inline-Fork

[Avatarsia]

TL;DR

In `www/pages/shopimporter_woocommerce.php` ist ab Zeile 1021 eine ~1.300-Zeilen-Kopie des
offiziellen `automattic/woocommerce`-PHP-SDK in der Version v3.0.0 von 2019 eingebettet.
Das Upstream-SDK ist seither mehrfach weiterentwickelt worden (Security-Fixes zu TLS/OpenSSL,
PHP-8.x-Kompatibilitätsverbesserungen, Bugfixes) — OpenXE bekommt davon nichts mit. Umstellung
auf die offizielle Composer-Dependency `automattic/woocommerce` entfernt die eingefrorene Kopie,
verschlankt den Importer um ~1.300 Zeilen und stellt sicher, dass zukünftige Upstream-Patches
automatisch einfließen.

---

Detaillierte Analyse (LLM-generiert, Claude Opus 4.7)

Problem

Inline-Fork eines eingefrorenen SDKs

In `shopimporter_woocommerce.php` sind ab Zeile 1021 die Klassen `WCClient`, `WCHttpClient`,
`WCResponse`, `WCRequest`, `WCOAuth`, `WCBasicAuth`, `WCOptions` und
`WCHttpClientException` als vollständige Kopie eingebettet. Die Versionskonstante
`WCClient::VERSION = '3.0.0'` belegt: dies ist der Stand von 2019.

Das Upstream-Paket `automattic/woocommerce` ist inzwischen bei v3.1.x — mit
Security-relevanten Änderungen:

• cURL-TLS-Handling und OpenSSL-Verifikation nachgehärtet
• OAuth 1.0a-Signatur-Erzeugung robuster gemacht
• PHP-8.x-Kompatibilitätslücken geschlossen
• Diverse HTTP-Header-Zugriffsbugs gefixt

Keine dieser Verbesserungen ist in OpenXEs Inline-Kopie angekommen.
Dazu kommt: es gibt keine Update-Strategie, keine Diff-Markierungen, keine Test-Abdeckung
der inlined Klassen — Upstream-Divergenz ist weder sichtbar noch beherrschbar.

Auswirkung

Security-Debt

Zukünftige Schwachstellen im Transport-Layer bleiben in OpenXE unbehoben, obwohl Upstream
sie längst fixt. Da das SDK direkt die HTTPS-Verbindung zur WooCommerce-REST-API aufbaut,
ist das kein theoretisches Risiko.

Erhöhter Wartungsaufwand

Bugs wie fehlerhafte Response-Header-Zugriffe (→ Issue #262) müssen manuell in die Inline-Kopie
gepatcht werden, anstatt sie per `composer update` aus Upstream zu ziehen. Jeder SDK-seitige
Bugfix kostet so eigene Analyse- und Testzeit.

Schlechte Datei-Ergonomie

`shopimporter_woocommerce.php` umfasst 2.370 Zeilen, davon ca. 1.300 reines Boilerplate-SDK.
Die eigentliche Businesslogik (Bestell-, Artikel- und Kundenimport) liegt in den ersten ~1.000
Zeilen. Das Verhältnis von 55 % generischem HTTP-Client zu 45 % Businesslogik erschwert
Code-Review und Onboarding erheblich.

Vorgeschlagene Lösung

1. Composer-Dependency einführen

composer require automattic/woocommerce

Das Paket ist unter der MIT-Lizenz veröffentlicht, aktiv gewartet und kompatibel mit
PHP 7.4+.

2. Namespace-Migration

Inline-Klasse	Upstream-Klasse
`WCClient`	`Automattic\WooCommerce\Client`
`WCHttpClient`	`Automattic\WooCommerce\HttpClient\HttpClient`
`WCResponse`	`Automattic\WooCommerce\HttpClient\Response`
`WCRequest`	`Automattic\WooCommerce\HttpClient\Request`
`WCOAuth`	`Automattic\WooCommerce\HttpClient\OAuth`
`WCBasicAuth`	`Automattic\WooCommerce\HttpClient\BasicAuth`
`WCOptions`	`Automattic\WooCommerce\HttpClient\Options`
`WCHttpClientException`	`Automattic\WooCommerce\HttpClient\HttpClientException`

Die Migration ist mechanisch — alle Aufrufstellen befinden sich innerhalb von
`shopimporter_woocommerce.php`.

3. Inline-SDK entfernen

Zeilen 1021–2370 vollständig löschen. Die Datei schrumpft von 2.370 auf ~1.070 Zeilen.

4. Smoke-Test

Durch Issue #262 existiert eine funktionierende End-to-End-Test-Matrix gegen eine
Docker-WooCommerce-Instanz. Diese lässt sich direkt als Regressions-Absicherung für
die SDK-Migration wiederverwenden — kein separater Test-Aufbau notwendig.

Vorteile

• Security-Hygiene: Upstream-Patches (OpenSSL, TLS, OAuth) landen automatisch in
  OpenXE sobald `composer update` läuft.
• Weniger Code: `shopimporter_woocommerce.php` schrumpft von 2.370 auf ~1.070 Zeilen.
• Wartbarkeit: `composer update` statt manuelles Diff-Mergen bei jedem SDK-Bug.
• Branch-Konsolidierung: Offene WC-PRs (Bug: WooCommerce Bestellimport verliert Aufträge bei >20 neuen Bestellungen (fehlende Pagination + künstlicher ID-Filter) #262, ggf. [Feature] WooCommerce Webhook Support — Push statt Polling für Bestellimport #239 Webhook-Support, Batch-Sync)
  können auf einer gemeinsamen, aktuellen SDK-Basis aufbauen.
• Composer-Ökosystem: Das Paket erscheint in `composer.lock` — Abhängigkeits-Audits
  (z.B. `composer audit`) greifen dann auch für den WC-Client.

Aufwand & Risiko

Aspekt	Einschätzung
Einmalaufwand	Mittelgroß — Namespace-Refactor ist mechanisch, aber gründlich zu testen
Hauptrisiko	Die Inline-Kopie könnte stillschweigende interne Anpassungen enthalten (Logging, Auth-Flags o.ä.), die im Upstream fehlen
Pflicht-Schritt	Sorgfältiger Diff zwischen Inline-Code und `automattic/woocommerce` v3.0.0 vor der Migration
Migrationsweg	Schrittweise möglich: erst Composer-Dependency parallel installieren, dann Aufrufstellen umstellen, dann Inline-Kopie löschen

Abgrenzung zu bestehenden Issues

• Separat von Bug: WooCommerce Bestellimport verliert Aufträge bei >20 neuen Bestellungen (fehlende Pagination + künstlicher ID-Filter) #262 (Pagination-Fix): Dort wurde der Inline-Client minimal gepatcht,
  aber nicht migriert. Die Composer-Migration ist der logische nächste Schritt danach.
• Blockt nicht Bug: WooCommerce Bestellimport verliert Aufträge bei >20 neuen Bestellungen (fehlende Pagination + künstlicher ID-Filter) #262 oder [Feature] WooCommerce Webhook Support — Push statt Polling für Bestellimport #239 — kann unabhängig und nachgelagert erfolgen.

Betrifft

• `www/pages/shopimporter_woocommerce.php` (Inline-SDK-Bereich, Zeilen ~1021–2370)
• `composer.json` / `composer.lock`

Umgebung

• OpenXE 1.12
• PHP 8.x (automattic/woocommerce v3.1 unterstützt PHP 7.4+)
• WooCommerce 10.x (REST v3 abwärtskompatibel seit WC 3.x)