The debug tab is a useful tool to find out why the cache isn’t behaving the way you expect it to.
You can activate the debug mode by going to the advanced tab and clicking “Enable Logging”.
Important: Don’t forget to deactivate the logging mode as soon as you don’t need it anymore. Logging uses server resources, which may cause issues on some servers. The logs — while password protected — also contain potentially sensitive data.
And then login to the debugging dashboard:
After you log in, you should see a screen that looks something like this:
Warning! Do not copy and paste this log file to a public website! It contains potentially sensitive information about your web server.
Reading the Debug Log
The log file will keep track of the decisions it makes for every request while it’s active. The following examples will help explain some of what you can find out by examining the Debug Log.
Verifying WP Super Cache is Working Correctly
In the following code — taken from the screenshot above — we can see that visiting the page testington resulted in WP Super Cache serving the request:
12:46:39 90601 /2022/10/21/testington/ wp_cache_get_cookies_values: return:
12:46:39 90601 /2022/10/21/testington/ supercache dir: ABSPATH/wp-content/cache/supercache/supercache.test/2022/10/21/testington/
12:46:39 90601 /2022/10/21/testington/ wp_cache_get_cookies_values: return:
12:46:39 90601 /2022/10/21/testington/ Fetched static page data from supercache file using PHP. File: ABSPATH/wp-content/cache/supercache/supercache.test/2022/10/21/testington/index.html
2022/10/21/testington/index.html was served when the /2022/10/21/testington/ page was requested. The index.html file is a static file, which isn’t the PHP file that WordPress usually shows. Showing the static file will be faster and is the desired behavior.
Confirming that Preloading is Working
Example Debug Log:
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/
This log was generated by setting the preload time to 0 to turn off automatic refreshing, and then clicking the “Preload Now” button. After a few minutes, the log generated the code shared above.
To verify that preloading is working, you will want to make sure that all the pages you expected to be preloaded are referred to in the log and that there are no lines indicating files are being deleted (note: remove directory just indicates it will be removed if it is empty and is not something to be worried about).
Caching Disabled for Logged In Users
Example Debug Log:
10:35:40 2943444 /favicon.ico wpsc_get_auth_cookies: cookies detected: wordpress_logged_in_xxxxxx
10:35:40 2943444 /favicon.ico wpsc_is_caching_user_disabled: true because logged in
10:35:40 2943444 /favicon.ico Caching disabled for logged in users on settings page.
10:35:40 2943444 /favicon.ico wp_cache_get_cookies_values: Login/postpass cookie detected
In this situation, WP Super Cache isn’t caching because the user is logged in. The Debug Log is alerting us to this on lines 2 and 3, in particular line 3 which gives the solution: Caching disabled for logged in users on settings page. To fix this, you would need to enable caching for logged in users in WP Super Cache’s settings.
Not Caching Due to POST Request
Example Debug Log:
07:47:04 3675 /wp-admin/admin-ajax.php Not caching wp-admin requests.
07:47:09 26206 / wpsc_get_auth_cookies: no auth cookies detected
07:47:09 26206 / wpsc_is_caching_user_disabled: false
07:47:09 26206 / wp_cache_get_cookies_values: return:
07:47:09 26206 / supercache dir: ABSPATH/wp-content/cache/supercache/example.com/
07:47:09 26206 / No Super Cache file found for current URL: ABSPATH/wp-content/cache/supercache/example.com/index-https.html
07:47:09 26206 / wp_cache_get_cookies_values: return:
07:47:09 26206 / In WP Cache Phase 2
07:47:09 26206 / Setting up WordPress actions
07:47:09 26206 / Created output buffer
07:47:09 26206 / wp_cache_get_cookies_values: return:
07:47:09 26206 / wpcache_do_rebuild: doing rebuild for ABSPATH/wp-content/cache/supercache/example.com/
07:47:10 26206 / Not caching POST request.
07:47:10 26206 / wp_cache_maybe_dynamic: returned $buffer
Looking at the Debug Log, WP Supercache isn’t caching the homepage as shown here: 07:47:10 26206 / Not caching POST request. This is happening because another plugin or theme is populating the _POST array, leading WP Super Cache to think the page has a POST request and isn’t caching it. The solution would be to check for a plugin or theme conflict.
Getting Help
If you need assistance interpreting the debug log, start by searching the WP Super Cache forums on WordPress.org. There is likely a past thread that can help explain what you are seeing.
Jetpack 