Mark (a11n)

Hi @dimalifragis – just following up to let you know that we released Super Cache 1.9.3, which includes a fix for this issue. Now, when it updates your wp-config.php file it is careful to maintain the same file permissions on it.

Hi @nonverbla – I just wanted to let you know that we released Super Cache 1.9.3, which now includes these options. You can see the documentation for it in the wiki.

Hi @nonverbla,

Just a quick update to let you know that our fix is still on its way.

I’m aiming to make ExpiresByType automatically set by max-age= Cache-control rules, and add the ability to override headers and expiry rules in the htaccess file via filters.

If you’re curious to see a preview, take a look at the PR. There’s even an example in there for adding custom Accept-ranges headers ??

• This reply was modified 1 year, 11 months ago by Mark (a11n).

Thanks for submitting a patch @nonverbla — it was really appreciated that you took the time to work through the submission process, and explain the context and your goals to us.

I’ve described a way you can control your Accept Ranges header without the need to modify WP Super Cache here: https://github.com/Automattic/jetpack/pull/27748#issuecomment-1352656727

I hope it helps! ??

Hi @lampir,

I currently have the following settings for the Preload:
Refresh preloaded cache files every 120 minutes.
Preload all posts.
Preload mode.

This would mean that it preloads everything every 120 minutes or?

That’s correct; those settings will ask WP Super Cache to preload everything every 120 minutes.

What is the purpose of the Expiry Time & Garbage Collection in the Advanced tab then?
There I have a Cache Timeout for 1800 seconds and a Scheluder with Timer for 600 Seconds.

Cache timeout and preloading on a timer are two different, but related ways of managing cached content.

When you preload your cache, your site attempts to generate HTML content for your whole site in advance, before visitors arrive. That way from the moment your first visitor arrives, they are served pre-made HTML extremely quickly.

If you preload your site every few hours, then fresh HTML is generated every few hours ready for visitors to arrive.

However, when you cache your site without preloading, each page is generated the first time a visitor loads it, so that future visitors have a faster experience. “Cache timeout” means that cached files which become too old are not reused – forcing the next visitor-load to regenerate the page.

I’ve tried to set in Preload the refresh preload to 0, manually refresh the files which I did, but then tomorrow when looking at Contents, no files were there except the main page.

That sounds like your preloaded files timed out after the configured 1800 seconds, but it did not schedule a new preload cycle as that was set to 0 (which means don’t periodically preload).

As I sad, maybe a full preload with a periodical scanning of changes would be the best for me, but I am not sure how to achieve that.
I hope I made it clear, so any tips on how to get that would be appreciated.

Based on your description, I recommend turning on Preload, and setting the “Refresh preloaded cache files” setting to a high value like 1440 seconds.

That will cause your preloaded cache to refresh once per day. That doesn’t prevent you from additionally visiting the WP Super Cache settings page and clicking the “Preload Now” button after you make a change to ensure that your preload gets refreshed immediately – but it will ensure that if you forget to hit the button, your site will be updated within a day.

Hi @vaka2vaka,

That’s very strange.

During the 1.9.2 release, it was accidentally tagged as a “beta”, then quickly corrected to remove that tag. I can only speculate that it confused your WordPress update process. Apologies for that.

I’m glad it’s all sorted, though.

Hi @nonverbla,

Thanks for writing in. It does appear that you’re right; the ExpiresByType value is hard-coded, while the Cache-Control heading can be freely modified by advanced users.

We’re having a quick internal debate about how best to handle this, but we’ll explore a fix for this in a future version of WP Super Cache.

I’ll let you know once we have a better answer for you.

Hi @niclasto,

I’ve examined your site, and have noticed a few things which are slowing down your first-use experience.

Super Cache is great at making WordPress itself run fast (by bypassing most of its internals) while rendering your page. However, it appears the slow-down is in the way that your site serves static resources. These are things like JavaScript files and CSS Files, which are loaded directly after WordPress has finished running.

First, I have noticed that your site does not support gzip compression. When loading static assets on your website (such as JavaScript files), they are not being served compressed.

Here are some example resources which are not compressed:

– wp-includes/css/dist/block-library/style.min.css?ver=6.1.1
– wp-content/plugins/stackable-ultimate-gutenberg-blocks/dist/deprecated/frontend_blocks_deprecated_v2.css?ver=3.6.2
– wp-content/plugins/tabs-responsive/assets/css/animate.css?ver=6.1.1

It appears your site is running on an Apache web server. I recommend that you contact your hosting provider, and ask them to set up mod_deflate on your server to enable compression for your static resources.

Second, I have noticed that your site appears to take a long time to serve static resources when multiple are requested simultaneously. For example, during a normal page-load:

– wp-content/plugins/wpglobus/includes/js/wpglobus.min.js takes 1.5 seconds to load,
– wp-content/plugins/q2w3-fixed-widget/js/frontend.min.js takes 1.09 seconds to load, and
– wp-content/plugins/ajax-search-lite/js/min/plugin/optimized/asl-wrapper.js takes 1.49 seconds to load

However, when I load any of these URLs individually, they load rapidly. To illustrate what I mean, I will focus on “wp-includes/js/utils.min.js”:

– During a regular page-load, this resource takes 1.57 seconds to load; 961ms of which are spent “waiting for server response”.
– When I load this resource individually, it only takes 457 milliseconds to complete.

This suggests that your web server may be either mis-configured, or running on a system which does not have enough resources to properly support its operation.

I recommend that you also ask your web hosting provider about your web server setup, and why it is taking a long time to serve static resources during a normal page load.

Hi @itsgotime,

It depends on how your affiliate links work, exactly. If affiliate links are assigned by JavaScript that is activated when you click the link, they will be unaffected by Super Cache.

However, if your site loads a special “redirection” page to send visitors to the correct affiliate destination, then you may need to consider how it will interact with your Super Cache options.

You can get around this issue by using the “Rejected URL Strings” setting in the “Advanced” tab of the WP Super Cache settings. If you add your affiliate “redirect” URL to that setting, then it will not be cached, and your affiliate links will be unaffected.

I hope that helps. If you need further help, please let us know more about how the affiliate links work so that we can give you more specific guidance.

Hi @helani,

I’ve had a look, and I can confirm that your front page does not appear to be cached.

Can you visit your WP Super Cache settings (under Settings -> WP Super Cache in your WordPress admin dashboard), and ensure that caching is turned on?

It is not on by default, and your site will not be cached until you turn it on.

Great! I’m glad it’s all sorted.

Thanks for letting me know!

Hi @m_uysl,

We have released Jetpack Boost 1.5.4 which contains a bugfix for this issue. Please upgrade, try it again, and let us know if you run into any further problems.

Hi @adorablepaws,

I think the issue is in the last two lines:

store_notice[notice
id]

It looks like it’s supposed to search for “store_notice[noticeid]” in your cookies. If you change that to “store_notice\[noticeid\]” (all on one line), it should resolve the issue.

Be sure to include that backslashes \, as it will tell Super Cache that you want to match with an exact “[” character, and it won’t get it confused with a Regular Expression control character.

• This reply was modified 2 years ago by Mark (a11n).
• This reply was modified 2 years ago by Mark (a11n).

Hi @chillmen,

Thanks for reporting the issue.

I’ve just tested Twenty Twenty-three using the settings you listed, and I can’t replicate the issue. That suggests there is something else going on here that we haven’t identified yet.

When your site shows a blank screen, can you check the page source to see if it’s empty? To view the source, add “view-source:” before the site URL in the location bar of your browser. If the page source is empty, it might tell us something about what is breaking.

Additionally, can you try enabling “Debug Mode” in Super Cache, to check if there’s an error in your debug log? There are instructions for Debug Mode here: https://github.com/Automattic/wp-super-cache/wiki/How-to-enable-debug-mode

If you’d like help understanding your debug logs, please be sure to remove any private information (e.g.: any URLs which are private) before posting any samples from your debug log here.

Hi @adorablepaws,

Thanks for the issue report.

Line 1748 in wp-cache-phase2.php is where Super Cache applies the “Rejected Cookies” setting from the “Advanced” tab in your Super Cache settings. Each line in that setting is treated as a Regular Expression, so if you have a stray “[” character in there it might get confused.

Can you please check your Rejected Cookies setting, and make sure there are no square brackets or other special characters included?

If you need help sorting out a complex Rejected Cookie setting using a Regular Expression, please let me know what settings you are aiming for and I can guide you on how to set it up.