Draxeiro

Hi Shahzeen,

To my knowledge is previously worked without a problem. It seems it might be something that was recently introduced after a plugin update. Am investigated which one could be the culprit.

Hi @shameemreza,

Thanks for the clarification (also with regards to who can set the topic as resolved). Will pass this on to my customer.

At the same time I think it would be a good idea if a solution was implemented that would increase the number of attribute terms displayed in the backend.

While your instructions were clear this didn’t do anything for the problem at hand.

I’ve made a few screenshots to further clarify. As said the client uses various attributes with a large amounts of terms. See: https://snipboard.io/lZneXC.jpg

However when he is adding a new product and adds an attribute with a lot of terms the selection list will stop at number 50-51. See: https://snipboard.io/HgSXoM.jpg

He will still be able to type in the name and select a term further down the list that way, but the selection list will not scroll further.

Adding the filter discussed above does not seem to have done anything. So I hope you can look further into this.

By the way, I noticed that seank123 set this topic to resolved, while it isn’t resolved yet but for some reason I am not able to change the status…

I can’t say the documentation on where to change what in this filter is clear. What needs to be changed to a greater numer?

See the filter below:

function custom_wc_ajax_variation_threshold( $qty, $product ) {
	return 10;
}

add_filter( 'woocommerce_ajax_variation_threshold', 'custom_wc_ajax_variation_threshold', 10, 2 );

One of our clients ran into this problem too: For various attributes he has a large amounts of terms (50+ and for one attribute even 98). However, when selecting the terms when adding a product Woocommerce will not scroll past term number 51. A workaround is typing in the name directly.

Our client is quite sure that this problem was not present in the previous Woocommerce version.

Hope you can look into this soon.

Nog altijd 0 reactie van PostNL…. en het probleem speelt nog steeds hier. Ook bij anderen? En zo ja, heeft iemand eventueel een workaround gevonden?

The same happened here, on a site that has been using the cache for a long time already. So I do not think it is as easy as your suggested solution, as the server would already be started and running at the moment of the update.

For now I have disabled the plugin. Hope you will look into this further soon.

I am contacting you too.

I can confirm Mauri01’s report: For us it is exactly the same.

We are selecting the local images from Sharepoint by the way.

When I upload through the regular media upload: Not a problem. Using another image replace plugin: Not a problem either.

But when trying the media replace functionality of this plugin: This failure notice each and every time.

• This reply was modified 2 years, 2 months ago by Draxeiro.

If I look at the dozens of sites we do maintenance for it is mixed: A fair number were upgraded to that alpha version while the majority were not.

Most of these sites were not on English language versions.

I think they managed to stop the rollout as it was happening and depending on how WP updates are rolled out probably certain geographic locations were affected more than others before they could shut it down.

The rollback on the affected sites was not problematic in any case. Just a matter of hitting the reinstall button and waiting a bit.

• This reply was modified 4 years, 5 months ago by Draxeiro.

Meaning: go to the update section of your own sites and reinstall, correct?

It seems the recent update to the latest version introduced this.

When I look in the update section there is a notice for Beta testers and a mention of the latest nightly builds.

• This reply was modified 4 years, 5 months ago by Draxeiro.

Not at all. Just regular installs without any test plugins or anything like that.

@modernnerd: Thank you for the prompt action on this Nick! I look forward to seeing the plugin page updated.

Truth be told I think using this plugin makes life a lot easier for Genesis users (we often use it on client sites) and it is good to know that Studiopress is committed to supporting it.

We very much prefer the Genesis/Woo combo as oppossed to having to opt for a different framework/theme.

I can confirm the problem is indeed caused by the upgrade to WordPress 5.1.

Please solve this a.s.a.p.