Link Variable products using standard Polylang post_translations taxonomy

[Jon007]

Enhancement: remove all restrictions on Variable products.

• add translation links for variations by using using standard Polylang post_translations taxonomy
• remove the _point_to_variation DUPLICATE_KEY handling
• remove the restrictions on variable products

This is too much work for v1.0, in the meantime there is a temporary fix for #149 by removing _point_to_variation meta when is a new product.

[Jon007]

This should be implemented by using pll_save_post_translations( $arr ); to link the variation translations.
This means would allow pll_get_post_translations to be used later to get the result.
An activation routine is also need to allow variations not previously linked to be linked.

[Jon007]

If the variations were linked by Polylang, it would be possible to get translated variation using:
$translated_id = pll_get_post( $product_id, $lang);

Currently to get translated variation a function like this can be used using the '_point_to_variation' key added by this plugin:

/*
 * get the translated product, including if it is a variation product, get the translated variation
 * if there is no translation, return the original product
 * 
 * @param int $product_id   Product 
 *
 * @return int    translated product or variation (or original if no translation)
 * 
 */
function get_translated_variation($product_id, $lang)
{
    if (! $lang){
        $lang = pll_current_language();
    }
    //if input is already in correct language just return it
    $sourcelang = pll_get_post_language($product_id);
    if ($sourcelang == $lang){
        return $product_id;
    }
    //if a translated item is found, return it
    $translated_id = pll_get_post( $product_id, $lang);
    if ( ( $translated_id ) && ( $translated_id != $product_id ) ){
        return $translated_id;
    }
    //ok no linked Polylang translation so maybe it's a variation
    $product = wc_get_product($product_id);
    if ($product && 'variation' === $product->get_type()) {
        //it's a variation, so let's get the parent and translate that
        $parent_id = $product->get_parent_id();
        $translated_id = pll_get_post( $parent_id, $lang);
        //if no translation return the original product variation id
        if ((! $translated_id) || ($translated_id == $parent_id) ) {
            return $product_id;
        }
        //ok, it's a variation and the parent product is translated, so here's what to do:
        //find the master link for this variation using the Hyyan '_point_to_variation' key
        $variationmaster = get_post_meta($product_id, '_point_to_variation');
        if (! $variationmaster){
            return $product_id;
        }
        //and now the related variation for the translation
        $posts = get_posts(array(
            'meta_key' => '_point_to_variation',
            'meta_value' => $variationmaster,
            'post_type' => 'product_variation',
            'post_parent' => $translated_id,
        ));        
        //return the related variation if there is one
        if ( count($posts) ){
            return $posts[0]->ID;
        } else {
            //if this variation hasn't been translated, return the original
            return $product_id;
        }
    }
}

Well, as long as the linking is done one way or another, it should then be possible to write extra check functions, to check for example if the variable product has been relinked to a different master product.

For example with correctly linked variations, these two values should be the same:

//get the parent of the translated variation
get_translated_variation($variation->get_id(), $masterlang)->get_parent_id() 
//get the translated parent of the current variation
pll_get_post( $variation->get_parent_id(), $lang)

If they are not the same then may need relinking..

[Jon007]

I'm going to close this as I think this re-engineering is now not necessary for the following reasons.

1. adding the meta links would just add unnecessary weight to the taxonomy tables and caches which are some of the largest in the system already
2. it is not generally to query by variations, instead get the variable products and where necessary use the functions as above