Problems with Variable Products

[FrankRosElche]

Hi,

We have problems editing variable products after last woocommerce update.

Product data indicates "Simple Product" but the product is variable.

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

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

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

• PHP:
• WordPress:
• WooCommerce:
• Polylang: [state if using Polylang PRO]
• Hyyan WooCommerce Polylang Integration:
• Browser:

Steps to Reproduce

What I Expected

What Happened Instead

WordPress Environment

``` Copy and paste the system status report from **WooCommerce > System Status** in WordPress admin here. ```

[jacopobonomi]

I have the same problem, if I copy from primary languages, i show only simple products, without the possibility to copy variation. How can I solve this?

[vinvin27]

Hello,

Did you try to install plugin "jQuery Migrate Helper" ?

[edgarmirandasilva]

Can you please use the code from the repository, download zip directly from download code and install, i think it might be solved, i will be testing this a lot next week, but every feedback is welcome.

[jacopobonomi]

Can you please use the code from the repository, download zip directly from download code and install, i think it might be solved, i will be testing this a lot next week, but every feedback is welcome.

After downloading zip and installing from GitHub I have 2 problems:

1. If I copy a product from the primary language into the secondary it creates many variations, (example if I have a product with 2 colors, the second language creates 10 variations from the color)
2. After a customer's order, the product becomes out of stock even if there are still stocks.

[mrleemon]

1. If I copy a product from the primary language into the secondary it creates many variations, (example if I have a product with 2 colors, the second language creates 10 variations from the color)

I'm having the same problem with the GitHub version of the plugin

[mrleemon]

It seems that the latest PR #518 has screwed up something related to variable products.

[jacopobonomi]

Ok i read topic, now the problem is a misspelling in a meta attribute. Can we solve with a update query and fix the name in src/Hyyan/WPI/Plugin.php?
@mrleemon i saw you are a collaborator in this project, if you give me some guidelines on this error I can try a solution and make it available to the community.

[mrleemon]

Sorry, I only commited some fixes for typos long time ago. My knowledge of the inner workings of this plugin is near zero.
I don't know what has to be done to fix this variations bug.

[mrleemon]

Right now, I think that the only one knowing how this plugin works is @Jon007

[Jon007]

I did see that #518 included this typo fix which I already rejected on #450 as it would be likely to break existing sites, but @hyyan has accepted it...

[hyyan]

I reverted #518 for now. And I will take a deeper look later

[mrleemon]

Thanks!

[mrleemon]

Maybe the plugin should use the official Polylang pll_copy_taxonomies filter to sync WooCommerce taxonomies (product_type, product_visibility and others) instead of the current custom way, which seems vulnerable to the constant WooCommerce releases. The plugin already uses Polylang pll_copy_post_metas filter to copy product meta, so it seems reasonable to use pll_copy_taxonomies to sync product taxonomies.

With this filter, one can specify the taxonomies one wants to sync or copy and Polylang takes care of the synchronization/copy of said taxonomies and their related terms when one creates a new translation.

Just an idea.

[Jon007]

I looked at that but all these are getting dangerously obsolete, as woocommerce moves more towards its own api and its own tables you can't rely on treating products as a post and using generic post based apis. At best there'll be bugs with the woocommerce caching mechanism.

[mrleemon]

Yes, I know that. I was thinking about it as a temporary solution while we wait for WC api changes.
Meanwhile, I think we can solve the incorrect selection of "Simple Product" when the product is variable changing the JS code in Meta.php to:

From:

$code = sprintf(
    '// <![CDATA[ %1$s'
    . ' addLoadEvent(function () { %1$s'
    . '  jQuery("#product-type option")'
    . '     .removeAttr("selected");%1$s'
    . '  jQuery("#product-type option[value=\"%2$s\"]")'
    . '    .attr("selected", "selected");%1$s'
    . '})'
    . '// ]]>', PHP_EOL, $type[0]
);

To:

$code = sprintf(
    '// <![CDATA[ %1$s'
    . ' addLoadEvent(function () { %1$s'
    . '  jQuery("#product-type option")'
    . '     .prop("selected", false);%1$s'
    . '  jQuery("#product-type option[value=\"%2$s\"]")'
    . '     .prop("selected", true);%1$s'
    . '})'
    . '// ]]>', PHP_EOL, $type[0]
);

Apparently, the use of attr() and removeAttr() for selecting/deselecting options is deprecated with the jQuery recent changes in WP.

[mrleemon]

From https://jquery.com/upgrade-guide/3.0/:

Breaking change: .removeAttr() no longer sets properties to false

Prior to jQuery 3.0, using .removeAttr() on a boolean attribute such as checked, selected, or readonly would also set the corresponding named property to false. This behavior was required for ancient versions of Internet Explorer but is not correct for modern browsers because the attribute represents the initial value and the property represents the current (dynamic) value.

It is almost always a mistake to use .removeAttr( "checked" ) on a DOM element. The only time it might be useful is if the DOM is later going to be serialized back to an HTML string. In all other cases, .prop( "checked", false ) should be used instead.

[mrleemon]

Also, right now, when the user clicks WC duplicate product link, the product type is not copied over the replica.

I "fixed" it by adding this to the unlinkOrginalProductTranslations() function in Duplicator.php:

$type = $product->get_type();
update_post_meta($duplicate->get_id(), '_translation_porduct_type', $type);

I don't know if there's anything wrong with this.

[Jon007]

I'd like to get rid of '_translation_porduct_type' altogether, it shouldn't really be necessary, it's only there to cope with user interface quirk, however the simplest for now is to keep it and do as you suggest

[mrleemon]

I was going to ask you about this. Why is the translated product type stored in _translation_porduct_type? Can't it be retrieved from the original product directly when needed?

[Jon007]

I think it's complicated because when translating polylang is there trying to give you the translated product details when you ask for the old product, at least, copying it across in the metadata is easier

[mrleemon]

I think that in order to get rid of the _translation_porduct_type meta, the plugin should use the WC API WC_Product:save() function to store translations instead of relying in a custom solution using the wp_insert_post action directly, but this means refactoring much of the code found in Meta.php and I don't know where to begin.

[frontsilent]

Hi. Have you solved this problem?

[Jon007]

Hi, I committed some solutions to the Variable products issues including some explanation on #430 - it would be great if someone could test the latest code and confirm what issues remain - ideally on a new clean github issue, as there have been many partially or wholly duplicated tickets and getting hard to follow.

[mrleemon]

Thanks for your work! I'll test the latest code when I get a chance and I'll let you know if any issues arise.

[mrleemon]

I opened an issue after testing your latest code:
#526

[Jon007]

@hyyan @mrleemon I checked in some important changes last week and labelled 5.1

In particular I have removed the workaround fix by @mrleemon on #408 by commenting out the meta.php call to:
$this->syncSelectedproductType( $ID );

Previously we had this problem because the save sequence was not correct at least in 5.0 it was:

1. WordPress saves post
2. woopoly synchronises post (but WooCommerce is not yet saved so Product Type is not saved and synchronised correctly)
3. WooCommerce saves product
4. [for variable product, WooCommerce saves variations and woopoly synchronises these]
5. When viewing product translation, the workaround fix reset the form to show the product type in the _translation_porduct_type so that on saving the translation it is then correct

The code revisions now pick up the hooks just after WooCommerce save, and have been adjusted to work on quick edit (#549) and bulk edit too so the product type workarounds are no longer needed.

Of course this isn't the end of it - the whole thing should be re-reviewed to only use the woo api and avoid the wp api - but should remove some of the odd behaviours.

[mrleemon]

Great! That workaround fix was truly awful.
So, is the misspelled _translation_porduct_type meta no longer necessary, either?
I'm going to test this updated version when I have a minute.

Thanks!

[Jon007]

I’ve left the the misspelled _translation_porduct_type meta assignment in there for now but it isn’t used. If this version goes ok a subsequent release could remove this and other redundant code

[mrleemon]

I tested this new version and I found an issue:

1. I have a site with three languages (Spanish, English and French). Spanish is the default one. The "Product-type" sync option in woopoly is checked.
2. I add a new product in Spanish
3. I select "Grouped product" (or any product type other than "Simple product") and save.
4. The product type dropdown shows the selected product type.
5. I click any "+" link in the "Languages" metabox to add a translation.
6. The product type dropdown in the new translation is disabled (the "Product-type" sync option is checked) but it shows "Simple product" instead of the selected product type in the default language product.

[Jon007]

Ok yes I’ll take a look.
Changing product types (and any other property) on existing products should be fine.

[Jon007]

@mrleemon checked in: on new translations needed to keep the wordpress hook as the woo hook is not fired yet

[mrleemon]

Ok, thanks!
I'll test it later when I have a moment and come back to you as soon as possible.

[mrleemon]

I tested this new version and my issue with new translations is fixed.
Thanks!