variations should have language attributes

[Jon007]

Can you reproduce this issue on default Wordpress theme (eg Storefront)?

yes

Can you reproduce this issue when all other plugins are disabled except WooCommerce, Polylang and Hyyan WooCommerce Polylang Integration?

yes

What product versions and settings are you using when this issue occurs?

• PHP: 7.1
• WordPress: 4.9.7
• WooCommerce: 3.4.4
• Polylang: [state if using Polylang PRO] 2.3.8
• Hyyan WooCommerce Polylang Integration: 1.2.0
• Browser: any

Steps to Reproduce

1. Export product variations using functions like WC_Product_Query->get_products()

What I Expected

product variations should be included if passed in the args

What Happened Instead

product variations are not included.

This is because product variations do not have a language assigned, but Polylang adds the language filter, so they become excluded.

@hyyan why are the variations linked by '_point_to_variation' rather than using the native Polylang functions to link up the variations? - in which case variations would be compatible with the rest of Polylang and need less special handling?

[Jon007]

Language can be set on variations by running:

insert into wp_term_relationships (object_id, term_taxonomy_id)
select vp.ID, tt1.term_taxonomy_id
FROM wp_posts p inner join wp_posts vp on p.ID = vp.post_parent
inner join wp_term_relationships AS tr1 ON (p.ID = tr1.object_id) 
inner join wp_term_taxonomy tt1 on (tt1.term_taxonomy_id = tr1.term_taxonomy_id)
WHERE vp.post_type = 'product_variation' 
and tt1.taxonomy = 'language'
AND NOT EXISTS (
				SELECT 1
				FROM wp_term_relationships tr2
        inner join wp_term_taxonomy tt2 on (tt2.term_taxonomy_id = tr2.term_taxonomy_id)
				WHERE tt2.taxonomy = 'language'
				AND tr2.object_id = vp.ID
			)

vp is the variation post, p is the parent post, joined to the language taxonomy via the term_relationships table.
The NOT EXISTS clause makes this query rerunnable by excluding variations which already have a language set. [ie, as a hack you could rerun this after adding more variations]

if you want to check your data before running try eg:
how many variations should be assigned to each language

select t.name, t.slug, count(*)
FROM wp_posts p inner join wp_posts vp on p.ID = vp.post_parent
inner join wp_term_relationships AS tr1 ON (p.ID = tr1.object_id) 
inner join wp_term_taxonomy tt1 on (tt1.term_taxonomy_id = tr1.term_taxonomy_id)
inner join wp_terms t on tt1.term_id = t.term_id
WHERE vp.post_type = 'product_variation' 
and tt1.taxonomy = 'language'
group by t.name, t.slug

how many variations actually are assigned to each language: you could run this before and after to test and confirm effect of insert

select t.name, t.slug, count(*)
FROM wp_posts p inner join wp_posts vp on p.ID = vp.post_parent
inner join wp_term_relationships AS tr1 ON (vp.ID = tr1.object_id) 
inner join wp_term_taxonomy tt1 on (tt1.term_taxonomy_id = tr1.term_taxonomy_id)
inner join wp_terms t on tt1.term_id = t.term_id
WHERE vp.post_type = 'product_variation' 
and tt1.taxonomy = 'language'
group by t.name, t.slug

Notes:

• the difference between the two queries is the join p.ID = tr1.object_id or vp.ID = tr1.object_id : the first joins by the parent post to count how many variations should exist in each language according to the language of the parent post, the second query checks how many DO exist in each language by joining on the variation posts directly
• The table prefix wp_ would need changing according to the site.

The SQL is fine, more testing needed to see if there is any negative impact from adding the language reference.
If there is any issue, this query would roll back the change by removing the language term relationship for product_variation posts

delete tr1.* from wp_term_relationships tr1
inner join  wp_posts vp ON (vp.ID = tr1.object_id) 
inner join wp_term_taxonomy tt1 on (tt1.term_taxonomy_id = tr1.term_taxonomy_id)
WHERE vp.post_type = 'product_variation' 
and tt1.taxonomy = 'language'

[Jon007]

Fixed in the code for any future saves of variations,
I'll just leave this open for consideration of automatic running of the language assignment insert on upgrade of the plugin.