Major Issue with 3.0.1 update

The ALTER TABLE notices are unrelated and can be ignored. This is a WP issue which has been logged already.

Hi

Just tried with 3.0.4 – same thing happening but all still OK in 3.0.0

I had a look at the Chrome Developer console and get this error when trying to access the Variations tab

Also, just updated WordPress to 4.7.4 too

The debug.log has this in it too:

PHP Fatal error:  Call to a member function get_id() on boolean in /home/groupcom/public_html/wp-content/plugins/woocommerce/includes/class-wc-ajax.php on line 1582

Thanks

Ah thats helpful. Looks like it’s getting a variation which is not ‘valid’ for whatever reason:

https://github.com/woocommerce/woocommerce/blob/master/includes/class-wc-ajax.php#L1582

If before that line you add:

if ( !  $variation_object ) {
continue;
}

That will stop it.

Logged here so we can prevent it occurring https://github.com/woocommerce/woocommerce/issues/14592

Excellent – that’s fixed the busy icon so I can get to the Variations tab – but the tab is now empty for all the products – can I get the variations back? Reverting back to 3.0.0 still shows variations properly.

Thanks

Now this is going to be related to that workaround ^ since you have a variation that is not valid for some reason.

These lines control if a variation is valid: https://github.com/woocommerce/woocommerce/blob/master/includes/data-stores/class-wc-product-variation-data-store-cpt.php#L48-L56

And https://github.com/woocommerce/woocommerce/blob/master/includes/data-stores/class-wc-product-variation-data-store-cpt.php#L40-L42

Notice it does a few checks.

1 to check if the variation is a product_variation post type and has a valid ID.

1 to make sure the parent is a product.

Another to ensure the variation **has** a parent. I don’t know which of those is failing in your case, nor what would cause it to fail. Any chance you can look into those and maybe see if it has the ID and valid post type?

And also to ensure those variations for this product are not trashed. There was a bug in 3.0.0 which could trash variations and this would get it back https://gist.github.com/mikejolley/7dc21432643a4fdd342474dc2694a22d

I ran the SQL query to update trashed variations to publish (changed the prefix to the correct database – wp_2_ in my case) but this hasn’t fixed it.

Looking at the wp_2_posts in phpMyAdmin I can see the variations and have checked a few to make sure they have IDs and post type is product_variation – the post_parent value is the post ID of the correct product too

Was this a site running WPML or anything?

You could add some error_log calls into those parts I pointed out – then you can see which checks are not passing?

Not running WPML – never has either.

How would I do that?

Thanks

Might do this in core in the next version, but for now this line:

https://github.com/woocommerce/woocommerce/blob/58b7b82ee1939a3e37cc21be2a4ef697f00dc21c/includes/class-wc-product-factory.php#L48

Before that place:

error_log( $product_id . ': ' . $e->getMessage() );

This will place an entry in your error log if the variation cannot be read due to one of those checks I pointed out.

I’m happy to debug this also if you contact me on WordPress slack – I’d like to know if it’s a core bug or something else.

Hui Mike

Apologies for the delay getting back to you – we’ve been very busy in the shop!

I added that and found a lot of entries like this:

[09-May-2017 14:02:49 UTC] 14934: Invalid product tax status.
[09-May-2017 14:02:49 UTC] 14935: Invalid product tax status.
[09-May-2017 14:02:49 UTC] 14936: Invalid product tax status.

We have the Tax features disabled, but I did experiment with them last year so I’ve set all the products to a tax status of NONE and the variations now appear to be working in 3.0.5!

Thanks for your help with this.