magdamunro

Thanks Jarno. All translations were all up to date. I did reset to default and cleaned my cache in server as well as the browser. Still no Swedish in the cookie banner. I did translate those strings myself.

Something was succeeding, already before the above, in that the Cookie Policy partly is shown in Swedish. I’m not sure that is actively using the localization, so maybe only the untranslated words are from there? I’ll check.

thank you!

OK, I solved this by changing my site conf:

Options Indexes FollowSymLinks Includes ExecCGI
                AllowOverride All
                Order allow,deny
                Require all granted
                Allow from all

To comment on your follow-up I didn’t see before posting as the page was open:

I always purge the cache, though possibly not when disabling it. I’d assume once a cache function is disabled it’s not functional anymore. This is not so?

I have naturally already disabled ALL other plug-ins to arrive at that the “Minimum core” plugin is involved. It’s possible this is indeed making use of jquery-migrate, but if so I was unaware of this. I’ll investigate further.

On further investigation and analysis this problem seemed related to jQuery. It took me quite a while to realize the situation with jQuery in the WordPress platform and that W3 Total Cache has a setting for this. As far as I know I haven’t touched this setting, but “Disable jquery-migrate on the front-end” was checked.

The odd thing is that I understand it as jquery-migrate is NOT enabled by default and you need to explicitly enable this, otherwise you’re running the jQuery coming with your WP. However, as I didn’t run “Enable jQuery Migrate Helper” before I was under the impression I was running the current WP version. Using this plug-in does indicate at least one removed call in my theme, but it also indicates I’m running the latest jQuery. As far as I understand it, this would be so since quite a while and this menu was working before. I have to go back to check.

As removing the Total Cache plugin did NOT fix the issue —?I had to remove the “cache” and the “w3tc-config” folders manually —?this still doesn’t explain why this was active. Or does an uninstall warrant I find the settings W3 Total Cache has changed? I did turn off all cache functions before uninstalling. This wasn’t sufficient, you think?

I have already disabled all settings and this doesn’t help. Only inactivation helps. This issue seems more involved. I’ll investigate further what are the differences with this menu.

@crevette1406 Peut-être essayer de trouver où se situe le problème en déboguant?

@kowarler The suggestion from @drwpcom that

“Those types of “Deprecated” warnings generally indicate there is code in a theme or plugin that has not been updated. Please update your theme, as well as anything else listed as having an update available in your Plugins list.”

…is sound. In my case, because my theme already had been updated, I identified where the call was used and replaced it with the suggestion in the error message. I reported this a as bug to the theme developer.

You can test if it’s your theme my testing with another to see if the problem persists or not. Or just replace the call.

• This reply was modified 3 years, 12 months ago by magdamunro.

I don’t even have Jetpack, and I see this issue. Because of the discussion here I started to inactivate and reactivate plug-ins. The problem disappeared and returned slowly, so to me this indicates this is not about a specific plug-in. I’d assume it’s more about how some plug-ins are coded and how this may interact with Site Health. I do feel it’s Site Health possibly that should change its practice, but it may also just be an indicator of problematic setup, just not in the fashion developers of Site Health imagined.

Anyway, I settled on the minimum plug-ins and Site Health analysis finishes around a minute on my test machine, likely faster in the main server. Before it was forever.

I have no issues with (latest) Woocommerce, that I’m aware of anyway.

I also got this error on first use and moved to another plug-in instead. I control the environment 100% myself, so I don’t think this is memory related. Especially as I can see the content of each table with another DB tool and the rows are few as well.

I also saw this when testing a solution for a Contact Page theme bug and the local server was running PHP 7.3.1. For debugging reasons I switched to 7.2.14, as the bug wasn’t removed and that particular problem was gone then, as initially expected.

Note though that in my case Woocommerce messages and test emails from the Gmail SMTP test page worked also under PHP 7.3.

Thanks for the reply.

I don’t know what other info I can give you. ‘Select options’ is button text for the Woocommerce product listing page. Woocommerce already have the proper localization and everything is in the proper locale in the public pages as well back-end, so likely you’re not calling on their strings.

I already pointed to where in your source code the string ‘Please enter a value for ‘ is. There are no “user created custom fields”, is there? Is this in regard to possibilities within the woo-extra-product-options package?

Both these strings are resolvable by ‘Say What’ using the woo-extra-product-options plug-in name space. Indicating both strings are with your source code. But maybe I’m misunderstanding something here.

The lines I would like localized aren’t in there. It’s as simple as that. I see no frontend strings anywhere, not in the “/woo-extra-product-options/languages/woo-extra-product-options.pot” file nor in the version at translate.www.ads-software.com.

I have updated to “Woocommerce 3.7.0” as well as “Extra Product Options 2.0.4” in WordPress 5.2.2. “Say What” now finds the string in question. Excellent!

A front-end localization would be nice, but at the moment it’s overkill as it’s 2 lines.

Thank you!