Woo-poly-integration: WooCommerce 3.6-Probleme

Erstellt am 3. Apr. 2019  ·  19Kommentare  ·  Quelle: hyyan/woo-poly-integration

Öffnen dieses Tickets für potenzielle WooCommerce 3.6-Kompatibilitätsprobleme.

Siehe den Beitrag für Verbesserungen in 3.6:
https://woocommerce.wordpress.com/2019/04/01/performance-improvements-in-3-6/

Die umfangreichen Änderungen werden wahrscheinlich einige subtile Fehler einführen.
Zum Beispiel verwendet die Produkt-Meta-Synchronisierung die standardmäßige Polylang-Post-Meta-Synchronisierung, sie verwendet nicht die Produkt-API, sodass aktualisierte Meta für Sekundärsprachen nicht in die neuen woo3.6-Produktnachschlagetabellen kopiert werden, was zu subtilen Fehlern bei der Produktsortierung und den Berichten führen kann wenn die primäre Sprache der Site nicht verwendet wird.
Ebenso werden zwischengespeicherte Produktdaten für Sekundärsprachen möglicherweise nicht geleert, wenn das Produkt in der Primärsprache aktualisiert wird.

Hilfreichster Kommentar

Dies ist ein allgemeines Thema für woo3.6-Probleme, das sich nicht auf ein einzelnes Problem bezieht. Spezifische Probleme, die bisher gemeldet wurden, wurden ab der ersten Version 3.4 dieses Plugins auf github behoben. Die Quelle ist jetzt 3.4.3, die ich auf github veröffentlichen werde, nachdem ich noch ein paar weitere Punkte überprüft habe.

Es ist immer vorzuziehen, mehr Feedback von Early Adopters vor einer vollständigen Veröffentlichung von WordPress zu erhalten: Es gibt so viele verschiedene Einstellungen und Nutzungsszenarien, dass ein vollständiges Testen eigentlich unmöglich ist, insbesondere wenn andere Plugins in Betracht gezogen werden - ich musste bereits eine Änderung rückgängig machen, nachdem ich sie akzeptiert hatte weil eine Kompatibilitätsänderung zugunsten eines Plugins die Kompatibilität für andere Plugins beeinträchtigt hat (benennen Sie Ihren Preis gegenüber Währungsumschaltern).

Gestern hat WooCommerce einen meiner zugehörigen Pull-Requests an WooCommerce 3.6+ abgelehnt, nachdem ich ihn zuvor akzeptiert hatte - aus Gründen der Überlegung, dass sie anderen Plugins nicht erlauben möchten, die Produkt-Lookup-Tabelle neu zu synchronisieren - also langfristig jedes WordPress-Plugin, das das Produkt als behandelt Bei Beiträgen mit der WordPress-API treten Probleme auf. Gleichzeitig besteht die einzige zuverlässige Möglichkeit zum Kopieren von Produktdaten für jedes Produkt (einschließlich benutzerdefinierter Produkttypen, deren Daten wir nicht kennen) darin, alle vorhandenen Meta- und Taxonomiedaten zu kopieren (je nach Einstellungen und filterbar von Kurs).
Die in 3.4 hinzugefügte Problemumgehung funktioniert weiterhin, aber ich werde sie mir vor jeder Veröffentlichung noch einmal ansehen.

Alle 19 Kommentare

Hallo. Hier ist ein Fehler im Zusammenhang mit dem, was Sie oben erwähnt haben.

Können Sie dieses Problem im Standard-Wordpress-Theme (zB Storefront) reproduzieren?
JAWOHL

Können Sie dieses Problem reproduzieren, wenn alle anderen Plugins außer WooCommerce, Polylang und Hyyan WooCommerce Polylang Integration deaktiviert sind?
JAWOHL

Welche Produktversionen und Einstellungen verwenden Sie, wenn dieses Problem auftritt?
PHP: 7.3.1
WordPress: 5.1.1
WooCommerce: 3.6.1
Mehrsprachig: 2.5.3
Hyyan WooCommerce Polylang-Integration: 1.3.0
Browser: Chrome, Firefox

Schritte zum Reproduzieren
Legen Sie Polylang mit mindestens 2 Sprachen fest
Variables Produkt in der Standardsprache erstellen
Erstellen Sie eine Übersetzung des Produkts

Was ich erwartet habe
Das übersetzte Produkt ist ebenfalls variabel.

Was ist stattdessen passiert
Wenn ich klicke, um eine Übersetzung des Produkts hinzuzufügen, wird der Produkttyp dieser Übersetzung auf EINFACH gesetzt.
Produkttyp ist nicht synchronisiert.

Product Type is Confirmed 3.6.x Problem - Ich kann dies auch reproduzieren und wird auch auf https://wordpress.org/support/topic/variable-products-change-to-simple-in-translated-version/ gemeldet.

Das Problem mit dem Produkttyp wird wahrscheinlich durch das Caching verursacht, das dem Produkttyp hinzugefügt wurde https://github.com/woocommerce/woocommerce/pull/22612/commits/57ccde66437ade8e91d12890245d9d4c5e5e1892
Dies bedeutet, dass bei einer Aktualisierung des Produkttyps durch Woopoly der Cache nicht ungültig gemacht wird, sodass er dann als Einfach angezeigt wird.

Dies ist ein anderes, aber ähnliches Problem wie bei den neuen Produktdaten-Lookup-Tabellen: Im Wesentlichen müssen jetzt alle Updates über die Woocommerce-API gehen, um sicherzustellen, dass die Caching- und Lookup-Tabellen aktualisiert werden.
Derzeit erweitert das Plugin die Polylang-Fähigkeiten zum Kopieren von Post-Meta und Taxonomien, mit dem minimal notwendigen Verständnis dafür, welche Metas und Taxonomien kopiert oder übersetzt werden müssen.
Nun sollten die vordefinierten WooCommerce-Items über die WooCommerce-API selbst abgewickelt werden.

Ich habe nicht viel Erfahrung im Umgang mit WooCommerce-Code, aber gibt es irgendwo Informationen zum WooCommerce-Caching, damit wir versuchen können, diese Probleme zu beheben? Muss nach Ihren Erkenntnissen die Funktion copyTerms() in Meta.php aktualisiert werden?

https://github.com/hyyan/woo-poly-integration/blob/1d83ef23e96f35c2bb008b5fa37e5157bfc388e4/src/Hyyan/WPI/Product/Meta.php#L341

Idealerweise sollten alle Updates die Woocommerce-Produktobjekte anstelle der WordPress-Post-Objekte verwenden, um sicherzustellen, dass das Caching auf Woocommerce-Ebene und Zwischentabellen (und zukünftige Produkttabellen) immer konsistent sind. Dies ist möglicherweise nicht so schwierig, wie es sich anhört.

Alternativ sollte es auch möglich sein, unverändert zu aktualisieren und Woocommerce zu zwingen, die relevanten Objekte neu zu cachen und neu zu berechnen, aber die Aktualisierung über die API wäre zukunftssicherer, und wir könnten alle mit weniger Wartung und weniger Problemen aus zukünftigen Woocommerce-Versionen auskommen .

Die Informationen zu den Änderungen sind alle im ersten Link in diesem Thread und in den Versionshinweisen der Punktversionen seitdem enthalten. Den obigen Woocommerce-Github-Link habe ich gefunden, indem ich die Versionshinweise durchgesehen habe, die mit Github-Fixes verknüpft sind.

In wirklich alten Versionen des Plugins gab es einen Aufruf von $this->syncSelectedproductType($ID); am Ende der Funktion syncProductsMeta() bei Meta.php . Wenn ich dies erneut hinzufüge, wählen Sie bei neuen Übersetzungen von variablen Produkten die richtige Option in der Dropdown-Liste für den Produkttyp aus.

@mrleemon ja, das behebt das Problem mit dem Variationsprodukttyp, gut gemacht!

Es ist ein bisschen Hackarbeit - es behebt nicht wirklich das zugrunde liegende Problem, sondern verwendet ein bisschen Javascript, um das übersetzte neue Produktformular mit ein bisschen Woopoly-Meta zu synchronisieren, damit es beim Speichern des Produkts gut funktioniert.

Die allgemeine Produktsynchronisation scheint auch in Ordnung zu sein (vorbehaltlich weiterer Tests), nur die neue Tabelle wc_product_meta_lookup wird nicht aktualisiert und ich glaube, das betrifft derzeit nur die Sortierung.

Wir müssen also Produkteigenschaften direkt mit den WooCommerce CRUD-Funktionen kopieren, anstatt uns wie jetzt auf den pll_copy_post_metas Filter zu verlassen, oder?

Nun, das Meta selbst scheint zu funktionieren, es besteht nur die Gefahr, dass es zwischengespeichert werden könnte, zum Beispiel hier ist das Woocommerce-Caching, das für Variationsattribute hinzugefügt wurde:

    public function read_variation_attributes( &$product ) {
        global $wpdb;

        $variation_attributes = array();
        $attributes           = $product->get_attributes();
        $child_ids            = $product->get_children();
        $cache_key            = WC_Cache_Helper::get_cache_prefix( 'product_' . $product->get_id() ) . 'product_variation_attributes_' . $product->get_id();
        $cache_group          = 'products';
        $cached_data          = wp_cache_get( $cache_key, $cache_group );

Irgendwie denke ich, dass der Cache geleert wird und das funktioniert, das ist vielleicht eher Glück als Design.
Dennoch muss die Tabelle wc_product_meta_lookup aktualisiert werden, und dies könnte separat erfolgen, indem die spezifischen Felder über die Produktklasse aktualisiert werden, aber es wäre effizienter, wenn alle Aktualisierungen über die Produktklasse _relevant_ durchgeführt würden, um wiederholte Datenbankaufrufe zu vermeiden. Es muss jedoch wahrscheinlich die _relevante_ Produktklasse sein, da verschiedene Produkttypen unterschiedliche Handhabung haben.

Ich weiß nicht, ob die folgende WC-Funktion sinnvoll sein kann, um Produktdaten beim Anlegen neuer Übersetzungen zu kopieren:

https://docs.woocommerce.com/wc-apidocs/source-class-WC_Admin_Duplicate_Product.html#134

Es verwendet einen woocommerce_duplicate_product_exclude_meta Filter, um Metafelder vom Kopieren auszuschließen, und einen woocommerce_product_duplicate_before_save Hook, um das Produktobjekt weiter zu modifizieren, bevor es erstellt wird.

@mrleemon danke .. wir duplizieren das Produkt nicht so, aber vielleicht könnten wir .....?

In der Zwischenzeit habe ich eine andere Lösung, die ich überprüfen werde.

@mrleemon Ich habe Ihren Vorschlag für $this->syncSelectedproductType($ID) akzeptiert; und eine Funktion hinzugefügt, um sicherzustellen, dass die Übersetzungsprodukt-Caches gelöscht und die Nachschlagetabellen aktualisiert werden.

Dies behebt alle bisher gemeldeten 3.6-Probleme.
Aber es ist kein vollständiger Code-Review ...

@mrleemon danke .. wir duplizieren das Produkt nicht so, aber vielleicht könnten wir .....?

Ja, ich weiß. Langfristig wird es jedoch wahrscheinlich notwendig sein, die Duplizierung von Produkten mit WC-Kernfunktionen in Betracht zu ziehen, da das WC-Team plant, in Zukunft alle Produktmetadaten aus der Tabelle wp_postmeta zu verschieben.

Der neue Produktbeitrag wird von Polylang als leerer Beitrag mit Taxonomiedaten für Sprache und verknüpfte Übersetzungen und ausgewählte Meta erstellt und dieses Plugin erweitert dies auf generische Weise, um Meta-Optionen und zusätzliche Begriffe und Taxonomien zu behandeln.

Es ist eigentlich besser, dass die Begriffe und Taxonomien generisch kopiert werden, weil sie dann (im Allgemeinen) für jeden Produkttyp (einschließlich Produkttypen, die wir nicht kennen) und jedes Plugin funktionieren (oder mit Filtern zum Laufen gebracht werden können) fügt dem Produkt Metadaten oder Taxonomien hinzu (von denen die Standard-Woocommerce-Objekte nichts wissen).

Das langfristige Ziel von WooCommerce schien es zu sein, die Produktdaten aus der Posts-Tabelle selbst zu verschieben, aber das macht jedes Erweiterungs-Plugin kaputt. Deshalb haben sie diese Nachschlagetabelle entwickelt, um die Leistungsbeschränkungen für die Hauptdatenfelder zu verringern, die zum Sortieren verwendet werden.

Hi! Wurde dieser Fehler behoben? Die letzten Changelog-Einträge erwähnen, dass die Kompatibilität mit WC 3.6 behoben wurde, aber dieses Problem ist noch offen. Wie ist der Status? Ist es auch möglich, das von WP (https://wordpress.org/plugins/woo-poly-integration/) vertriebene Plugin aktualisieren zu lassen?

Übrigens, vielen Dank für die Pflege dieses Plugins an alle Beteiligten!

Dies ist ein allgemeines Thema für woo3.6-Probleme, das sich nicht auf ein einzelnes Problem bezieht. Spezifische Probleme, die bisher gemeldet wurden, wurden ab der ersten Version 3.4 dieses Plugins auf github behoben. Die Quelle ist jetzt 3.4.3, die ich auf github veröffentlichen werde, nachdem ich noch ein paar weitere Punkte überprüft habe.

Es ist immer vorzuziehen, mehr Feedback von Early Adopters vor einer vollständigen Veröffentlichung von WordPress zu erhalten: Es gibt so viele verschiedene Einstellungen und Nutzungsszenarien, dass ein vollständiges Testen eigentlich unmöglich ist, insbesondere wenn andere Plugins in Betracht gezogen werden - ich musste bereits eine Änderung rückgängig machen, nachdem ich sie akzeptiert hatte weil eine Kompatibilitätsänderung zugunsten eines Plugins die Kompatibilität für andere Plugins beeinträchtigt hat (benennen Sie Ihren Preis gegenüber Währungsumschaltern).

Gestern hat WooCommerce einen meiner zugehörigen Pull-Requests an WooCommerce 3.6+ abgelehnt, nachdem ich ihn zuvor akzeptiert hatte - aus Gründen der Überlegung, dass sie anderen Plugins nicht erlauben möchten, die Produkt-Lookup-Tabelle neu zu synchronisieren - also langfristig jedes WordPress-Plugin, das das Produkt als behandelt Bei Beiträgen mit der WordPress-API treten Probleme auf. Gleichzeitig besteht die einzige zuverlässige Möglichkeit zum Kopieren von Produktdaten für jedes Produkt (einschließlich benutzerdefinierter Produkttypen, deren Daten wir nicht kennen) darin, alle vorhandenen Meta- und Taxonomiedaten zu kopieren (je nach Einstellungen und filterbar von Kurs).
Die in 3.4 hinzugefügte Problemumgehung funktioniert weiterhin, aber ich werde sie mir vor jeder Veröffentlichung noch einmal ansehen.

Ich habe immer noch diesen Fehler bei Hyyan WooCommerce Polylang Integration Version 1.4.3 auf wp5.2.2

Das Laden des Editors für ein variables Produkt entfernt die variablen Produktdaten, selbst ein erneutes Speichern der variablen Produktdaten ist wirkungslos.

Das Deaktivieren und erneute Aktivieren von Hyyan hat dieses Verhalten nicht geändert
es gab vor kurzem ein Update für Polylang
https://wordpress.org/plugins/polylang/#developers
2.6.2 (2019-07-16)
Pro: Behebung eines langsamen Admins, falls der Übersetzungs-Update-Server nicht erreichbar ist
Pro: Korrekturwert für ACF-Klonfelder im Repeater nicht korrekt übersetzt
Beheben Sie gemischte Zeichenfolgenübersetzungen, wenn sie über die WPML-Kompatibilität registriert wurden. #381

Hallo @Oclair Bitte beachten Sie, dass der Fix auch mit den neuesten Polylang- und WooCommerce-Updates noch funktioniert. Wenn Sie also ein Problem haben, melden Sie es bitte als separates Github-Problem mit vollständigen Details.

Bitte beachten Sie, dass die Problemumgehung Javascript enthält. Daher lohnt es sich zusätzlich zur Überprüfung auf serverseitige Fehler, die Chrome-Entwicklertools zu überprüfen und die Javascript-Konsole auf Fehler zu überprüfen.

Es ist möglich, dass ein anderes Problem oder ein anderes Plugin dies in irgendeiner Weise beeinflusst.

Hey, danke für die Antwort und Lösung, keine triviale Einschränkung, die Javascript aktiviert!
Vielleicht benachrichtigt das Plugin den Administrator, wenn dieses Javascript ein Problem hat? weil die meisten Leute Produktvariablen nicht überprüfen, wenn sie nur etwas Text aktualisieren müssen ....

Nochmals vielen Dank, lass es dir gut gehen!

Hallo @Oclair Bitte beachten Sie, dass der Fix auch mit den neuesten Polylang- und WooCommerce-Updates noch funktioniert. Wenn Sie also ein Problem haben, melden Sie es bitte als separates Github-Problem mit vollständigen Details.

Bitte beachten Sie, dass die Problemumgehung Javascript enthält. Daher lohnt es sich zusätzlich zur Überprüfung auf serverseitige Fehler, die Chrome-Entwicklertools zu überprüfen und die Javascript-Konsole auf Fehler zu überprüfen.

Es ist möglich, dass ein anderes Problem oder ein anderes Plugin dies in irgendeiner Weise beeinflusst.

Vielleicht benachrichtigt das Plugin den Administrator, wenn dieses Javascript ein Problem hat?
Es kann eine schwierige Situation sein, sie zu erkennen und darauf zu reagieren: Wenn das Javascript-Problem darin besteht, dass es nie ausgeführt wird, kann es keine Warnung ausgeben.

Ich habe diese Problemumgehung vor einigen Versionen tatsächlich entfernt, da sie mir nicht gefällt und ich fand sie nicht notwendig. Leider machten WooCommerce-Änderungen es wieder notwendig und ich konnte keine bessere Alternative finden..

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Tii picture Tii  ·  27Kommentare

hyyan picture hyyan  ·  13Kommentare

theblackhole picture theblackhole  ·  4Kommentare

vasildervenski picture vasildervenski  ·  19Kommentare

Magneticdud picture Magneticdud  ·  5Kommentare