Closed promediaserve closed 3 years ago
The same here, even with meta fields locks activated... when saving original language post, variations are duplicate only on the second language :0
same here. Multiple variations, with every save on product in original language with 2 variations, new variations are created. SOme products with 2 variations in original language have up to 40 variations in translation!
Same here. I posted a more detailed message about this issue here: https://github.com/hyyan/woo-poly-integration/issues/430
Where this could happen is if the relationship between the language, the products and the variations has changed. For example if the shop base language has changed (not supported) or the language of the product has been changed this could introduce problems. In these situations the products could have child variations which are not in the expected language (or are linked to variation attributes which are in the wrong language) and so can never be translated properly.
There was a fix on #430 related to the translated variations never being enabled, therefore when the code looked for the translations they could not be found and so were translated again.
You should find that for new products this should be working correctly.
Same here, though the fix on #430 seems to prevent it from happening again. Would there be a way of deleting unused or obsolete variations?
Well yes this can be done in the database, though I'm not sure of a one-size-fits all solution at the moment. Variations are posts of type product_variation in the posts table with post_parent being the parent product.
The old way the plugin worked for variations was via a post_meta called _point_to_variation which I believe is still there in the code. Using this one could find all the posts which share the same _point_to_variation and delete them. Since you only have two languages you could keep the highest post_id for each _point_to_variation and delete the others. I'd do this as a select query and checking it thoroughly before turning it to a delete...
Variations should now have a language since code checked in a couple of years ago on #348: some may not though if not edited since then, the backfill sql on this code was not incorporated to run automatically. This would then allow the code or sql to do more checks for example run a query to find variations which are assigned a language which is different from the parent product language and delete them. code for the taxonomy queries is also on on #348
Ultimately some more defensive code should be added, including disabling the ability to change the language of an existing product as this is fairly fatal to any existing translation links - if someone changed a product from English to French but is already linked to a French product, behaviour is undefinable, and worse if the product has variations.
Hi, it's me again 😄 Just dropping by because I've been figuring out some issues with duplicated variations and it seems that in my case they were being caused by WooCommerce storing funny values in transients. I added some logging to WC_Product_Variable_Data_Store_CPT->read_children, especifically something like this:
error_log("$children_transient_name: " . convert_multi_array($children));
error_log($wpdb->last_query);
So, I have a product with 77662 with four variations (two colous and two sizes) all of which should be translated. The same product in the secondary language has ID 73923. With this in mind, consider what happens whenever I update product 77662:
[05-Jul-2020 16:34:06 UTC] wc_product_children_77662: 80538, 80542, 80546, 80550
[05-Jul-2020 16:34:06 UTC] SELECT wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_parent = 77662 ...
[05-Jul-2020 16:34:18 UTC] wc_product_children_73923: 80538, 80542, 80546, 80550
[05-Jul-2020 16:34:18 UTC] SELECT wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_parent = 77662 ...
As you can see, the key does not match with the queries post_parent
, thus storing a wrong value in the transients which causes a series of issues like posts not displaying variations and the aforementioned duplication.
I fixed this by hacking that class, forcing the parameter bypassing cache to true. If you have any idea of a longer term fix or any clue of what might be happening, I would forever be beholden to you.
Thanks in advance!
Hi Ramonacus,
thanks for your workaround. I have the same problem but I cannot find any solutions. So I tried to fix the class class-wc-product-variable-data-store-cpt.php from read_children( &$product, $force_read = false ) to read_children( &$product, $force_read = true ) as you have written, but the problem is not gone.
Is there anything else to change?
Thanks in advance,
Chris
Is there anything else to change?
Aye, there is. Sorry I wasn't clear in my explanation. This hack prevents the issue from happening again, but it doesn't delete already existing duplicates. I am afraid that you will have to delete them, either directly in the database or manually via product page in the admin.
Thanks for your fast answer. I already delete the duplicate entries directly from the product page. And I modified the class but the problem is still alive. I forgot, my system is on the latest version of woocommerce and wordpress 5.5.3 with all fixes.
Hi, on #430 I added a fix to delete duplicate variations if found when saving a product, so with the latest source code, the next save on any affected product would clear it for that product, please try with latest source
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?
Steps to Reproduce
What I Expected
same number of variations
What Happened Instead
Duplicate variations in huge numbers, and more added on each save 11 variations becomes 72 then 112, 168... etc. number seems random, and not a multiple of original number of variations
WordPress Environment
Network, 3 languages enabled.