JackSim

I’ve opened an issue in the Yoast SEO repository about this. I’m seeing the same thing, my cache is completely nuked once a day just by visiting the admin:

https://github.com/Yoast/wordpress-seo/issues/20554

After investigating I’m 100% sure the issue comes from Yoast SEO, most likely linked to their SEO data optimization feature.

I can confirm what @sheriffdonnerknall is seeing, I posted a report on the original PR, which is not the best way to do it, I realize now.

Glad to see it’s already being addressed.

Thank you Donncha.

However, on low traffic websites like ours, such a short expiry time would mean that basically every page load would need to be generated by WordPress and not come from the cache, so the cache would be basically useless. And almost every page load would take 1-2 seconds, failing the Web Vitals.

I’m looking to cache pages for days, not minutes.

BTW, I ran into a frustrating bug that clears the whole cache when I visit the admin area. I’m currently trying to narrow down the exact cirumstances that cause this. I will create another topic when I know more.

Object Cache is different from the static files caching that WP Super Cache does. WordPress is suggesting to use both.

Popular Object Caching solutions include Redis and Memcached. If your hosting provider offers one or the other, definitely use that. It might require some configuration work.

On shared hosting solutions, those two are less common. I’ve had good experiences with SQLite Object Cache, which requires almost no configuration.

https://www.ads-software.com/plugins/sqlite-object-cache/

Note that if you use it on a low traffic website with already correct performances, you will not feel a huge boost in speed.

Then my problem may be specific to my testing environment (PHP 8.2.4 on MAMP PRO 6.8.1 on macOS 12.6.7). But I doubt it since I saw the same behaviour on my live environment (shared hosting on PHP 8.2.x).

I simply took a new WP installation in French without anything else, installed and enabled WP-Optimize and saw the fatal error on the Images configuration page.

To be honest I gave up on WP-Optimize because it was causing too much trouble for me. In addition to the fatal error, the cache preloading wasn’t preloading anything except for the sitemaps. I even experienced a 500 error on my live server while preloading (in addition to a JS error message).

• This reply was modified 1 year, 8 months ago by JackSim.

By the way, the same bug is present in another string:

#: includes/class-updraft-smush-task.php:293
msgid "The file was compressed from %s to %s saving %s percent using WP-Optimize"
msgstr "Le fichier a été compressé de %s à %s en réduisant de %s?% avec WP-Optimize"

The last % should be escaped with a double %%, or replaced with the words “pour cent” like in English.

In this one tough, it is done properly:

#: includes/class-updraft-smush-manager.php:157
msgid "The file was compressed from %s to %s, saving %s percent, using WP-Optimize"
msgstr "Le fichier a été compressé de %s à %s, en économisant %s?%% à l’aide de WP-Optimize"

Nope. I updated the translation, but I still have the same error:

[12-Jul-2023 14:02:11 UTC] PHP Fatal error:  Uncaught ArgumentCountError: 5 arguments are required, 4 given in /path/wp-content/plugins/wp-optimize/includes/class-updraft-smush-manager-commands.php:175

I noticed that the change in the translation wasn’t enough to fix the error: a space was removed from the string, but the % character is still not escaped correctly with a double %%.

The unsufficient change: https://www.dropbox.com/s/lmlo2634jfk5j9c/wpo-fr-bug.png?dl=0

The best approach would be the one I suggested: do like all of the other translators did (and the original English version does), use the word for “percent”, “pour cent” in French, instead of the problematic % character. Then the problem will be solved.

The shop is https://mix3d.ch/

I don’t have a server-side cache plugin installed (yet – working on it) and no other tracking code.

I did notice that the function that invoques the aforementioned script is called loadScriptAndCacheIt(). So is there an internal cache to your plugin that doesn’t get purged when the configuration is modified?

• This reply was modified 1 year, 8 months ago by JackSim.

I updated one of my sites to 3.2 from 3.1.4 (technical requirements met, not modded, the only plugins I have are Akismet and Google XML Sitemaps).

It seemed to update OK, I got the message at the end that confirmed the installation was successful, but when I reloaded the page (or any other page) it was stuck in maintenance mode. I had to manually delete the .maintenance file and now everything seems to be OK.

I would advise against upgrading for now. Wait for a revised version that cleans up properly after the update.

You must repair your MySQL tables. Log on your SQL server with PHPMyAdmin and repair all tables. That should do it.

Same problem here, and same fix ??

So the conclusion is, WordPress MUST alter your .htaccess file for a new page to work with a nice URI. It has to create a set of rule for it.

I’d like to see an updated French .po file too…

Does anybody care? ??

Ok, and a space is missing between the first = sign and $HTTP_GET_VARS.