Laurent OneChai

@donncha – Brilliant, this time, it works!
My homepage is not a static page, but it’s not either the classic index.php. It’s a custom front-page.php with it’s own WP_Query calls.
This time, in the log file at the end of the preloading, I’ve got this kind of stuff (I’ve changed the path, but you’ll get the meaning)

wp_cron_preload_cache: no more posts. scheduling next preload in 1430 minutes.
wp_cron_preload_cache: clean expired cache files older than 85800 seconds.
Cleaning expired cache files in /home/wp/wp-content/cache/
Doing GC on supercache dir: /home/wp/wp-content/cache/supercache
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/bloglist-et-liens/index-https.html
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/bloglist-et-liens/index-https.html.gz
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/test4/index-https.html
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/test4/index-https.html.gz
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/destinations/asie-centrale/kirghizstan/index-https.html
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/destinations/asie-centrale/kirghizstan/index-https.html.gz
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/destinations/asie-centrale/tadjikistan/index-https.html
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/destinations/asie-centrale/tadjikistan/index-https.html.gz
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/destinations/asie-centrale/index-https.html
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/destinations/asie-centrale/index-https.html.gz
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/destinations/asie-centrale/ouzbekistan/index-https.html
prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /home/wp/wp-content/cache/supercache/url.fr/destinations/asie-centrale/ouzbekistan/index-https.html.gz
gc: could not delete /home/wp/wp-content/cache/supercache/index.html as it's protected.
prune_super_cache: did not delete file: /home/wp/wp-content/cache/supercache/index.html
gc: could not delete /home/wp/wp-content/cache/supercache/index.html as it's protected.

The homepage is not preload, but it just doesn’t matter as far as I’m concern.
Thanks again.

Thanks Donncha, I just tried this dev version, but sadly, I still get the very same behaviour. Near the end of the preload, I get in the log file all those:

prune_super_cache:...
gc: deleted...

And so on.
And my cache directory is nearly empty at the end, containing only for few files generated after this GC.

I’ve reported this problem 5 months ago with a detailed log explaining as much as I could what’s going on. I tried again with the latest version today (1.6.2) and the issue is still the same.
All the cache is pre generated as it should and mysteriously deleted when the preload is almost finished.
Full description in my bug report here.
So I’m stuck with version 1.4.9, the latest version where preloading works as it should (in my case).

For the error 404 issue, after changing the setup back to “remove category”, go to WordPress permalinks settings and save the configuration (without actually changing any option).
This fixed the 404 errors for me.

OK, thanks.

Thanks a lot for the prompt anwser.
No worries, I was not asking for you to provide me the way to change the code in order to do that. I can try to figure it out myself.
I was just hoping that they would be a callback available somewhere that I could use in order to customize that from my theme functions.php file without having to edit the code of the Yoast plugin directly, which is always an issue whenever an updates comes along.

Ok thanks, I will.

Did you get around that by any chance ? I’m running into the very same problem. Preloading used to work like a charm (until version 1.4.9), but after updating to v 1.5.9, just before the end of the preloading, almost all the preloaded files are deleted. I get this in the debug log :

21:42:26 4005 /wp-cron.php?doing_wp_cron=[...] supercache dir: /home/[...]/wp-content/cache/supercache/[...]/
21:42:26 4005 /wp-cron.php?doing_wp_cron=[...] clear_post_supercache: deleting files in /home/[...]/wp-content/cache/supercache/[...]/
21:42:26 4005 /wp-cron.php?doing_wp_cron=[...] prune_super_cache: deleted /home/[...]/wp-content/cache/supercache/[...]/bloglist-et-liens/index-https.html
21:42:26 4005 /wp-cron.php?doing_wp_cron=[...] prune_super_cache: deleted /home/[...]/wp-content/cache/supercache/[...]/bloglist-et-liens/index-https.html.gz
21:42:26 4005 /wp-cron.php?doing_wp_cron=[...] gc: deleted /home/[...]/wp-content/cache/supercache/[...]/bloglist-et-liens, forced delete

I end up with only a few files preloaded in the cache, 4 files (always the same) that are preloaded after the gc clearing burst.

You need another plugin that can generate this kind of error popup. I have for instance the problem with WP-SpamShield. If you add the plugin and write a comment that is considered as being a spam.
To write a comment that is considered a spam, pretend that the email address of the person who writes this comment is for instance “[email protected]”. You’ll get a popup asking you to enter a valide email address at the Cookie Consent at the end.

Brilliant, thanks a million !
I actually tried to do that when I figured out the problem, but I got it wrong somehow (I don’t know how !), because it didn’t work at that time, but now it does.
I missed the fact that the content type was different when trying to figure out what was going on.
Thanks again.

I’ve got the very same issue. I see that you are also using WP Super Cache. In my case, when disabling WP Super Cache, the sitemap_index.xml works great again.

The XML is actually right and works for Google, this is just the rendering using the XML stylesheet that is broken.

One more thought on the subject. When lazyloading responsive images, why don’t your actually just replace the src=”” with the data-src=”” as you normally do without responsive images and just rename the attribute data-srcset into srcset and let the browser do the job of picking up the right image ?
The current solution has the added advantage to use responsive images even if the browser doesn’t support it, which is nice, but you’ve got to do all the maths. But that would be a lot more simple to handle.

I’ve got, I think the same problem. In the html, the field “og:description” is not the one I provided for my front page but the one of another page.
And if I delete this other page, Yoast picks up the description from yet another one, but never the one provided for the front page.
All the other og: fields are correct, but not og:description.
Looks like a bug to me…

Thanks for the anser, but I saw this page already. That’s where I got the information that the excerpt provided in the post had piority over the text until the “more” tag. But what I was wondering was whether I could, with a hook in my function.php, change this priority or not.

My undertsanding of this option is that it changes the behavior of the cache if a user access a given page while this page is being cached or something like that. So indeed, it should have an impact only for site with loads of visitors. This is not my case so I’m not too worried about that.
But you’re right Tommy78, this definitively looks like a bug that should be fixed. My suggestion is just a work around for the time being.