Gelöst Probleme mit Kategorien beim anbinden eines WooCommerce-Shop

[j_d]

Heute war dann mal der Tag, an dem wir unsere Produkte von unserem WooCommerce- Shop in die JTL-Wawi importieren wollten. Und nicht nur, dass diese Wawi kein Unicode kann (und wahrscheinlich auch in näherer Zeit nicht unterstützen wird, weil Windows ihren Unicode-Support lobotomiert hat), und nicht nur, dass unsere Kategorienamen HTML-kodiert in der Datenbank gespeichert werden (ein SQL-Server ist keine HTML-Seite, und den Ampersand sollten die auch in ISO-8859-1 *gerade noch so unterstützen können*) - nein, jetzt werden auch noch nach den ersten sieben Kategorien Fehlermeldungen generiert.

Abgleich-Protokoll:
Bitte beachten Sie, dass JTL-Wawi federführend ist!
Im Shop-Backend vorgenommene Änderungen können nicht mehr automatisiert abgeglichen werden und führen somit zu Datenverlust.
Prüfe Endpointkonfiguration.
Abgleich gestartet für '<Withheld>'.
Onlineshop-Abgleich beendet für '<Withheld>'.


Fehler:
Kategorien-Empfangen-Fehler: Bitte beachten Sie, dass zur Fehler-Diagnose ebenfalls die Log-Datei des Servers und das Abgleich-Log der JTL-Wawi notwendig sind!

Fehler beim Kategorien-Abgleich: Der Shop sendet dauerhaft gleiche Daten. Um eine Endlosschleife zu verhindern, wird der Abgleich abgebrochen.

   bei jtlCore.ControllerClasses.Connector.Abgleich.Funktionen.ConnectorPuller.Pull[TEntity](Int64 quantity)
   bei jtlCore.ControllerClasses.Connector.Abgleich.EntityAbgleicher.ConnectorPullTask`1.Run()
   bei JTL.Connector.Business.SyncRunner.Run()



Warnungen:
Abgleich darf nicht weiterlaufen.Abgleich darf nicht weiterlaufen.Abgleich darf nicht weiterlaufen.

Ja, ich kapier's, der Abgleich darf nicht weiterlaufen. Nur den Grund dafür weiß ich nicht.

Nur das " Log-Datei des Servers" stellt ein Problem da, denn - Wunder über Wunder - auch in dieser Kategorie (Pun intended) gibt's Probleme. Ich sitze hier an meiner root-Konsole, mit "developer_logging" auf true gesetzt, aber deswegen erstellt der mir doch keine Logs auf dem Server. An den Zugriffsrechten, wie auch hier mal in die Kristallkugel geraten wurde, liegt*s kaum, den ganzen verdammten Ordner habe ich dem Nutzer des Verzeichnisses und die Zugriffsrechte 777 (User, Group und Others dürfen alles).

Und weil das Server-Log nicht erstellt wird, kann ich auch nix von da verpacken und hochladen.

Die Version des Shops ist 3.4.4, Connector ist für WooCommerce 3.0, die Version des Connectors ist Version 1.6.3, Version der Wawi ist 1.3.20.0. Wenn die Server-Log so dringend gebraucht werden, muss man mir erstmal sagen, wie ich an die Logs kommen soll.
Zugriff auf die Wawi-Datenbank ist vorhanden über das SQL Server Management Studio, da kann ich auch sehen, dass die ersten sieben Kategorien importiert werden und er dann die Latschen aufstellt.

Ich bin kein Händler, sondern Anwendungsentwickler (nicht in PHP, sondern eher Low-Level). Zurückhalten mit Fachchinesisch braucht man nicht.

 

[Jan Weskamp]

Hallo,

Die Kategorien werden so aus dem Shop gezogen, wie diese dort hinterlegt sind. Der JTL-Connector modifiziert Deine Daten nicht.

<<< Category.statistic: {"result":{"available":7,"controllerName":"category"},"error":null,"jtlrpc":"2.0","id":"7c51362880014ae6bb9e2d94c163491d"}

An diesem Aufruf sieht man, das es nur 7 verfügbare Kategorien gibt, die auch übertragen wurden.

Nur das " Log-Datei des Servers" stellt ein Problem da, denn - Wunder über Wunder - auch in dieser Kategorie (Pun intended) gibt's Probleme. Ich sitze hier an meiner root-Konsole, mit "developer_logging" auf true gesetzt, aber deswegen erstellt der mir doch keine Logs auf dem Server. An den Zugriffsrechten, wie auch hier mal in die Kristallkugel geraten wurde, liegt*s kaum, den ganzen verdammten Ordner habe ich dem Nutzer des Verzeichnisses und die Zugriffsrechte 777 (User, Group und Others dürfen alles).

Und weil das Server-Log nicht erstellt wird, kann ich auch nix von da verpacken und hochladen.

Du schaust auch in den "logs" Ordner im "woo-jtl-connector" dir?

Die Vermutung, warum der Abgleich abbricht ist, dass beim ziehen des ersten Artikels ein Fehler mit dem Lagerbestand auftritt.

mfg

Jan W.

 

[j_d]

Die Kategorien werden so aus dem Shop gezogen, wie diese dort hinterlegt sind.

Wenn das stimmt sollte, dann hat's bei WooCommerce den Knall noch nicht gehört. Denn soweit ich das beurteilen kann (anhand des HTML-Quelltextes), kodieren die unsere Umlaute eben *nicht* als HTML-Entities. Ich hoffe doch, die Wawi ist so gescheit, UTF-8-Daten in ISO-8859-1 umzuwandeln, wenn sie schon nicht HTML-Entities umkodiert? Denn soweit ich das sehe, kodiert WC ein "ü" nicht als ein "&uuml;", sondern als UTF-8 \xc3\xa4.

An diesem Aufruf sieht man, das es nur 7 verfügbare Kategorien gibt, die auch übertragen wurden.

Das halte ich für ein Gerücht. Im Interface werden mir 43 Kategorien angezeigt, und über die WooCommerce-API (https://<unsere Shop-Domain>/wp-json/wc/v2/products/categories?per_page=50) werden die mir auch angezeigt. Woher sich der Connector die 7 Kategorien holt, kann ich dir nicht sagen, aber was ich sagen kann, ist dass *deutlich* mehr Kategorien drin sind als was das Log behauptet - sowohl im Webinterface als auch über die API. Warum auch immer es das behauptet.

Du schaust auch in den "logs" Ordner im "woo-jtl-connector" dir?

Fast. Bei der Installation des Connectors mussten wir ein Plugin installieren, und darum hat der Admin sich gekümmert. In den Plugin-Einstellungen des Shops ist die URL auf "https://<unsere Shop-Domain>/index.php/jtlconnector/" festgestellt, ändern kann ich das auch nicht - zumindest nicht über das Web-Interface. Für den 3.0-Connector habe ich dann einfach "woo-jtl-connector" in "jtlconnector" umbenannt, weil ich mir dachte, dass die index.php die Anfrage an einen Dateisystempfad weiterleiten muss.

Ich habe jetzt mal "jtlconnector" in "woo-jtl-connector" umbenannt, nur um zu gucken, was passiert. Nix dramatisches. "https://<unsere Shop-Domain>/index.php/jtlconnector/" ist immer noch erreichbar, schmeißt immer noch mit JSON um sich, und die Wawi meint auch: "HTTP-Verbindung zum Webshop OK!". Aber uffer Konsole:

$ pwd
/home/<unser Nutzer>/public_html/woo-jtl-connector/logs
$ ls -lah
insgesamt 4,0K
drwxrwxrwx  2 <unser Nutzer> <unsere Gruppe>    6 14. Dez 08:58 .
drwxr-xr-x 11 <unser Nutzer> <unsere Gruppe> 4,0K 14. Dez 08:58 ..
$

So, I dunno what to tell ya.

Die Vermutung, warum der Abgleich abbricht ist, dass beim ziehen des ersten Artikels ein Fehler mit dem Lagerbestand auftritt.

Möglich. Wir hatten bereits in der Vergangenheit Probleme mit bestimmten Produkten - aber was für ein Fehler soll das sein, und warum gibt mir die Wawi nicht mehr Informationen als beinahe schon frenetisch auszugeben, dass der Abgleich nicht fortgesetzt werden darf?

EDIT:

Vergisst das mit den Logs. Ich habe gerade mal

# find / -name "woo-jtl-connector"

auf der Konsole ausgeführt. Stellt sich heraus, dass das Plugin, welches der Admin installiert hat, einen *eigenen* Ordner "woo-jtl-conncetor" mit sich bringt, der sich in "~/public_html/wp-content/plugins/" versteckt hat. Hatte mich schon gewundert, warum der Dienst nach der Umbenennung noch tat.

Kann ich die Logs per PM senden? Allein schon beim durchgreppen kann ich sehen, dass da sensitive Informationen drin sind.

 

[Jan Weskamp]

Vergisst das mit den Logs. Ich habe gerade mal

# find / -name "woo-jtl-connector"

auf der Konsole ausgeführt. Stellt sich heraus, dass das Plugin, welches der Admin installiert hat, einen *eigenen* Ordner "woo-jtl-conncetor" mit sich bringt, der sich in "~/public_html/wp-content/plugins/" versteckt hat. Hatte mich schon gewundert, warum der Dienst nach der Umbenennung noch tat.

Kann ich die Logs per PM senden? Allein schon beim durchgreppen kann ich sehen, dass da sensitive Informationen drin sind.

Ich bitte darum diese privat zu senden =)

 

[Jan Weskamp]

j_d

Problem war das Plugin WP - Rocket

 

[j_d]

Nein, Problem war *nicht* das WP-Rocket-Plugin. Dieses Plugin hat lediglich eine Warnung hervorgerufen, weil es temporäre Verzeichnisse für's Caching erstellt. Das Plugin versucht dabei erst, das unterste Verzeichnis durchzugehen, und wenn dies nicht klappt (weil ein oder mehrere Oberverzeichnisse nicht existieren), dann versucht der Code, das nächsthöhere Verzeichnis zu erstellen - bis es klappt. Danach wird die Verzeichnisliste umgekehrt durchgegangen und alle Unterverzeichnisse ordentlich erstellt.

Das Problem war, dass wir anscheinend mal eine Kategorie mit Unterkategorien im System hatten, die dann entfernt wurde. Diese Kategorien behielten ihre Elternkategorienummern bei, sodass der Connector versuchte, diese Elternkategorienummer ebenfalls aufzulösen. Da die Kategorie aber nicht mehr existierte, konnte er das nicht.

Wie es hierzu kommen konnte, wage ich nur zu vermuten, aber es könnte sein, dass die Kategorie zu einem Zeitpunkt entfernt worden ist, an dem der Server ausgelastet war. Das Löschen von Kategorien und Unterkategorien ist nicht atomisch, d.h. dass zwischen diesen Zeitpunken ("Kategorie löschen" und "Unterkategorie löschen") das Script wegen Timeouts beendet wurde. Da Wordpress als Datenbankengine MyISAM verwendet und somit keine Fremdschlüssel unterstützt, gibt es somit auch keine Kaskadenfunktion, die das Löschen der Unterkategorien atomisiert hätte.

Um derartige Kategorien zu finden, benötigt man direkten Zugriff auf die Datenbank. In der MySQL-Kommandozeile kann man sie dann mit diesem Befehl anzeigen lassen:

SELECT tt.parent, tt.description, cl.*, tt.count
FROM `wp_terms` t
LEFT JOIN `wp_term_taxonomy` tt ON t.term_id = tt.term_id
LEFT JOIN `wp_jtl_connector_category_level` cl ON tt.term_id = cl.category_id
LEFT JOIN `wp_jtl_connector_link_category` l ON t.term_id = l.endpoint_id
WHERE tt.taxonomy = 'product_cat' AND l.host_id IS NULL
ORDER BY cl.level ASC, tt.parent ASC, cl.sort ASC;

In unserem Fall war es die Elternkategorienummer "699", die nicht mehr existierte, die die Unterkategorien aber immer noch drinhatten:

+--------+-------------+-------------+-------+------+-------+
| parent | description | category_id | level | sort | count |
+--------+-------------+-------------+-------+------+-------+
|    699 |             |        NULL |  NULL | NULL |     6 |
|    699 |             |        NULL |  NULL | NULL |     1 |
|    699 |             |        NULL |  NULL | NULL |     0 |
|    699 |             |        NULL |  NULL | NULL |     0 |
|    699 |             |        NULL |  NULL | NULL |     9 |
|    699 |             |        NULL |  NULL | NULL |     0 |
|    699 |             |        NULL |  NULL | NULL |     0 |
+--------+-------------+-------------+-------+------+-------+

Wir haben diese Kategorien dann einfach zu Topkategorien umgewandelt:

UPDATE wp_term_taxonomy SET parent = 0 WHERE parent=699;

und danach den Abgleich nochmal gestartet. Das hat das Problem mit dem Kategorieimport gelößt - jetzt sind wir erstmal dabei, zu prüfen, ob der Rest des Imports auch ordentlich abgelaufen ist.