Mark (a11n)

Hi @teresacuervo,

Thanks for writing in.

While I can’t really offer specific support for WordFence, to the best of my knowledge WP Super Cache and WordFence work alongside each other. I certainly haven’t seen any reports of a compatibility issue there.

If you run into any trouble, let us know!

Hi @dimalifragis,

Thanks for writing in with this observation.

WP Super Cache automatically adds a couple of constants to your wp-config.php file to allow it to manage your cache before WordPress has been fully loaded. It also cleans up after itself by removing those constants when you deactivate the plugin.

When updating your wp-config.php file, Super Cache is very careful never to leave your config file in a half-written state, so if something goes wrong it will not break your site.

It updates your wp-config file by creating a copy with the necessary changes, then it renames the file to switch you to the updated configuration. In doing this, it appears to have modified your file permissions.

I have filed an issue for us to investigate a fix for this in a future release of WP Super Cache here: https://github.com/Automattic/jetpack/issues/27324

Hi @morpheus83,

By default, WP Super Cache writes your cached content to “wp-content/cache/”, not “wp-uploads”.

Can you please check your “Cache Location” setting under the “Advanced” tab in Settings > WP Super Cache? If that is set to the default (ends with “wp-content/cache”), then it is unlikely that WP Super Cache has created these additional pages.

These paths also don’t look like the cache files that WP Super Cache generates. Those typically have your domain name repeated in the path, for example: “wp-content/cache/supercache/example.com/index-https.html”.

I would recommend that you review your installed plugins and check the settings for each one.

Hi @openrange,

In most cases, it’s better to run only one caching solution at a time. Generally running multiple caching solutions won’t make your site faster, and may cause compatibility issues across different solutions.

Which other caching plugin are you using, and what settings are you trying to apply?

Hi again @redsector72,

Thanks! I guess you have done more debugging already 🙂

> So I can’t understand why GC runs in preload, just after preload, plus I’ve checked and the file it complains is not able to delete, exist and has just been created. Maybe sometime it is able to delete it, wasting the creation of the preload.

The Garbage Collector is designed to be “safe” to run at any time – and runs both in wp_cron, and regularly at other points throughout WP Super Cache.

prune_super_cache: did not delete file as it wasn't a directory or file and not forced to delete new file: /us/News/wp-content/cache/supercache/www.tld.com/us/news/somedir/index-https.html.gz

You’re right; this is a new file that it has decided not to delete. It’s clearly just been created in the preload, and is not expired.

In theory, this shouldn’t be a problem — unless:

> Time. I can’t understand why do you log time in UTC time, but my server is not using UTC time anywhere. My files date/time is not UTC, so maybe you’re not converting files local time to UTC when doing GC?

This is an interesting theory. Timezones are always “fun”.

The timestamps shown in your debug log are generating using PHP’s own time functions, with no explicit conversion to UTC. That suggests that your PHP settings are configured to use UTC, despite your server generally running on a different timezone.

However, WP Super Cache relies on filemtime() to read the time files were last updated, and time() to get the current time. Both are equally affected by PHP’s timezone setting, so they should (in theory) match.

But there are a million different ways to setup a server, and I can’t rule this idea out. If we can identify which code-path in WP Super Cache is deleting these files, we can dig in further to find out more.

Have you seen any delete logs in your debug log? They would generally look line one of these:

wp_cache_phase2_clean_expired: Deleting obsolete wpcache cache+meta files: [filename]
Deleting wp-cache file: [filename]
Deleting supercache file: [filename]
Deleting [filename], older than [time] seconds

Finding these would help us identify which path the files are being deleted on; there are a few ways files can be deleted in WP Super Cache.

Hi @vdn-staff,

There is no official support for this. May I ask what the use-case is? Do you want to hide it from specific users?

Right now, the Delete Cache button is only shown for users with the “delete_others_posts” permission. You could use that to control who can and cannot see the button.

If you would like to just hide the button for cosmetic reasons, you could do so using some custom CSS:

#wp-admin-bar-delete-cache {
  display: none;
}

However, this will not prevent advanced users from removing the custom CSS and accessing the button.

Hi @dickraney

Thanks for running the test for me! Looking at your logs, I can see a bunch of activity in wp-admin which we can disregard. The first non-wp-admin load in your logs is:

14:12:14 11016 / wpsc_is_caching_user_disabled: false
14:12:14 11016 / wp_cache_get_cookies_values: return: 
14:12:14 11016 / supercache dir: /var/www/vhosts/mydomain.com/httpdocs/wp-content/cache/supercache/www.mydomain.com/
14:12:14 11016 / wp-cache file exists: /var/www/vhosts/mydomain.com/httpdocs/wp-content/cache/supercache/www.mydomain.com/wp-cache-b78f00e0bf0882a258c2b125d46e642b.php
14:12:14 11016 / Serving wp-cache static file
14:12:14 11016 / Getting legacy cache file /var/www/vhosts/mydomain.com/httpdocs/wp-content/cache/supercache/www.mydomain.com/wp-cache-b78f00e0bf0882a258c2b125d46e642b.php
14:12:14 11016 / exit request

That is rendering a cached file. That means that your cache is either not clearing correctly, or is being regenerated very quickly after you clear it.

Can you please delete your cache once more, and check if there are any files under wp-content/cache/supercache/ on your site. If so, check their permissions to make sure that WordPress can delete them.

It may also be worth deleting the contents of the wp-content/cache/supercache/ directory manually (via your web hosting dashboard or FTP program) to force these “stuck” files out.

Hi @insomnia88,

I’m afraid WP Super Cache focuses on the pages and posts that WordPress knows about, at their permalink URLs.

If you want to preload extra posts, you will need to use an external tool. You shouldn’t need a full headless browser; a tool like cURL should be able to trigger an appropriate HTTP request to preload any additional pages / URLs you would like.