Woo-poly-integration: L'e-mail de commande n'inclut pas les informations de variation

Veuillez réessayer avec la dernière version, maintenant publiée sous le nom de Hyyan WooCommerce Polylang Integration 1.0.
La première série de modifications de wooCommerce 3.0 n'incluait pas un examen approfondi des variations.

Cela dit, je ne fais que le retester et dans mon installation de test simple :

• l'e-mail au propriétaire de la boutique comprend les détails de la variation
• l'e-mail au client n'inclut pas le détail de la variation

Si je désactive ensuite à la fois woo-poly-integration et polylang, j'obtiens le même résultat... c'est donc dans les modèles WooCommerce eux-mêmes.
donc si vous en avez besoin, vous pouvez ajuster le modèle ou soulever le problème auprès de WooCommerce.

Veuillez vérifier et confirmer ici.

J'ai fait une commande test et les informations de variation n'étaient dans aucun des e-mails.
Y a-t-il quelque chose que je puisse faire pour vous aider à déboguer le problème ?

Eh bien, si vous confirmez que les informations de variation ne sont pas dans l'e-mail lorsque Polylang et woo-poly sont désactivés, ce n'est pas un problème avec ce plugin...

J'ai désactivé woo-poly et maintenant je vois les informations de variation dans l'e-mail à l'administrateur.
par exemple "Navy Movie Stars Dog Bandana - 26 pouces" (où "26 pouces" est l'information de variation).

J'ai réactivé woo-poly et les informations de variation ont de nouveau disparu.

Information additionnelle:

• Le détail de la variation est toujours affiché à la caisse.
• Le détail de la variation n'est pas dans la page de commande reçue lorsque woo-poly est actif.
• Le détail de la variation n'est pas dans l'e-mail de l'administrateur lorsque woo-poly est actif.
• Le détail de la variation n'est pas dans l'e-mail du client lorsque woo-poly est actif (il est là lorsque woo-poly est inactif, différent de ce que vous avez remarqué).

était-ce dans la langue de base ou la langue seconde?

Langue de base.
Voulez-vous que je l'essaie dans la deuxième langue ? (le site n'a que 2 langues actives - anglais et allemand).

Bon, voici le problème :

Commande.php l. 118** fonction translateProductNameInOrdersDetails
essaie d'être intelligent et d'ajouter des liens sur chaque article de commande pour revenir aux détails du produit ainsi que [à défaut de] traduire le nom de la variante.

Vous pouvez le dire en ajoutant la première ligne de cette fonction :
return $name;

Vous obtiendrez le nom de la variante du produit sur les e-mails, etc., mais ce sera toujours dans la langue de base de la boutique.

À première vue, l'ajout des liens de produits semble une fonctionnalité intéressante et en effet, il semble extrêmement boiteux que les e - mails standard des clients WooCommerce
Et il y a probablement une raison pour laquelle wooCommerce ne le fait pas : le client peut conserver l'e-mail pendant des siècles comme reçu, mais le produit peut être modifié plus tard afin qu'il ne corresponde plus au lien. Cela semble mauvais si le client clique plus tard sur l'ancien e-mail de commande.
Je pourrais donc en faire une option...

J'ai aussi une raison pour le comportement apparemment incohérent:

• la fonctionnalité standard de wooCommerce utilise product->get_name() qui semble dériver de wp_posts.post_title
  Normalement, vous ne voyez pas le titre de la variation dans ce champ, il est donc difficile à suivre, mais les titres de variation réels peuvent dépendre des versions de l'intégration WooCommerce et WooCommerce Polylang qui ont été installées au moment de la création ou de l'enregistrement des variations.

D'un point de vue observationnel, j'ai les formats suivants dans un magasin construit au cours de la dernière année :

• [nom du produit] traduit mais aucune information de variation
• Variante n°[variation_id] de [nom du produit]
• [nom du produit] [nom de la variante] nom de la variante non traduit
• [nom du produit] [nom de la variante] nom de la variante traduit

Ainsi, la bonne solution peut avoir les éléments suivants :

• identifier le nom de variante correct et s'assurer qu'il est correctement défini lors de la sauvegarde/mise à jour du produit
• créer un script pour reconstruire les noms de variante de produit et le code corrects pour l'exécuter exactement une fois lors de la mise à jour du plugin
• la fonction translateProductNameInOrdersDetails pourra alors être supprimée, puisque le nom sera correct nativement...

Logiquement, enregistrer correctement le nom doit être mieux que d'essayer d'accrocher et de changer le nom partout où il peut être utilisé.

wooCommerce 3.0 a aussi du code pour cela :

class-wc-product-variation-data-store-cpt-php ll.73-83

        /**
         * If a variation title is not in sync with the parent e.g. saved prior to 3.0, or if the parent title has changed, detect here and update.
         */
        if ( version_compare( get_post_meta( $product->get_id(), '_product_version', true ), '3.0', '<' ) && ( $parent_title = get_post_field( 'post_title', $product->get_parent_id() ) ) && 0 !== strpos( $post_object->post_title, $parent_title ) ) {
            global $wpdb;

            $new_title = $this->generate_product_title( $product );
            $product->set_name( $new_title );
            $wpdb->update( $wpdb->posts, array( 'post_title' => $new_title ), array( 'ID' => $product->get_id() ) );
            clean_post_cache( $product->get_id() );
        }

ok, ça se complique, j'allais le signaler à wooCommerce, mais il y a un checkin associé il y a 5 jours et ajouté à la 3.0.8 : https://github.com/woocommerce/woocommerce/issues/15315
il serait donc judicieux de revoir cela.

Fondamentalement, wooCommerce 3.0.7 a toujours des problèmes avec la description de la variation dans le panier et donc dans les commandes.
Voici une séquence avec WooCommerce 3.0.7 brut après avoir désactivé l'intégration Polylang et Polylang WooCommerce .

1. Créez un attribut de produit, par exemple une couleur avec des termes noir et bleu
2. Créer un nouveau produit de variante avec des variantes pour le noir et le bleu
3. Changez le terme Blue en NewBlue
4. Voir le produit - il montre maintenant la variation "NewBlue"
5. Ajouter au panier, voir le panier
6. le panier affiche maintenant : Variations de test de synchronisation - Bleu
   couleur: NouveauBleu
7. Modifiez maintenant le produit, par exemple changez le titre….
   Le titre de la variante ne sera jamais entièrement réinitialisé et reste avec l'ancienne valeur de l'attribut, car le code WooCommerce ne recherche-remplace que l'ancien titre du produit, il ne reconstruit jamais complètement le titre.
   Quelle que soit la modification de l'attribut du produit, le titre n'est jamais réinitialisé :

mysql> select ID, post_title from wp_posts where ID>456;
+-----+---------------------------------------------+
| ID  | post_title                                  |
+-----+---------------------------------------------+
| 457 | Test Sync variations 2                      |
| 458 | Test Sync variations 2 - Blue               |
| 459 | Test Sync variations 2 - Black              |

(L'attribut Bleu est renommé mais la description pour Panier/Commande n'est jamais tout à fait mise à jour correctement)

Comment wooCommerce fait le lien :
À l'enregistrement :
class-wc-product-variable.php save() l.394 appels
$this->data_store->sync_variation_names( $this, $previous_name, $new_name );
class-wc-product-variable-data-store-cpt.php sync_variation_names() ll.304++
une chaîne remplace-t-elle dans les noms plutôt qu'un nouveau nom
donc ici une chaîne de variation traduite n'est pas prise, elle remplace simplement la partie titre

Sur le commentaire précédent, generate_product_title () est une fonction protégée d'une classe de données interne, ce qui n'est donc pas facilement accessible pour une substitution depuis l'extérieur de WooCommerce.

Ainsi, en rapport avec tout cela, voici comment fonctionne WooCommerce-Polylang : au niveau de la variation, WooCommerce-Polylang ajoute sa propre référence pour s'assurer que les détails de la variation sont normalement récupérés à partir de la copie en langue principale de la variation - voir le problème #168

Je pense appliquer un correctif temporaire en utilisant un filtre "woocommerce_product_variation_get_name".

Il existe une autre alternative curieuse mentionnée, pour désactiver les attributs du produit dans le titre, ce qui signifie qu'ils devraient plutôt être imprimés après le titre.
add_filter( 'woocommerce_product_variation_title_include_attributes', '__return_false' );
Cependant cela ne fonctionne pas pour moi.

Ok, C'EST FIXE DANS WOOCOMMERCE !!!

testé avec le dernier code https://github.com/woocommerce/woocommerce "Version 3.1.0-beta"
et devrait être publié en 3.0.8.

et avec la fonction woo-poly translateProductNameInOrdersDetails() désactivée,
alors le correctif woocommerce s'appliquera

Aussi si je voulais le
add_filter( 'woocommerce_product_variation_title_include_attributes', '__return_false' );
fonctionne dans le WooCommerce mis à jour

Peut-être WooCommerce 3.1 plutôt que 3.0.8, en regardant le blog woocommerce : https://woocommerce.wordpress.com/
2 semaines à partir du 31 mai mettraient la date de sortie au 14 juin peut-être.

notez qu'il semble que woocommerce/woocommerce # 15315 ait été supprimé de 3.0.8 à la dernière minute, mais est toujours prévu pour 3.1 avec un examen plus approfondi.
Ainsi, les détails des variations dans le panier/les commandes peuvent continuer à être étranges jusque-là.

Le résultat typique peut être par exemple :

Nom du produit espagnol - _Terme de variation anglais_
Nom de l'attribut - _Terme de variante espagnol_