English Order email does not include variation information

[damiencarbery]

I am running WordPress 4.7.5, WooCommerce 3.0.7 and a master branch version of Hyyan WooCommerce Polylang (downloaded 15 May, after WC 3 changes were committed).

When the order emails are sent to the customer and the admin the variation information is not present.
The products are variable products with variations created for each value in the single attribute.
For products with more than one attribute it has variations created for one attribute. In this case the other attribute info does appear in the email.

When I disable Hyyan WooCommerce Polylang the variation information does appear in the emails.
Product box in email: Unicorn Fantasy Dog Bandana
When plugin disabled: Unicorn Fantasy Dog Bandana - 12inch

I tried experimenting with the 'woocommerce_order_item_name' filter to see the value of $item_name but it was always null!
I tried to isolate the issue by disabling the add_filter call for 'translateProductNameInOrdersDetails' function in Hyyan\WPI\Order.php's __construct() but it resulted in a NULL product name!

I am happy to try out any ideas and add debug messages.

[Jon007]

Please try again with the latest version, now released as Hyyan WooCommerce Polylang Integration 1.0.
The first set of wooCommerce 3.0 changes did not include thorough review of variations.

Having said that, I'm just retesting it and in my plain test installation:

• the email to the shop owner includes variation detail
• the email to the customer doesn't include the variation detail

If I then turn off both woo-poly-integration and polylang, I get the same result... so this is in the WooCommerce templates themselves.
so if you need you could adjust the template or raise the issue to WooCommerce.

Please check and confirm back here.

[damiencarbery]

I did a test order and the variation information was not in either email.
Is there anything I can do to help you debug the issue?

[Jon007]

Well, if you are confirming that the variation information is not in the email when Polylang and woo-poly are turned off then it's not an issue with this plugin...

[damiencarbery]

I disabled woo-poly and now I see the variation information in the email to the admin.
e.g. "Navy Movie Stars Dog Bandana – 26inch" (where "26inch" is the variation information).

[damiencarbery]

I enabled woo-poly again and the variation information is gone again.

Additional information:

• Variation detail is always shown in checkout.
• Variation detail is not in order-received page when woo-poly active.
• Variation detail is not in admin email when woo-poly active.
• Variation detail is not in customer email when woo-poly active (it is there when woo-poly inactive, different from what you noticed).

[Jon007]

was is that in base language or second language?

[damiencarbery]

Base language.
Do you want me to try it in the second language? (the site only has 2 active languages - English and German).

[Jon007]

Ok, here's the issue:

Order.php l. 118** function translateProductNameInOrdersDetails
is trying to be clever and add links on each order item to go back to the product details as well as [failing to] translate the variation name.

You can tell this by adding a the first line of this function:
return $name;

You'll get the name of the product variation on the emails etc but it will always be in shop base language.

At first sight, the addition of the product links seems a nice feature and indeed it seems hugely lame that the standard WooCommerce customer emails do not include any links at all (!!), however it probably shouldn't be the job of this plugin to modify the email templates in this way.
And there's probably a reason wooCommerce doesn't do this: the customer may keep the email for ages as a receipt, but the product might be edited later so it no longer matches the link. This looks bad if the customer clicks on the old order email later.
So I might make this an option...

[Jon007]

I also have a reason for the apparent inconsistent behaviour:

• the standard wooCommerce functionality uses product->get_name() which appears to derive from wp_posts.post_title
  Normally you don't see the variation title from this field, so it's hard to track, however the actual variation titles may depend on which versions of WooCommerce and WooCommerce Polylang integration were installed at the time of creating or saving the variations.

Observationally I have the following formats in a shop built over the last year:

• [product name] translated but no variation information
• Variation #[variation_id] of [product name]
• [product name] [variation name] untranslated variation name
• [product name] [variation name] translated variation name

So the correct solution may have the following elements:

• identify the correct variation name and ensure this is set correctly on save/update of product
• create an script to rebuild the correct product variation names and code to run it exactly once on update of the plugin
• the function translateProductNameInOrdersDetails could then be removed, since the name will be correct natively...

Logically saving the name correctly must be better than trying to hook and change the name everywhere it may be used.

[Jon007]

wooCommerce 3.0 has some code for this too:

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

[Jon007]

ok, this is getting complicated, I was going to report it to wooCommerce, but there's a related checkin 5 days ago and added to the 3.0.8: woocommerce/woocommerce#15315
so it would be sensible to review that.

Basically wooCommerce 3.0.7 still has problems with the variation description in Cart and indeed therefore in Orders.
Here is a sequence with plain WooCommerce 3.0.7 after turning off Polylang and Polylang WooCommerce integration.

1. Create a Product Attribute eg Colour with Terms Black and Blue
2. Create a new Variation Product with Variations for Black and Blue
3. Change the Term Blue to NewBlue
4. View the product - it now shows the variation “NewBlue”
5. Add to Basket, View Basket
6. basket now shows: Test Sync variations - Blue
   color: NewBlue
7. Now edit the product, for example change the title….
   The variation title will never be fully reset and remains with the old attribute value, because the WooCommerce code only does search-replace on the old product title, it never fully rebuilds the title.
   However much the product attribute is changed the title never gets reset:

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              |

(The attribute Blue is renamed but the description for Cart/Order is never quite updated properly)

How wooCommerce does the link:
On save:
class-wc-product-variable.php save() l.394 calls
$this->data_store->sync_variation_names( $this, $previous_name, $new_name );
class-wc-product-variable-data-store-cpt.php sync_variation_names() ll.304++
does a string replace within the names rather than a new name
so here a translated variation string is not picked up, it’s just replacing the title part

On the previous comment, generate_product_title() is a protected function of an internal data class so that’s not readily accessible for override from outside of WooCommerce.

So, related to all this is how WooCommerce-Polylang is working: at a variation level, WooCommerce-Polylang adds it's own reference to ensure that variation details are normally retrieved from the master language copy of the variation - see issue #168

I believe apply a temporary fix by using a filter "woocommerce_product_variation_get_name".

There is another curious alternative mentioned, to turn off the product attributes in Title which means that they should instead be printed after the title.
add_filter( 'woocommerce_product_variation_title_include_attributes', '__return_false' );
However this doesn't work for me.

[Jon007]

Ok, THIS IS FIXED IN WOOCOMMERCE!!!

tested with latest code https://github.com/woocommerce/woocommerce "Version 3.1.0-beta"
and expected to be released in 3.0.8.

and with the woo-poly translateProductNameInOrdersDetails() function turned off,
then the woocommerce fix will apply

Also if wanted the
add_filter( 'woocommerce_product_variation_title_include_attributes', '__return_false' );
works in the updated WooCommerce

[Jon007]

Might be WooCommerce 3.1 rather than 3.0.8, looking at woocommerce blog: https://woocommerce.wordpress.com/
2 weeks from May 31 would put release date as maybe 14 June.

[Jon007]

note, it looks like woocommerce/woocommerce#15315 was dropped from 3.0.8 at the last minute, but is still slated for 3.1 with more thorough review.
So variation details in basket/orders may continue to be odd until then.

Typical result may be eg:

Spanish product name - English Variation Term
Attribute Name - Spanish Variation Term