Mark (a11n)

Hi @richardsonchairmakers,

May I ask which page you loaded which spawned multiple requests to admin/admin-ajax.php?

The Jetpack Boost dashboard will make POST requests to your site while it’s open, if it is in the midst of requesting a fresh Speed Score, or while you are generating Critical CSS. When the Boost dashboard is idle, it may occasionally ping your site to refresh its data but not many time.

Jetpack Boost should not add any calls (especially to admin/admin-ajax.php) when users load your site’s main page, or when you view any other part of the Admin interface.

Hi @ztom,

Thanks for posting your logs. Picking through them, I can see two distinct requests – however, I can’t tell for sure which are done via quic and which isn’t.

Here’s request one:

14:10:20 2576691 / wpsc_is_caching_user_disabled: false
14:10:20 2576691 / wp_cache_get_cookies_values: return:
14:10:20 2576691 / supercache dir: ABSPATH/wp-content/cache/supercache/quictest.vtp.xyz/
14:10:20 2576691 / wp_cache_get_cookies_values: return:
14:10:20 2576691 / Fetched static page data from supercache file using PHP. File: ABSPATH/wp-content/cache/supercache/quictest.vtp.xyz/index-https.html

Here’s request two:

14:10:40 2576688 / wpsc_is_caching_user_disabled: false
14:10:40 2576688 / wp_cache_get_cookies_values: Login/postpass cookie detected
14:10:40 2576688 / wp_cache_get_cookies_values: return: 01abc8d22d19efafd85cb29185e23acc
14:10:40 2576688 / supercache dir: ABSPATH/wp-content/cache/supercache/quictest.vtp.xyz/
14:10:40 2576688 / wp_cache_get_cookies_values: cached: 01abc8d22d19efafd85cb29185e23acc
14:10:40 2576688 / Cookies found. Cannot serve a supercache file. 01abc8d22d19efafd85cb29185e23acc
14:10:40 2576688 / wp_cache_get_cookies_values: cached: 01abc8d22d19efafd85cb29185e23acc
14:10:40 2576688 / In WP Cache Phase 2
14:10:40 2576688 / Setting up WordPress actions
14:10:40 2576688 / Created output buffer
14:10:40 2576688 / wp_cache_get_cookies_values: cached: 01abc8d22d19efafd85cb29185e23acc
14:10:40 2576688 / wpsc_is_caching_user_disabled: false
14:10:40 2576688 / Output buffer callback
14:10:40 2576688 / wp_cache_get_cookies_values: cached: 01abc8d22d19efafd85cb29185e23acc
14:10:40 2576688 / wpsc_is_caching_user_disabled: false
14:10:40 2576688 / Writing non-gzipped buffer to wp-cache cache file.
14:10:40 2576688 / Renamed temp wp-cache file to ABSPATH/wp-content/cache/supercache/quictest.vtp.xyz/wp-cache-77cef4520ace7ab0dcd2b8ccb5143fca.php
14:10:40 2576688 / Sending buffer to browser
14:10:40 2576688 / wp_cache_shutdown_callback: collecting meta data.
14:10:40 2576688 / Writing meta file: ABSPATH/wp-content/cache/supercache/quictest.vtp.xyz/meta-wp-cache-77cef4520ace7ab0dcd2b8ccb5143fca.php

Looking at the logs, one case is logged in and the other is not. This would normally account for a difference in what is or isn’t cached. Was one of these loaded when logged in, and the other in “incognito” mode?

I recommend testing with both quic and without quic in “incognito mode” to ensure that login cookies don’t play a role in the results you see.

Hi @dimalifragis,

Thanks for your reports. First, I can assure you that PHP 8, WordPress 6.1, and FastCGI shouldn’t be a problem here; I have tested with all of these environments.

I also tried disabling garbage collection (setting Cache Timeout to 0), even though my understanding is that in preload mode this setting should be irrelevant. This seems to have no effect.

I agree that Garbage Collection shouldn’t have an effect on this, however @bruceallen suggested it as we recently had another forum user report that having GC set to anything other than 0 was deleting their Super Cache files for reasons we haven’t yet tracked down.

Thank you both for checking and reporting on this setting, we can rule this out as a factor in your cases.

In order to track down what is happening, would you mind trying out DEBUG mode and triggering a Preload?

We have instructions for enabling DEBUG mode here: https://github.com/Automattic/wp-super-cache/wiki/How-to-enable-debug-mode

Set your preload time to 0 to turn off automatic refreshing, and then click the “Preload Now” button. Give it a few minutes, then check out the DEBUG log for information.

It should look something like this:

wp_cron_preload_cache: got 100 posts from position 0.
supercache dir: /home/test-user/example.com/subdir/wp-content/cache/supercache/example.com/subdir/sample-page/
wp_cron_preload_cache: fetched https://example.com/subdir/sample-page/
supercache dir: /home/test-user/example.com/subdir/wp-content/cache/supercache/example.com/subdir/2023/03/06/hello-world/
wp_cron_preload_cache: fetched https://example.com/subdir/2023/03/06/hello-world/
wpsc_delete_files: deleting /home/test-user/example.com/subdir/wp-content/cache/supercache/example.com/subdir/
wpsc_get_realpath: directory does not exist - /home/test-user/example.com/subdir/wp-content/cache/blogs/
wpsc_delete_files: reading files: ..
wpsc_delete_files: reading files: sample-page
wpsc_delete_files: reading files: 2023
wpsc_delete_files: reading files: .
wpsc_delete_files: remove directory /home/test-user/example.com/subdir/wp-content/cache/supercache/example.com/subdir/

Take a look at the pages it’s fetching – make sure it appears to be fetching all of the posts you expect to be preloaded, and check that there are no lines indicating files are being deleted (note: “remove directory” just indicates it will be removed _if empty_ and is not something to be worried about).

If you’d like help interpreting your debug mode output, please feel free to send it to me – but please be sure to edit out any private information you do not want to post on this forum (e.g.: URLs, private directory names, etc).

Hi @ztom,

Thanks for the link to your site site and some of your logs.

I’ve taken a look at your test site, and have noticed some interesting errors at the top of the page when fetched via quic:

Warning: Undefined array key “host” in /www/wwwroot/quictest.vtp.xyz/wp-includes/canonical.php on line 689

That suggests that your web server (nginx/quic) isn’t properly reporting your hostname / URL to PHP when it’s running WordPress – which may explain why WP Super Cache is unable to cache pages properly.

I’ve also examined your log – unfortunately, there isn’t quite enough there to illuminate exactly what’s going wrong here.

wp_cache_get_cookies_values: cached: f4826c90d614770daaab87cd4b05dcc9

The first line appears to be cut off – but it appears to see that you have a login cookie present.

What happens if you try to access your site in “incognito mode”, with no login cookies present? Do the DEBUG logs still show a line like the above with a hex value? If so, it may be possible that nginx is adding a cookie to your requests, though that would be strange.

Would it be possible to generate a longer DEBUG log dump, including:

• Loading a page in incognito mode / with no login cookie, twice
• Loading your frontpage when logged into your WordPress site, and finally
• Loading your frontpage with quic disabled in your browser, so that I can see the difference?

Thanks for bearing with us while we try to get to the bottom of this; this is a new and strange problem from my perspective.

Hi @enmuci

Thanks for your response. It’s strange behaviour. I hope you don’t mind, but I have more questions about your setup to help us get to the bottom of this:

1. Do you have “Extra homepage checks” enabled on the Advanced tab?

2. Do you have “Preload mode” turned on on the “Preload” tab, and if so what Refresh setting do you have?

3. To help us get to the bottom of the issue, would you mind turning on Debug Mode, then try to “catch it” either deleting or failing to read your homepage cache files. You can find instructions for Debug Mode here: https://github.com/Automattic/wp-super-cache/wiki/How-to-enable-debug-mode . In debug mode, WP Super Cache writes about what it is doing to a file on your server. If you send us Debug logs, please be sure to remove any private information from them before posting them here, such as your site’s URL if you do not want it listed in the forums.

4. Alternately, it might be worth turning on the “Email me when the garbage collection runs.” setting on the Advanced tab. If you don’t get an email when your home page requires re-caching in the future, it will at least rule out the garbage collector running when it shouldn’t.

Thanks for bearing with us while we try to work this out with you

Hi @ztom,

That’s strange. I don’t have direct experience with nginx-quic, but I don’t know of any reason why it would affect WP Super Cache. I have a few questions to understand more about what you’re seeing, and your setup:

• You mention that WP Super Cache is not enabled when using http3-quic. Do you mean that it appears deactivated in the wp-admin interface when viewed through http3, or are you checking for the HTML comments that WP Super Cache adds to your page footer for confirmation?
• Is the same nginx service also serving HTTP/2 pages when accessed over that protocol?
• What “Cache Restrictions” setting do you have enabled in the Advanced settings of WP Super Cache? I wonder if there is a difference in the cookies / auth token between HTTP/2 and 3.

Finally, would you be willing to enable debug mode to capture some debug logs while viewing your site via http3? There may be details in there, such as a message about why WP Super Cache is not serving cached versions of certain pages. We have instructions for Debug mode here: https://github.com/Automattic/wp-super-cache/wiki/How-to-enable-debug-mode

If you’d like our help interpreting your debug logs, feel free to post them here – but please make sure they don’t contain any private information such as your site’s URL or any relevant user details before posting them.

Hi @enmuci,

Thanks for writing in, and for sending in a full stack trace. That helped me understand where the problem is pretty quickly.

Based on the stack trace, I think the issue is to do with the date of your next scheduled wp_cache_gc task – that is, your next “Garbage collection” run.

I suspect the date scheduled for that in your database is somehow corrupt (or so far into the future that WordPress’ internationalization-friendly date formatter can’t cope with it).

To solve the issue, can I please ask you to install a plugin which lets you delete scheduled events, such as Advanced Cron Manager and use it to delete the next scheduled wp_cache_gc task. Hopefully by doing that, we can clear out the issue and get things moving again.