Woo-poly-integration: Problèmes avec les produits variables

J'ai le même problème, si je copie à partir des langues principales, je n'affiche que des produits simples, sans possibilité de copier des variantes. Comment puis-je resoudre ceci?

Bonjour,

Avez-vous essayé d'installer le plugin "jQuery Migrate Helper" ?

Pouvez-vous s'il vous plaît utiliser le code du référentiel, télécharger zip directement à partir du code de téléchargement et installer, je pense que cela pourrait être résolu, je testerai beaucoup cela la semaine prochaine, mais tous les commentaires sont les bienvenus.

Pouvez-vous s'il vous plaît utiliser le code du référentiel, télécharger zip directement à partir du code de téléchargement et installer, je pense que cela pourrait être résolu, je testerai beaucoup cela la semaine prochaine, mais tous les commentaires sont les bienvenus.

Après avoir téléchargé zip et installé depuis GitHub, j'ai 2 problèmes :
1) Si je copie un produit de la langue principale dans la secondaire, cela crée de nombreuses variantes (exemple si j'ai un produit avec 2 couleurs, la deuxième langue crée 10 variantes de la couleur)
2) Après la commande d'un client, le produit devient en rupture de stock même s'il reste des stocks.

1. If I copy a product from the primary language into the secondary it creates many variations, (example if I have a product with 2 colors, the second language creates 10 variations from the color)

J'ai le même problème avec la version GitHub du plugin

Il semble que le dernier PR #518 ait foiré quelque chose lié aux produits variables.

Ok, j'ai lu le sujet, maintenant le problème est une faute d'orthographe dans un attribut meta. Pouvons-nous résoudre avec une requête de mise à jour et corriger le nom dans src/Hyyan/WPI/Plugin.php ?
@mrleemon j'ai vu que vous étiez un collaborateur de ce projet, si vous me donnez des directives sur cette erreur, je peux essayer une solution et la mettre à la disposition de la communauté.

Désolé, je n'ai commis que quelques corrections pour les fautes de frappe il y a longtemps. Ma connaissance du fonctionnement interne de ce plugin est proche de zéro.
Je ne sais pas ce qu'il faut faire pour corriger ce bug de variations.

Pour le moment, je pense que le seul à savoir comment fonctionne ce plugin est @Jon007

J'ai vu que #518 incluait cette correction de faute de frappe que j'avais déjà rejetée sur #450 car cela risquerait de casser des sites existants, mais @hyyan l' a accepté...

Je suis revenu au #518 pour l'instant. Et je regarderai plus en profondeur plus tard

Merci!

Peut-être que le plugin devrait utiliser le filtre officiel Polylang pll_copy_taxonomies pour synchroniser les taxonomies WooCommerce (product_type, product_visibility et autres) au lieu de la méthode personnalisée actuelle, qui semble vulnérable aux versions constantes de WooCommerce. Le plugin utilise déjà le filtre Polylang pll_copy_post_metas pour copier la méta du produit, il semble donc raisonnable d'utiliser pll_copy_taxonomies pour synchroniser les taxonomies des produits.

Avec ce filtre, on peut spécifier les taxonomies que l'on veut synchroniser ou copier et Polylang se charge de la synchronisation/copie desdites taxonomies et de leurs termes associés lorsque l'on crée une nouvelle traduction.

Juste une idée.

J'ai regardé cela, mais tout cela devient dangereusement obsolète, car le woocommerce se déplace davantage vers sa propre API et ses propres tables, vous ne pouvez pas compter sur le traitement des produits comme une publication et l'utilisation d'API génériques basées sur la publication. Au mieux, il y aura des bugs avec le mécanisme de mise en cache de woocommerce.

Oui je sais. J'y pensais comme une solution temporaire en attendant les changements de l'API WC.
En attendant, je pense que nous pouvons résoudre la sélection incorrecte de "Produit simple" lorsque le produit est variable en changeant le code JS dans Meta.php en :

À partir de:

$code = sprintf(
    '// <![CDATA[ %1$s'
    . ' addLoadEvent(function () { %1$s'
    . '  jQuery("#product-type option")'
    . '     .removeAttr("selected");%1$s'
    . '  jQuery("#product-type option[value=\"%2$s\"]")'
    . '    .attr("selected", "selected");%1$s'
    . '})'
    . '// ]]>', PHP_EOL, $type[0]
);

À:

$code = sprintf(
    '// <![CDATA[ %1$s'
    . ' addLoadEvent(function () { %1$s'
    . '  jQuery("#product-type option")'
    . '     .prop("selected", false);%1$s'
    . '  jQuery("#product-type option[value=\"%2$s\"]")'
    . '     .prop("selected", true);%1$s'
    . '})'
    . '// ]]>', PHP_EOL, $type[0]
);

Apparemment, l'utilisation de attr() et removeAttr() pour sélectionner/désélectionner des options est déconseillée avec les modifications récentes de jQuery dans WP.

Depuis https://jquery.com/upgrade-guide/3.0/ :

Breaking change: .removeAttr() no longer sets properties to false

Prior to jQuery 3.0, using .removeAttr() on a boolean attribute such as checked, selected, or readonly would also set the corresponding named property to false. This behavior was required for ancient versions of Internet Explorer but is not correct for modern browsers because the attribute represents the initial value and the property represents the current (dynamic) value.

It is almost always a mistake to use .removeAttr( "checked" ) on a DOM element. The only time it might be useful is if the DOM is later going to be serialized back to an HTML string. In all other cases, .prop( "checked", false ) should be used instead.

De plus, actuellement, lorsque l'utilisateur clique sur le lien du produit en double WC, le type de produit n'est pas copié sur la réplique.

Je l'ai "réparé" en ajoutant ceci à la fonction unlinkOrginalProductTranslations() dans Duplicator.php :

$type = $product->get_type();
update_post_meta($duplicate->get_id(), '_translation_porduct_type', $type);

Je ne sais pas s'il y a quelque chose de mal à cela.

J'aimerais me débarrasser complètement de '_translation_porduct_type', cela ne devrait pas vraiment être nécessaire, c'est seulement là pour faire face à la bizarrerie de l'interface utilisateur, mais le plus simple pour l'instant est de le garder et de faire ce que vous suggérez

J'allais te poser la question à ce sujet. Pourquoi le type de produit traduit est-il stocké dans _translation_porduct_type ? Ne peut-il pas être récupéré directement à partir du produit d'origine en cas de besoin ?

Je pense que c'est compliqué parce que lors de la traduction de polylang essaie de vous donner les détails du produit traduit lorsque vous demandez l'ancien produit, au moins, le copier dans les métadonnées est plus facile

Je pense que pour se débarrasser de la méta _translation_porduct_type , le plugin devrait utiliser la fonction WC API WC_Product:save() pour stocker les traductions au lieu de s'appuyer sur une solution personnalisée utilisant la wp_insert_post action directement, mais cela signifie refactoriser une grande partie du code trouvé dans Meta.php et je ne sais pas par où commencer.

Salut. Avez-vous résolu ce problème ?

Salut, j'ai proposé des solutions aux problèmes des produits variables, y compris des explications sur le n° 430 - ce serait formidable si quelqu'un pouvait tester le dernier code et confirmer les problèmes qui subsistent - idéalement sur un nouveau problème de github propre, car il y en a eu beaucoup partiellement ou billets entièrement dupliqués et devenant difficiles à suivre.

Merci pour votre travail ! Je testerai le dernier code dès que j'en aurai l'occasion et je vous ferai savoir si des problèmes surviennent.

J'ai ouvert un problème après avoir testé votre dernier code :
https://github.com/hyyan/woo-poly-integration/issues/526

@hyyan @mrleemon J'ai vérifié quelques changements importants la semaine dernière et j'ai étiqueté 5.1

En particulier, j'ai supprimé le correctif de contournement de @mrleemon sur #408 en commentant l'appel meta.php à :
$this->syncSelectedproductType( $ID );

Auparavant, nous avions ce problème car la séquence de sauvegarde n'était pas correcte, au moins dans la version 5.0, c'était :

1. WordPress enregistre la publication
2. woopoly synchronise la publication (mais WooCommerce n'est pas encore enregistré, donc le type de produit n'est pas enregistré et synchronisé correctement)
3. WooCommerce enregistre le produit
4. [pour les produits variables, WooCommerce enregistre les variations et woopoly les synchronise]
5. Lors de l'affichage de la traduction du produit, la solution de contournement réinitialise le formulaire pour afficher le type de produit dans le _translation_porduct_type afin que lors de l'enregistrement de la traduction, il soit correct.

Les révisions du code récupèrent désormais les crochets juste après la sauvegarde de WooCommerce et ont été ajustées pour fonctionner sur l'édition rapide (# 549) et l'édition en bloc également, de sorte que les solutions de contournement du type de produit ne sont plus nécessaires.

Bien sûr, ce n'est pas la fin - tout devrait être revu pour n'utiliser que l'API woo et éviter l'API wp - mais devrait supprimer certains des comportements étranges.

Super! Cette solution de contournement était vraiment horrible.
Alors, la méta _translation_porduct_type mal orthographiée n'est-elle plus nécessaire non plus ?
Je vais tester cette version mise à jour dès que j'aurai une minute.

Merci!

J'ai laissé la méta affectation _translation_porduct_type mal orthographiée pour le moment, mais elle n'est pas utilisée. Si cette version se passe bien, une version ultérieure pourrait supprimer ce code et d'autres codes redondants

J'ai testé cette nouvelle version et j'ai trouvé un problème :

1. J'ai un site en trois langues (espagnol, anglais et français). L'espagnol est celui par défaut. L'option de synchronisation "Type de produit" dans woopoly est cochée.
2. J'ajoute un nouveau produit en espagnol
3. Je sélectionne "Produit groupé" (ou tout type de produit autre que "Produit simple") et enregistre.
4. La liste déroulante du type de produit affiche le type de produit sélectionné.
5. Je clique sur n'importe quel lien "+" dans la métabox "Langues" pour ajouter une traduction.
6. La liste déroulante du type de produit dans la nouvelle traduction est désactivée (l'option de synchronisation « Type de produit » est cochée) mais elle affiche « Produit simple » au lieu du type de produit sélectionné dans le produit de langue par défaut.

Ok oui je vais regarder.
Changer les types de produits (et toute autre propriété) sur les produits existants devrait être bien.

@mrleemon s'est enregistré : sur les nouvelles traductions nécessaires pour conserver le crochet wordpress car le crochet woo n'est pas encore déclenché

D'accord merci!
Je le testerai plus tard quand j'aurai un moment et reviendrai vers vous dès que possible.

J'ai testé cette nouvelle version et mon problème avec les nouvelles traductions est résolu.
Merci!