[Warten auf das Feedback der Benutzer] WooCommerce REST API gibt falsches Ergebnis zurück, wenn WPML String Translation aktiv ist

Damit wir das Verhalten gezielt analysieren können, benötige ich bitte eine konkrete Schritt-für-Schritt-Anleitung zur Reproduktion des Problems in Ihrer Testumgebung.

Auf Basis Ihrer bisherigen Beschreibung schlage ich folgenden Ablauf zur Verifikation vor. Bitte korrigieren Sie mich, falls diese Annahmen nicht zutreffen:

Vorgeschlagene Schritte zur Reproduktion:

1. Anmeldung im WordPress-Backend
2. Aktivierung des Plugins „WPML String Translation“
3. Auswahl eines variablen Produkts (z. B. Produkt-ID 1370 mit Variation 1372)
4. Prüfung des aktuellen Werts von `stock_quantity` (z. B. 100)
5. Senden des folgenden REST API Requests:

   PUT /wp-json/wc/v3/products/1370/variations/1372
   Body: { "stock_quantity": 200 }

6. Beobachtung der REST-Response:
– Erwartetes Verhalten: Rückgabe von stock_quantity = 200
– Tatsächliches Verhalten: Rückgabe des vorherigen Werts (z. B. 100)
7. Deaktivierung von „WPML String Translation“
8. Wiederholung des gleichen REST API Requests
9. Beobachtung: Die API gibt nun den korrekten Wert (z. B. 200) zurück

Könnten Sie bitte bestätigen, ob diese Schritte den Fehler korrekt abbilden, oder uns über Abweichungen informieren?

Zusätzlich wäre ich Ihnen dankbar, wenn Sie – sofern möglich – Screenshots der folgenden Punkte zur Verfügung stellen könnten:

– des gesendeten REST-Requests
– der jeweiligen REST-Responses
– der Produkt-/Variationsansicht im Backend (Lagerbestand)

Die Zugangsdaten zur Staging-Umgebung können Sie mir gerne in einer separaten privaten Nachricht senden.

Unser 2nd-Level-Team hat den Fall geprüft und konnte das Verhalten auf einer eigenen WCML-Installation nicht nachstellen. Sie haben festgestellt, dass der Datenbankwert korrekt aktualisiert wird und dass eine GET-Abfrage direkt nach dem PUT den richtigen Wert zurückgibt. Das Problem betrifft also nur die erste PUT-Antwort, die veraltete Daten liefert.

Der wesentliche Unterschied zwischen Ihrer Umgebung und unserer Testumgebung scheint der Server-Schutzlayer sowie eventuell aktives Caching zu sein.

Um die Ursache einzugrenzen, benötigen wir bitte folgende Prüfungen:

1. Den Server-Schutzlayer kurzzeitig deaktivieren und den PUT-Request erneut testen.
2. Überprüfen, ob irgendeine Form von Caching aktiv ist (Server-Cache, Object-Cache, Proxy-Cache). Falls ja, bitte kurzzeitig deaktivieren und erneut testen.

Diese Schritte helfen uns festzustellen, ob die veraltete PUT-Antwort durch den Server-Schutz oder ein Cache-System verursacht wird und nicht durch WPML/WCML selbst.

Bitte teilen Sie uns die Ergebnisse dieser beiden Tests mit.

An dieser Stelle ist das von Ihnen geschilderte Verhalten klar – die REST-API liefert einen veralteten Lagerbestand zurück, wenn WPML String Translation aktiviert ist. Die weiteren von Ihnen genannten Symptome (Amazon-Warnungen, fehlerhafte HTTP-Antworten und das Risiko einer Kontosperrung) deuten jedoch darauf hin, dass möglicherweise ein größeres Problem vorliegt, für das uns derzeit noch nicht alle technischen Details vorliegen.

Um die Situation richtig beurteilen und weitere Amazon-bezogene Probleme vermeiden zu können, benötigen wir genauere Informationen zu den erzeugten Fehlermeldungen.

Könnten Sie uns bitte die genauen Fehlermeldungen oder Log-Einträge zur Verfügung stellen, die Billbee oder Amazon ausgeben? Konkret benötigen wir:

* Die vollständige HTTP-Antwort, die Billbee als fehlerhaft markiert
* Jegliche Fehlerprotokolle oder Warnungen von Billbee/Amazon im Zusammenhang mit diesen Anfragen
* Die genaue API-Anfrage und die entsprechende Antwort, die die Warnungen auslöst

Derzeit kennen wir nur das Problem der veralteten Bestandsangabe in der API-Antwort, aber die Amazon-Warnungen könnten durch etwas anderes verursacht werden, das gleichzeitig passiert. Mit den vollständigen Fehlerdaten können wir feststellen, ob:

* das Problem mit WPML String Translation direkt für die Amazon-Warnungen verantwortlich ist, oder
* ob ein separates, davon unabhängiges Problem vorliegt, das ebenfalls untersucht werden muss

Könnten Sie bitte prüfen, ob das Problem weiterhin auftritt, wenn String Translation aktiv ist, aber WooCommerce Multilingual (WCML) deaktiviert ist? Das würde uns helfen, die Ursache einzugrenzen.

Hallo,

Danke für das Testen. Ich stimme mich mit unseren Entwicklern ab und melde mich, sobald ich neue Informationen habe.

Bei der Analyse ist uns ein wesentlicher Unterschied zwischen Ihrer Staging-Umgebung und unserer lokalen Testumgebung aufgefallen.

Wenn `prepare_object_for_response` in
`woocommerce/includes/rest-api/Controllers/Version3/class-wc-rest-product-variations-controller.php` aufgerufen wird, enthält `$response` den korrekten Lagerbestand, während das zugrunde liegende `$object` noch den vorherigen Bestand enthält.

Geht man im Ablauf weiter zurück, sieht man, dass der `_stock`-Wert zuvor korrekt in
`woocommerce/includes/data-stores/class-wc-product-data-store-cpt.php` über `update_or_delete_post_meta()` aktualisiert wird. Ein direkt anschließender `get_post_meta()`-Aufruf liefert an dieser Stelle bereits den neuen Wert. Dieses unterschiedliche Verhalten tritt in unserer lokalen Testumgebung nicht auf.

Da das Problem offenbar umgebungsspezifisch ist, ist das Debugging ausschließlich auf der Staging-Seite sehr zeitaufwendig und eingeschränkt.

Um das Problem effizient weiter untersuchen zu können, wäre es möglich, dass Sie uns eine Kopie der Seite zur Verfügung stellen, damit wir den Fehler lokal reproduzieren können?

Eine der folgenden Optionen wäre ausreichend:

* Ein Datenbank-Dump (SQL) und die Seitendateien, idealerweise ohne das Verzeichnis `/uploads`
oder
* Ein mit Duplicator ([versteckter Link)) erstelltes Paket, ebenfalls nach Möglichkeit ohne `/uploads`

Damit könnten wir die Ursache deutlich schneller identifizieren. Bitte geben Sie uns Bescheid, was für Sie am einfachsten ist.