WooCommerce ↔ JTL-Wawi: Wenn die Synchronisation silent versagt

Ein Kunde aus Heidelberg hat uns vor zwei Wochen angerufen. Drei überverkaufte Bestellungen an einem Tag, zwei davon Geschenke für einen Geburtstag, der in drei Tagen war. In JTL-Wawi standen die Artikel auf 0, im WooCommerce-Shop noch auf 5. Die Sync lief, der Connector zeigte grün, niemand hatte eine Fehlermeldung gesehen. Genau das ist die unangenehme Variante: Sync funktioniert nicht, sagt aber niemandem Bescheid.

In den letzten Jahren haben wir diese Situation für Händler aus Mannheim, Ludwigshafen, Karlsruhe und deutschlandweit durchgespielt. Die Ursachen wiederholen sich. Drei davon decken nach unserer Erfahrung den Großteil der Fälle ab, und du kannst sie selbst prüfen, bevor du jemanden ranholst.

Die drei ersten Checks

Wenn die Bestände driften, prüfst du in dieser Reihenfolge:

1. Artikelnummer-Zuordnung. Gibt es Artikel im Shop, deren SKU sich nicht 1:1 in JTL findet? Führende Nullen, Leerzeichen oder Sonderzeichen sind die häufigsten Verdächtigen.
2. Letzter Sync-Lauf. Lief er sauber durch oder wurde er nach 60 Sekunden vom Server abgebrochen?
3. Drittplugins im Shop. Gibt es Caching, Stock-Manager oder Variation-Plugins, die nach dem Sync nochmal in den Bestand schreiben?

Diese drei Checks lösen den Großteil. Wenn sie alle sauber sind, geht es tiefer rein.

Inhalt

• Was beim Sync technisch passiert
• Symptom-Diagnose-Tabelle
• Ursache 1: Artikelnummern-Mismatch
• Ursache 2: Sync-Timeout bei großen Stapeln
• Ursache 3: Drittplugins überschreiben den Bestand
• Manuelle Reparatur
• Monitoring, damit es nicht wieder passiert
• Wann externe Hilfe sich lohnt
• FAQ

Was beim Sync technisch passiert

Der JTL-Connector für WooCommerce ist ein WordPress-Plugin, das die WooCommerce REST-API aufruft. JTL-Wawi pusht über den Connector Artikeldaten in den Shop, der Shop meldet Bestellungen zurück. Beide Richtungen laufen über HTTPS, beide Richtungen können kippen.

Drei Stellen brechen typischerweise:

• Auf dem Wawi-Rechner, wenn der Connector-Service selbst hängt oder die Wawi gerade einen großen Datenexport blockiert.
• Auf dem Webserver, wenn PHP-Limits oder MySQL-Locks den Schreibvorgang abbrechen.
• Im Shop selbst, wenn ein anderes Plugin oder ein Cache zwischen API-Schreibvorgang und sichtbarem Frontend-Bestand sitzt.

Wenn Wawi und Shop unterschiedliche Werte zeigen, ist die erste Frage immer: war der letzte Sync erfolgreich, ja oder nein? Die Antwort steht im Connector-Log. Im aktuellen JTL-Connector für WooCommerce liegt das Log innerhalb des Plugin-Verzeichnisses unter wp-content/plugins/woo-jtl-connector/var/log/. Den Status erreichst du im WordPress-Backend über WooCommerce → Einstellungen → Tab „JTL-Connector".

Symptom-Diagnose-Tabelle

Wenn du dein Symptom nicht in der Tabelle findest, geht es in die drei Hauptursachen.

Ursache 1: Artikelnummern-Mismatch

Das ist die häufigste Einzelursache, die wir sehen. JTL-Wawi und WooCommerce identifizieren einen Artikel über die Artikelnummer beziehungsweise SKU. Wenn die Strings nicht exakt gleich sind, schreibt der Connector entweder einen neuen Artikel an, oder er ignoriert den Eintrag still. Letzteres ist das eigentliche Problem, weil es keine Fehlermeldung gibt.

Typische Stolpersteine, in der Reihenfolge der Häufigkeit:

• Führende Nullen, die Excel beim CSV-Import wegfrisst. Aus „00123" wird „123", die Wawi behält die Null, der Shop nicht.
• Leerzeichen am Ende einer SKU. Beim manuellen Anlegen rutscht ein Leerzeichen rein, optisch unsichtbar, technisch ein anderer String.
• Bindestrich versus Geviertstrich. „ABC-123" und „ABC–123" sind aus Datenbanksicht zwei verschiedene Artikel.
• Stille Umlaut- oder Encoding-Konvertierung beim Export-Import zwischen Wawi und Shop, vor allem wenn UTF-8 und Latin-1 sich kreuzen.
• Variations-SKU gegen Parent-SKU. Wenn der Connector eine Variation schreiben will, der Shop aber denkt, das sei eine Parent-SKU, läuft der Schreibvorgang ins Leere.

Wie du das prüfst: SKU-Listen aus beiden Systemen exportieren und gegenüberstellen. In Wawi geht das mit der JTL-Ameise als CSV-Export, in WooCommerce über Produkte → Alle Produkte → Exportieren. Beide CSVs in Excel oder Google Sheets gegeneinanderlegen, mit =VERGLEICH() oder XLOOKUP die Differenzen rausziehen.

Die Reparatur ist meist trivial, sobald die Liste steht: betroffene SKUs in Wawi korrigieren oder im Shop angleichen, dann einen erneuten Sync auslösen. Wichtig ist die Richtung. Wenn Wawi der Master ist (Standardfall), korrigierst du nicht im Shop, weil der nächste Sync den korrigierten Wert wieder überschreibt.

Ursache 2: Sync-Timeout bei großen Stapeln

Bei Sortimenten ab etwa 500 aktiven Artikeln laufen die Sync-Stapel gerne in PHP- oder MySQL-Limits. Symptome: Sync startet sauber, läuft 60 oder 90 Sekunden, hängt dann fest und bricht stillschweigend ab. Im Connector-Log steht oft nur „pull cancelled" oder gar nichts.

Die typischen Limit-Werte, die du bei deinem Hoster prüfen solltest:

• max_execution_time in PHP. PHP-Default ist 30 Sekunden, viele Shared-Hoster lassen 60 stehen. Für den Connector empfehlen wir mindestens 300 Sekunden.
• memory_limit in PHP. PHP-Default ist 128 MB, WordPress hebt das beim Bootstrap auf 40 MB hoch (WP_MEMORY_LIMIT), für den Admin-Bereich auf 256 MB. Bei großen Sortimenten mit vielen Bildern werden 512 MB empfehlenswert.
• max_input_vars in PHP. Default 1.000. Bei vielen Variationen mit vielen Attributen reicht das nicht, dann auf 5.000 setzen.
• innodb_lock_wait_timeout in MySQL. Default 50 Sekunden. Wenn ein anderer Prozess gerade in wp_postmeta schreibt (zum Beispiel ein paralleler Cron) und der Connector wartet zu lange, bricht der Schreibvorgang ab.

Wo du das findest: bei den meisten Hostern in der php.ini oder unter Plesk/cPanel im PHP-Konfigurationsmenü. Bei Managed-Hostern wie Raidboxes oder Mittwald reicht meist ein Support-Ticket, dann werden die Limits angehoben.

Eine zweite Stellschraube ist die Stapelgröße auf Connector-Seite. Im Connector-Tab unter den Einstellungen kannst du die Anzahl der Artikel pro Pull-Vorgang absenken. Wenn der Sync chronisch in Timeouts läuft, halbiere den Wert und beobachte, ob der Lauf jetzt durchkommt. Der Sync braucht dann länger, geht aber sauber durch.

Ursache 3: Drittplugins überschreiben den Bestand

Diese Ursache ist die heimtückischste, weil sie nur sporadisch zuschlägt. Der Sync schreibt einen Bestand in die Datenbank, ein anderes Plugin schreibt direkt danach einen anderen Wert rein. Im WooCommerce-Frontend siehst du den falschen, in der Wawi steht der richtige.

Vier Plugin-Familien finden wir bei Kunden regelmäßig als Übeltäter.

Caching-Plugins wie WP Rocket oder LiteSpeed Cache cachen Produkt-Templates und zeigen den alten Bestand auch dann noch, wenn die Datenbank längst aktualisiert ist. Lösung: Cache nach jedem Sync gezielt purgen, idealerweise per Webhook.

Stock-Management-Add-ons berechnen den Bestand mit eigener Logik neu, zum Beispiel nach Reservierungen im Warenkorb. Sinnvolle Funktion, kollidiert aber mit dem Connector, sobald beide in dasselbe Feld schreiben dürfen.

Variation-Plugins wie WooCommerce Bulk Variations oder Variation Swatches verändern manchmal die Variation-Struktur nach dem Sync und löschen dabei Bestandswerte mit.

Multi-Vendor-Plugins schreiben den Bestand pro Vendor zurück. Wenn dein Shop nicht nur eigene Ware verkauft, überschreibt das den Master-Bestand aus Wawi.

Zur Eingrenzung: das verdächtige Plugin temporär deaktivieren, Sync neu auslösen, prüfen ob die Bestände jetzt sauber durchkommen. Wenn ja, das Plugin entweder ersetzen oder den Connector so konfigurieren, dass er den Bestand nicht überschreibt, je nachdem, welche Logik gewinnen soll.

Manuelle Reparatur

Wenn die Bestände komplett auseinandergelaufen sind und du nicht jeden Artikel einzeln nachpflegen willst, gibt es zwei harte Wege. Vorher zwingend ein Datenbank-Backup. Beide Wege schreiben in produktive Tabellen, ein Schreibfehler ohne Backup ist eine sehr lange Nacht.

Weg 1: Ameise CSV-Re-Import

Du exportierst aus Wawi alle Artikel mit Bestand und Preis und importierst die CSV in WooCommerce über das Standard-Import-Tool. Vorteil: keine SQL-Berührung. Nachteil: dauert bei großen Sortimenten lang und überschreibt nur, was im CSV steht. Was im Shop zusätzlich existiert, bleibt unangetastet.

Weg 2: direkter SQL-Update

Wenn nur die Bestandsmenge falsch ist und der Rest stimmt, kannst du in wp_postmeta direkt schreiben. Beispiel:

UPDATE wp_postmeta pm
JOIN wp_posts p ON p.ID = pm.post_id
SET pm.meta_value = '0'
WHERE pm.meta_key = '_stock'
AND p.post_status = 'publish'
AND p.post_type = 'product';

Das setzt erstmal alle Bestände auf 0. Danach läuft ein vollständiger Sync aus Wawi und befüllt sauber neu. Methode ist brutal, aber bei totalem Datenchaos manchmal der schnellste Weg zurück. Nicht ohne Backup, nicht im laufenden Betrieb, idealerweise nachts mit einem Maintenance-Mode-Plugin, das den Shop für Kunden zumacht.

Eine Warnung, falls du den SQL-Weg gehst: WooCommerce pflegt seit einigen Versionen zusätzlich die Lookup-Tabelle wp_wc_product_meta_lookup für schnellere Suchen. Wenn du nur wp_postmeta updatest, bleibt der Lookup-Wert kurzzeitig veraltet, bis das nächste Schreib-Event den Sync triggert. Ein Aufruf von wc_update_product_lookup_tables() per WP-CLI nach dem SQL-Update gleicht das ab.

Monitoring, damit es nicht wieder passiert

Die meisten Shops, die wir betreuen, hatten das Sync-Problem schon mal vorher und einfach repariert, ohne Lerneffekt. Das ist die teure Variante. Drei Bausteine laufen unauffällig im Hintergrund und melden die Drift früh genug.

Ein Cron-Job, der einmal pro Stunde ein Sample von 20 Artikeln in beiden Systemen vergleicht. Bei einer Abweichung von mehr als 1 Stück geht ein Alert raus, per E-Mail oder Slack. Das ist ein 30-Zeilen-PHP-Skript, das jeder PHP-fähige Hoster ausführt und im laufenden Betrieb nichts kostet.

Plausibilitäts-Checks in der Ameise. Beim Export kannst du Regeln definieren, etwa „Bestand muss größer oder gleich 0 sein" oder „Preis muss größer 0 sein". Wenn ein Artikel die Regel verletzt, wird er nicht exportiert und du bekommst eine Warnmeldung. Das fängt Pflegefehler ab, bevor sie überhaupt im Shop ankommen.

Niedrigere Sync-Frequenz. Viele Setups syncen im 5-Minuten-Takt, weil Echtzeit angeblich immer besser ist. Ist sie nicht. Häufige Stapel kollidieren öfter mit Cache und API-Limits. Ein Sync alle 30 bis 60 Minuten reicht für die allermeisten Shops und reduziert silente Abbrüche deutlich.

Wann externe Hilfe sich lohnt

Kunden, die selbst diagnostizieren wollen, geben wir meist die Zwei-Stunden-Regel mit. Wenn du in zwei Stunden keinen Fortschritt siehst, also weder die Ursache eingegrenzt noch eine erste Reparatur erfolgreich, dann hol jemanden, der das täglich macht. Die Stunden, die du danach noch reinsteckst, kosten dich mehr als ein erfahrener Blick von außen. Falls du an genau diesem Punkt bist, kannst du dich direkt an uns wenden.

Hilfreich kann es vorher sein zu prüfen, ob auch andere Anbindungen wackeln. Buchhaltung, Versand, Zahlungsanbieter hängen oft an denselben Wawi-Mechanismen wie der Shop-Sync. Unser Überblick zu JTL-Wawi-Schnittstellen zeigt, wo diese Mechanismen ähnlich kippen können.

Wenn du ohnehin gerade prüfst, ob WooCommerce mittelfristig die richtige Plattform ist, lohnt vorher der Blick in unseren Vergleich JTL-Shop, Shopify oder WooCommerce: Welches System passt?. Bei einem Teil der chronischen Sync-Krisen, zu denen wir gerufen werden, ist die ehrliche Antwort am Ende: das System hätte besser zum JTL-eigenen Shop gewechselt, weil dort die Wawi-Anbindung nativ läuft.

FAQ

Warum kommt keine Fehlermeldung, wenn die Sync abbricht?

Der JTL-Connector loggt Fehler ins eigene Log innerhalb des Plugin-Verzeichnisses (wp-content/plugins/woo-jtl-connector/var/log/), schickt aber standardmäßig keine Benachrichtigung. Stille Abbrüche durch PHP-Timeouts werden zudem oft nur als „pull cancelled" eingetragen, ohne Stack-Trace. Aktive Benachrichtigung muss man selbst einrichten, etwa per Cron-Vergleich oder Hosting-Monitoring.

JTL-Connector vs. Drittanbieter-Plugin: was ist robuster?

Der offizielle JTL-Connector ist die Standardlösung und wird mit Wawi-Updates synchron gepflegt. Drittanbieter-Plugins haben manchmal Features, die der offizielle Connector nicht hat, hängen aber am Wartungstempo des Anbieters. Für Standardanforderungen empfehlen wir den offiziellen Connector, weil das Risiko bei Wawi-Updates kleiner ist.

Wie oft sollte ich syncen, Echtzeit oder stündlich?

Für Shops mit weniger als 100 Bestellungen pro Tag reicht stündlich oder alle 30 Minuten. Für Shops mit hoher Frequenz und knappen Beständen kann häufigerer Sync sinnvoll sein, dann aber kombiniert mit einem Reservierungs-Plugin, das Warenkorb-Bestände vorhält. Echtzeit-Sync alle 5 Minuten löst mehr Probleme als er behebt, vor allem auf Shared Hosting.

Lohnt der Wechsel zu JTL-Shop, wenn die WooCommerce-Sync ständig kippt?

Manchmal ja. JTL-Shop hat die Wawi-Anbindung nativ, ohne Connector-Schicht, und Bestandsdrift ist deutlich seltener. Der Wechsel kostet aber meist mehrere Tausend Euro und bringt eigene Themen mit, etwa Template-Migration und SEO-Schutz. Wir empfehlen den Wechsel nur, wenn die Sync-Probleme nach gründlicher Diagnose strukturell sind und nicht durch ein einzelnes Plugin verursacht werden.

Welche Daten gewinnen Konflikte, Wawi oder Shop?

Standard-Setup ist Wawi als Master, der Shop bekommt Werte überschrieben. Du kannst die Richtung im Connector pro Datenfeld umstellen, aber für Bestände und Preise ist Wawi-Master fast immer richtig, weil die Wawi den physischen Lagerbestand kennt und der Shop nicht. Eine Mischrichtung führt langfristig zu Drift, sobald irgendein Datenpfad bricht.

Pfade, Default-Werte und Tab-Bezeichnungen verifiziert gegen JTL-Connector for WooCommerce 2.4.1 (Stand Mai 2026), WooCommerce-Quellcode (is_existing_sku, wc_product_meta_lookup) und PHP/MySQL-Standardwerte. Bei abweichenden Connector-Versionen kann sich die Verzeichnisstruktur unterscheiden.