Woo-poly-integration: Problèmes liés à WooCommerce 3.6

Bonjour. Voici un bug lié à ce que vous mentionnez ci-dessus.

Pouvez-vous reproduire ce problème sur le thème Wordpress par défaut (par exemple, Storefront) ?
OUI

Pouvez-vous reproduire ce problème lorsque tous les autres plugins sont désactivés, à l'exception de WooCommerce, Polylang et Hyyan WooCommerce Polylang Integration ?
OUI

Quelles versions de produit et quels paramètres utilisez-vous lorsque ce problème se produit ?
PHP : 7.3.1
WordPress : 5.1.1
WooCommerce : 3.6.1
Polylang : 2.5.3
Intégration de Hyyan WooCommerce Polylang : 1.3.0
Navigateur : Chrome, Firefox

Étapes pour reproduire
Définir Polylang avec au moins 2 langues
Créer un produit variable dans la langue par défaut
Créer une traduction du produit

Ce que j'attendais
Le produit traduit est également variable.

Ce qui s'est passé à la place
Lorsque je clique pour ajouter une traduction du produit, le type de produit de cette traduction est défini sur SIMPLE.
Le type de produit n'est pas synchronisé.

Le type de produit est un problème confirmé 3.6.x - Je peux également le reproduire et est également signalé sur https://wordpress.org/support/topic/variable-products-change-to-simple-in-translated-version/

Le problème de type de produit est probablement dû à la mise en cache ajoutée au type de produit https://github.com/woocommerce/woocommerce/pull/22612/commits/57ccde66437ade8e91d12890245d9d4c5e5e1892
cela signifie que lorsque le type de produit est mis à jour par woopoly, le cache n'est pas invalidé donc il apparaît alors comme Simple.

Il s'agit d'un problème différent mais similaire à celui des nouvelles tables de recherche de données produit : toutes les mises à jour doivent désormais passer par l'API woocommerce pour garantir la mise à jour des tables de mise en cache et de recherche.
Actuellement, le plugin étend les capacités de Polylang pour copier les méta et taxonomies post, avec la compréhension minimale nécessaire des méta et taxonomies qui nécessitent une copie ou une traduction.
Désormais, les éléments WooCommerce prédéfinis doivent être gérés via l'API WooCommerce elle-même.

Je n'ai pas beaucoup d'expérience avec le code WooCommerce, mais existe-t-il des informations sur la mise en cache WooCommerce quelque part afin que nous puissions essayer de trouver un moyen de résoudre ces problèmes ? D'après vos découvertes, la fonction copyTerms() dans Meta.php doit-elle être mise à jour ?

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

Idéalement, toutes les mises à jour doivent utiliser les objets Product woocommerce plutôt que les objets Post wordpress, pour garantir que la mise en cache de niveau woocommerce et les tables intermédiaires (et futures tables Product) sont toujours cohérentes. Cela peut ne pas être aussi difficile qu'il y paraît.

Alternativement, il devrait également être possible de mettre à jour tel quel et de forcer woocommerce à remettre en cache et à recalculer les objets pertinents, mais la mise à jour via l'API serait plus à l'épreuve du temps, et nous pourrions tous faire avec moins de maintenance et moins de problèmes des futures versions de woocommerce .

Les informations sur les changements sont toutes là dans le premier lien de ce fil et les notes de version des versions ponctuelles depuis lors. Le lien woocommerce github ci-dessus que j'ai trouvé en parcourant les notes de version qui sont liées aux correctifs github.

Dans les très anciennes versions du plugin, il y avait un appel à $this->syncSelectedproductType($ID); à la fin de la fonction syncProductsMeta() à Meta.php . Si je rajoute cela, les nouvelles traductions de produits variables sélectionnent l'option correcte dans la liste déroulante des types de produits.

@mrleemon oui qui résout le problème de type de produit de variation, bravo !

C'est un peu un travail de piratage - il ne corrige pas réellement le problème sous-jacent, mais utilise à la place un peu de javascript pour synchroniser la nouvelle forme de produit traduite avec un peu de méta woopoly, de sorte qu'il fonctionne correctement lorsque le produit est enregistré.

La synchronisation générale du produit semble également être correcte (sous réserve de tests supplémentaires), seule la nouvelle table wc_product_meta_lookup n'est pas mise à jour et je pense que cela n'affecte actuellement que le tri.

Nous devons donc copier directement les propriétés du produit à l'aide des fonctions WooCommerce CRUD au lieu de compter sur le filtre pll_copy_post_metas comme maintenant, n'est-ce pas ?

Eh bien, la méta elle-même semble fonctionner, il y a juste un risque qu'elle soit mise en cache, par exemple voici la mise en cache woocommerce ajoutée pour les attributs de variation :

    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 );

D'une manière ou d'une autre, je pense que le cache est vidé et que cela fonctionne, cela peut être dû à la chance plutôt qu'à la conception.
Néanmoins, la table wc_product_meta_lookup doit être mise à jour et cela pourrait être fait séparément en mettant à jour les champs spécifiques via la classe de produits, mais serait plus efficace si toutes les mises à jour étaient effectuées via la classe de produits _relevant_ pour éviter les appels répétés à la base de données. Il doit probablement s'agir de la classe de produits _relevant_, car différents types de produits ont une gestion différente.

Je ne sais pas si la fonction WC suivante peut être utile pour copier les données produit lors de la création de nouvelles traductions :

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

Il utilise un filtre woocommerce_duplicate_product_exclude_meta pour exclure les champs méta de la copie et un crochet woocommerce_product_duplicate_before_save pour modifier davantage l'objet produit avant sa création.

@mrleemon merci .. nous ne

En attendant, j'ai une autre solution que je vais vérifier.

@mrleemon J'ai accepté votre suggestion pour $this->syncSelectedproductType($ID); et ajouté une fonction pour s'assurer que les caches des produits de traduction sont effacés et que les tables de recherche sont mises à jour.

Cela résout tous les problèmes 3.6 signalés jusqu'à présent.
Mais ce n'est pas une revue de code complète...

@mrleemon merci .. nous ne

Oui je sais. Mais, probablement à long terme, il sera nécessaire d'envisager de dupliquer les produits à l'aide des fonctions principales de WC, étant donné que l'équipe WC prévoit de déplacer toutes les métadonnées de produit hors de la table wp_postmeta à l'avenir.

La nouvelle publication de produit est créée par Polylang en tant que publication vierge avec des données de taxonomie pour la langue et les traductions liées et les méta sélectionnées et ce plugin étend cela de manière générique pour gérer les options de méta et les termes et taxonomies supplémentaires.

Il est en fait préférable que les termes et les taxonomies soient copiés de manière générique car ils fonctionnent alors (généralement) (ou peuvent fonctionner avec des filtres) sur n'importe quel type de produit (y compris les types de produits que nous ne connaissons pas) et tout plugin qui ajoute des métadonnées ou des taxonomies au produit (que les objets woocommerce standard ne connaissent pas).

L'objectif à long terme de WooCommerce semblait être de déplacer les données produit de la table des publications elle-même, mais cela casse chaque plugin d'extension, c'est pourquoi ils ont proposé cette table de recherche pour atténuer les limitations de performances pour les principaux champs de données utilisés pour le tri.

Salut! Ce bug a-t-il été corrigé ? Les dernières entrées du journal des modifications mentionnent que la compatibilité avec WC 3.6 a été corrigée, mais ce problème est toujours ouvert. Quel est le statut? De plus, est-il possible de mettre à jour le plugin distribué par WP (https://wordpress.org/plugins/woo-poly-integration/) ?

BTW, merci beaucoup pour la maintenance de ce plugin à toutes les personnes impliquées !

Il s'agit d'un sujet général pour les problèmes de woo3.6 ne faisant pas référence à un seul problème. Les problèmes spécifiques signalés jusqu'à présent ont été corrigés à partir de la première version 3.4 de ce plugin sur github. La source est maintenant 3.4.3 que je publierai sur github après avoir revérifié quelques points supplémentaires.

Il est toujours préférable d'avoir plus de commentaires des premiers utilisateurs avant une version complète sur WordPress : il y a tellement de paramètres et de scénarios d'utilisation différents qu'un test complet est en fait impossible, surtout lorsque d'autres plugins sont envisagés - j'ai déjà dû annuler une modification après l'avoir acceptée car un changement de compatibilité au profit d'un plugin a rompu la compatibilité pour d'autres plugins (nommez votre prix par rapport aux sélecteurs de devises).

Hier, WooCommerce a rejeté l'une de mes demandes d'extraction liées à WooCommerce 3.6+ après l'avoir précédemment acceptée - en considération, ils ne veulent pas autoriser d'autres plugins à resynchroniser la table de recherche de produit - donc à long terme, tout plugin wordpress qui traite le produit comme un publier à l'aide de l'API WordPress aura des problèmes. Dans le même temps, le seul moyen fiable jusqu'à présent de copier les données de produit pour n'importe quel produit (y compris les types de produits personnalisés qui ont des données que nous ne connaissons pas) est de copier toutes les métadonnées et les données de taxonomie qu'il y a (selon les paramètres et filtrables de cours).
La solution de contournement ajoutée dans la version 3.4 fonctionnera toujours, mais je la réexaminerai avant toute version.

Je rencontre toujours ce bogue sur Hyyan WooCommerce Polylang Integration Version 1.4.3 sur wp5.2.2

Le chargement de l'éditeur pour un produit variable supprime les données de produit variables, même la réenregistrement des données de produit variables est inefficace.

La désactivation et la réactivation de Hyyan n'ont pas modifié ce comportement
il y a eu récemment une mise à jour de Polylang
https://wordpress.org/plugins/polylang/#developers
2.6.2 (2019-07-16)
Pro : Correction de la lenteur de l'administration au cas où le serveur de mise à jour des traductions ne serait pas accessible
Avantages : la valeur de correction n'est pas correctement traduite pour les champs de clone ACF dans le répéteur
Correction des traductions de chaînes mélangées lors de l'enregistrement via la compatibilité WPML. #381

Salut, @Oclair, veuillez noter que le correctif fonctionne toujours même avec les dernières mises à jour de Polylang et WooCommerce, donc si vous rencontrez un problème, veuillez le signaler en tant que problème github séparé avec tous les détails.

Veuillez noter que la solution de contournement inclut Javascript, donc en plus de la vérification des erreurs côté serveur, il vaut la peine d'inspecter avec les outils de développement Chrome et de vérifier la console Javascript pour toute erreur.

Il est possible qu'un autre problème ou un autre plugin affecte cela d'une manière ou d'une autre.

Hé merci pour la réponse et la solution, pas une mise en garde triviale permettant javascript !
Peut-être que le plugin pourrait informer l'administrateur si ce javascript rencontre un problème ? parce que la plupart des gens ne vérifient pas les variables du produit s'ils n'ont besoin que de mettre à jour du texte...

Merci encore, bonne soirée !

Salut, @Oclair, veuillez noter que le correctif fonctionne toujours même avec les dernières mises à jour de Polylang et WooCommerce, donc si vous rencontrez un problème, veuillez le signaler en tant que problème github séparé avec tous les détails.

Veuillez noter que la solution de contournement inclut Javascript, donc en plus de la vérification des erreurs côté serveur, il vaut la peine d'inspecter avec les outils de développement Chrome et de vérifier la console Javascript pour toute erreur.

Il est possible qu'un autre problème ou un autre plugin affecte cela d'une manière ou d'une autre.

Peut-être que le plugin pourrait informer l'administrateur si ce javascript rencontre un problème ?
cela peut être une situation difficile à détecter et à traiter : si le problème de javascript est qu'il ne s'exécute jamais, il ne pourra pas émettre d'alerte.

En fait, j'ai supprimé cette solution de contournement il y a quelques versions car je ne l'aime pas et j'ai trouvé que ce n'était pas nécessaire. Malheureusement, les modifications apportées à WooCommerce l'ont à nouveau rendu nécessaire et je n'ai pas pu trouver de meilleure alternative.