homullus

TLDR for anyone coming here:
– The setting in a single product always takes precedence over the “global” setting. Thus, someone decided it is smart to: not only throw a warning, but to completely prevent the user from updating products locally. This is a silly decision which can be reversed within 15 minutes, but SkyVerge are stalling.

The only way to resolve it currently is to perform a migration script that sets the value for each product individually, or set them by hand as @madmax4ever proposed. Or, disable the plugin, edit stuff, re-enable.

—

The horrendous level ignorance exhibited by Jennifer and Simon from SkyVerge above are easily enough to get me to uninstall the plugin, as i no longer trust this developer with my shop.

They repeatedly reference issues which have nothing to do with the plugin, blame Facebook API, even try to defer people to open new topics as “this one is resolved”. While at the same time absolutely knowing that the issue is very much not resolved.

@madmax4ever managed to decypher the ramblings of Simon from one of the first replies. The cascade of inclusion is such that the product-level meta value always takes precedence over the global value – in the context of the editor. Thus, even if you exclude a category in global, the editor will not let you save because of the local value. It is not aware that the value has not actually ever been set.

But that is actually not the problem. That is a symptom. The problem is that SkyVerge is confident enough to prevent a user from saving. Yeah, read that again. They believe that instead of dropping a subtle warning and letting Woo work – their plugin is so important, that they have the authority to prevent everyone from using Woo whenever they feel like it.

Reading all of the above messages and the general unprofessional approach of SkyVerge made me uninstall the damn thing and just write my own within a space of 2 hours. Its just a stupid csv file, not rocket science.

It’s sad :/

It is not super-pretty, but fits well with my theme, and doesn’t require any invasive changes to the DOM. @pluginswoo

Screenshot: https://imgur.com/noTdIES
Code: https://www.dropbox.com/t/xLExXSRvfYbRrhyM

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

Nevermind, made it myself.
Hoping it arrives soon as part of the plugin tho ??

P.S. I would be glad to share the JS with you if you want.

Hello Peva, the real answer you are looking for is:

add_filter( 'woocommerce_hide_invisible_variations', '__return_false' );

Asbolutely the same issue. I took some time to debug it, and i can reproduce it without any plugins other than Woo present.

Attriutes and variations still do exists on my products, even hand written url filters work fine. But the little widgets for attributes do not appear anymore. In fact, sometimes they apprear, but only see certain products.

For example, this page would have a sidebar full of options prior to the update.
https://macola.rs/apple-store/mac

It seems that DB is not affected at all, and i had to revert to Stable tag: 4.3.2 on production code.

• This reply was modified 4 years, 7 months ago by homullus.

Nice, so if it’s open source, i guess you might have a Git-based repo that you use for actual development and tickets, because WP’s system is blah… If so, could i get a link, to look around, maybe i would be interested in solving some tickets or translating or something similar.

Hey, thanks for the response, and fixing the thing. Is the project open source or licenced for now?

Will rate ofc ??

Ok, so the answer to my question is:

You need to create variations of your product for it to show up in the picker.
You can create variations on the product page itself, once you add attributes, a new tab should appear called variations.

Thank you for your fast response,

i suspected that init was used, but had no time to look at the plugin code because of some deadlines. I will definitely try with init tonight and report back. ??