Woo-poly-integration: Die englische Bestell-E-Mail enthält keine Variationsinformationen

Bitte versuchen Sie es erneut mit der neuesten Version, die jetzt als Hyyan WooCommerce Polylang Integration 1.0 veröffentlicht wurde.
Der erste Satz von WooCommerce 3.0-Änderungen beinhaltete keine gründliche Überprüfung der Variationen.

Trotzdem teste ich es nur noch einmal und in meiner einfachen Testinstallation:

• die E-Mail an den Shop-Inhaber enthält Details zur Variation
• die E-Mail an den Kunden enthält keine Variationsdetails

Wenn ich dann sowohl Woo-Poly-Integration als auch Polylang ausschalte, erhalte ich das gleiche Ergebnis ... also dies ist in den WooCommerce-Vorlagen selbst.
Bei Bedarf können Sie die Vorlage anpassen oder das Problem an WooCommerce wenden.

Bitte überprüfen und bestätigen Sie hier.

Ich habe eine Testbestellung gemacht und die Variationsinformationen waren in keiner der E-Mails enthalten.
Gibt es etwas, was ich tun kann, um Ihnen bei der Fehlersuche zu helfen?

Nun, wenn Sie bestätigen, dass die Variationsinformationen nicht in der E-Mail enthalten sind, wenn Polylang und woo-poly deaktiviert sind, ist dies kein Problem mit diesem Plugin ...

Ich habe Woo-Poly deaktiviert und sehe jetzt die Variationsinformationen in der E-Mail an den Admin.
zB "Navy Movie Stars Dog Bandana – 26inch" (wobei "26inch" die Variationsinformation ist).

Ich habe Woo-Poly wieder aktiviert und die Variationsinformationen sind wieder weg.

Weitere Informationen:

• Variationsdetails werden immer in der Kasse angezeigt.
• Variationsdetails befinden sich nicht auf der Bestelleingangsseite, wenn Woo-Poly aktiv ist.
• Variationsdetails sind nicht in der Admin-E-Mail enthalten, wenn Woo-Poly aktiv ist.
• Variationsdetails sind nicht in der Kunden-E-Mail enthalten, wenn Woo-Poly aktiv ist (sie ist vorhanden, wenn Woo-Poly inaktiv ist, anders als Sie es bemerkt haben).

war das in der grundsprache oder in der zweiten sprache?

Basissprache.
Soll ich es in der zweiten Sprache versuchen? (die Seite hat nur 2 aktive Sprachen - Englisch und Deutsch).

Okay, hier ist das Problem:

Bestell.php l. 118** Funktion translateProductNameInOrdersDetails
versucht clever zu sein und fügt jedem Bestellartikel Links hinzu, um zu den Produktdetails zurückzukehren und den Variationsnamen [fehlgeschlagen] zu übersetzen.

Sie können dies erkennen, indem Sie die erste Zeile dieser Funktion hinzufügen:
return $name;

Sie erhalten den Namen der Produktvariante in den E-Mails usw., jedoch immer in der Sprache des Shops.

Auf den ersten Blick scheint das Hinzufügen der Produktlinks ein nettes Feature zu sein und tatsächlich erscheint es sehr lahm, dass die Standard-WooCommerce-Kunden-E-Mails überhaupt keine Links enthalten (!!), aber es sollte wahrscheinlich nicht die Aufgabe dieses Plugins sein um die E-Mail-Vorlagen auf diese Weise zu ändern.
Und es gibt wahrscheinlich einen Grund, warum wooCommerce dies nicht tut: Der Kunde kann die E-Mail lange Zeit als Quittung aufbewahren, aber das Produkt könnte später bearbeitet werden, sodass es nicht mehr mit dem Link übereinstimmt. Das sieht schlecht aus, wenn der Kunde später auf die alte Bestell-E-Mail klickt.
Also könnte ich das zu einer Option machen...

Ich habe auch einen Grund für das scheinbar inkonsistente Verhalten:

• Die Standard-WooCommerce-Funktionalität verwendet product->get_name(), die von wp_posts.post_title abzuleiten scheint
  Normalerweise wird der Variationstitel in diesem Feld nicht angezeigt, sodass er schwer zu verfolgen ist. Die tatsächlichen Variationstitel können jedoch davon abhängen, welche Versionen der WooCommerce- und WooCommerce Polylang-Integration zum Zeitpunkt der Erstellung oder Speicherung der Variationen installiert wurden.

Beobachtet habe ich folgende Formate in einem im letzten Jahr aufgebauten Shop:

• [Produktname] übersetzt, aber keine Variationsinformationen
• Variante #[variation_id] von [Produktname]
• [Produktname] [Variantenname] unübersetzter Variantenname
• [Produktname] [Variantenname] übersetzter Variantenname

Die richtige Lösung kann also die folgenden Elemente haben:

• Identifizieren Sie den richtigen Variationsnamen und stellen Sie sicher, dass dieser beim Speichern/Aktualisieren des Produkts richtig eingestellt ist
• Erstellen Sie ein Skript, um die korrekten Produktvariantennamen und den richtigen Code neu zu erstellen, um es beim Aktualisieren des Plugins genau einmal auszuführen
• die Funktion translateProductNameInOrdersDetails könnte dann entfernt werden, da der Name nativ korrekt ist...

Das richtige Speichern des Namens muss logischerweise besser sein, als zu versuchen, den Namen überall dort einzuhaken und zu ändern, wo er verwendet werden kann.

wooCommerce 3.0 hat auch dafür etwas Code:

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, das wird kompliziert, ich wollte es wooCommerce melden, aber es gibt vor 5 Tagen einen entsprechenden Check-in und wurde zu 3.0.8 hinzugefügt: https://github.com/woocommerce/woocommerce/issues/15315
Es wäre also sinnvoll, das zu überprüfen.

Grundsätzlich hat wooCommerce 3.0.7 noch Probleme mit der Variantenbeschreibung im Warenkorb und damit auch in den Bestellungen.
Hier ist eine Sequenz mit einfacher WooCommerce 3.0.7 nach dem Deaktivieren der Polylang- und Polylang WooCommerce-Integration .

1. Erstellen Sie ein Produktattribut, z. B. Farbe mit den Begriffen Schwarz und Blau
2. Erstellen Sie ein neues Variationsprodukt mit Variationen für Schwarz und Blau
3. Ändern Sie den Begriff Blue in NewBlue
4. Produkt ansehen - es zeigt jetzt die Variante „NewBlue“
5. In den Warenkorb legen, Warenkorb anzeigen
6. Warenkorb zeigt jetzt: Test-Sync-Varianten - Blau
   Farbe: NewBlue
7. Bearbeiten Sie nun das Produkt, ändern Sie beispielsweise den Titel….
   Der Variationstitel wird nie vollständig zurückgesetzt und verbleibt mit dem alten Attributwert, da der WooCommerce-Code nur den alten Produkttitel durch Suchen ersetzt und den Titel nie vollständig neu erstellt.
   So sehr das Produktattribut auch geändert wird, der Titel wird nie zurückgesetzt:

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              |

(Das Attribut Blau wird umbenannt, aber die Beschreibung für Warenkorb/Bestellung wird nie richtig aktualisiert)

Wie wooCommerce den Link macht:
Beim Speichern:
class-wc-product-variable.php save() l.394 Aufrufe
$this->data_store->sync_variation_names( $this, $vorheriger_name, $neuer_name );
class-wc-product-variable-data-store-cpt.php sync_variation_names() ll.304++
ersetzt eine Zeichenfolge die Namen anstelle eines neuen Namens
hier wird also kein übersetzter Variationsstring aufgenommen, sondern nur den Titelteil ersetzt

Im vorherigen Kommentar ist generate_product_title() eine geschützte Funktion einer internen Datenklasse, die von außerhalb von WooCommerce nicht ohne weiteres überschrieben werden kann.

Im Zusammenhang mit all dem funktioniert WooCommerce-Polylang: Auf Variationsebene fügt WooCommerce-Polylang eine eigene Referenz hinzu, um sicherzustellen, dass Variationsdetails normalerweise aus der Mastersprachkopie der Variation abgerufen werden - siehe Ausgabe #168

Ich glaube, wenden Sie eine vorübergehende Lösung an, indem Sie einen Filter "woocommerce_product_variation_get_name" verwenden.

Es wird eine weitere kuriose Alternative erwähnt, die Produktattribute im Titel zu deaktivieren, was bedeutet, dass sie stattdessen nach dem Titel gedruckt werden sollten.
add_filter( 'woocommerce_product_variation_title_include_attributes', '__return_false' );
Dies funktioniert jedoch bei mir nicht.

OK, DIES IST IM WOOCOMMERCE BEHOBEN!!!

getestet mit neuestem Code https://github.com/woocommerce/woocommerce "Version 3.1.0-beta"
und wird voraussichtlich in 3.0.8 veröffentlicht.

und mit der woo-poly translateProductNameInOrdersDetails() Funktion ausgeschaltet,
dann wird der Woocommerce-Fix angewendet

Auch wenn gewünscht die
add_filter( 'woocommerce_product_variation_title_include_attributes', '__return_false');
funktioniert im aktualisierten WooCommerce

Könnte WooCommerce 3.1 statt 3.0.8 sein, wenn man sich den Woocommerce-Blog ansieht: https://woocommerce.wordpress.com/
2 Wochen ab dem 31. Mai würden den Veröffentlichungstermin vielleicht auf den 14. Juni setzen.

Beachten Sie, dass woocommerce/woocommerce#15315 in letzter Minute von 3.0.8 fallen gelassen wurde, aber immer noch für 3.1 mit einer gründlicheren Überprüfung geplant ist.
Bis dahin können Variationsdetails im Warenkorb/in den Bestellungen ungerade sein.

Typisches Ergebnis kann zB sein:

Spanischer Produktname - _Englischer Variationsbegriff_
Attributname - _Spanischer Variationsbegriff_