cockpitseeker

Right. I can close this thread if you think that’s the proper course of action.

*facepalm* I stand corrected the feature is there! Sorry for having wasted your time.

/**
* Hides third party admin notices on the SkyVerge pages.
* @see \Automattic\WooCommerce\Admin\Loader::inject_before_notices()
*/

@grynge that was funny !
Anyway, thanks both of you, that will do ??

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

Thanks

To whoever is reading this, apparently the woo membership plugin is developed by this SkyVerge entity, thus their appearance in the latest update of the plugin. They just decided to display their brand with their own icon in the admin WP dashboard for more clutter ??

Mystery solved.

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

Flushed all cache and issue still here. WooCommerce Admin deactivated and deleted as well. No dice.

Regarding that, it seems that the settings previously used on the last tweaked widget are the ones that apply by default to new ones.

In the meantime I reverted to 1.1.13 and:

• settings now properly apply – solves the issue
• however, dynamic settings still auto apply (instead of static after saving)
• …and previously used settings are the ones applying by default also (before applying changes that now work).

I use widgets with blank (no) titles quite often if this could have a bearing on how the code changed between current v1.5.14 and former .13 version.

• This reply was modified 6 years ago by cockpitseeker.

Behaviour remains the same :/

• saved widget stays dynamic with some random presets
• changing these presets isn’t taken into account frontend-wise

Is it possible a very high number of widget would cause a problem here? Like IDs assignment or something, because the one more widget I’m trying to add is the 100th…

I confirm. Haven’t skipped a beat of your previous updates.

My theme hasn’t changed either, so yeah, my WP environment remained static if that’s your question ;). All things equal, this issue arose somehow.
edit: thanks for coming back to me on this

• This reply was modified 6 years, 1 month ago by cockpitseeker. Reason: thanks to the dev

Exactly my point. It used to do something, now it doesn’t and stays “dynamic” from the get go. Conditional choices are not respected frontend, even though backend has the desired setting.

Er… wait I’m confused, it’s wc-core-functions.php you edited, right?

@coen Jacobs: thanks for your reply and giving the straight answer (it’s all theme related after all).
Thanks in advance for the link as well :). No bashing intended anywhere, otherwise I wouldn’t be caring for woo in this troubleshooting-thread in the first place.

I stand on my opinion that it’s too bad woo doesn’t work out of the box, but I understand there might be no other way (just like the template issue where theme devs had to hook their own wrapper’s name to prevent misbehaviour)

@aaplfan: It seems then it’s more of a problem than just a wrong path (files being wrongly distributed amont folders?)… at least for you :/

@lalune: what do you mean by “symbolic link”?

@elegant Themes: I guess you’re adressing alistairgd’s initial issue. What about aaplfan’s remark underlining whole files could be misplaced.
Indeed, only copying the “shop” folder info the “template” one calmed the warnings for him (which doesn’t necessarily mean woo is functionning properly btw).

Please if you solved the issue with other clients already (have you?), tweaking your theme files, let us know what you did (as I suspect it’s more than theme related… but I could be wrong).

@woo-devs: if you guys read this, for what my opinion is worth, I find it too bad having to hackity-hack one’s files (other than you plugin’s) with custom plugin code to grant compatibility. It doesnt look like good practice to me.

Did you try to just rename “global” to “shop” (I’d like to know if errors occur with such change as they have slightly different files inside)?