Great work. Question about wp-super-cache conf for Nginx

[pkiula]

This is about this file. Many thanks for sharing this! -- https://github.com/pothi/wordpress-nginx/blob/master/globals/wp-super-cache.conf

I can figure out from it what the 418 and 419 mean. We do it with the 'skip_cache' version found in some forums online. Same thing.

Question: the @mobileaccess directive has:

/wp-content/cache/supercache/$host${uri}index$https_suffix-mobile.html

What's the "suffix-mobile"? Our theme is completely responsive. Same pages and URLs get served to all devices. Is this still relevant to us?

Thanks.

[pothi]

Thank you for your time to test the configuration in this repo.

WP Super Cache creates mobile version of the cache for the home page at wp-content/cache/supercache/example.com/index-mobile.html (for non-https sites) or at /wp-content/cache/supercache/example.com/index-https-mobile.html (for HTTPS sites). So, in /wp-content/cache/supercache/$host${uri}index$https_suffix-mobile.html, the following are variables...

1. $host
2. $uri
3. $https_suffix

https_suffix is defined at https://github.com/pothi/wordpress-nginx/blob/master/conf.d/common.conf#L35-L36 . It is used by WP Rocket plugin as well. So, it is defined in a common place to avoid duplication in code. So, suffix-mobile doesn't mean anything. It is actually https_suffix that has a meaning in the above code.

Our theme is completely responsive. Same pages and URLs get served to all devices. Is this still relevant to us?

No, not relevant to your theme. 99% of sites don't use a separate mobile cache. That's why the mobile cache is not enabled by default. Just updated the inline documentation to reflect this point. Please see https://github.com/pothi/wordpress-nginx/blob/master/globals/wp-super-cache.conf#L37-L42 .

[pkiula]

Super, thank you Pothi. What a valuable contribution to the community. Much appreciated!

[pkiula]

Quick additional question. I'm not seeing the X-Cache header at all. Reference to this:

try_files "/wp-content/cache/supercache/$host${uri}index-https.html" $uri $uri/ /index.php$is_args$args;

    #--> all the following would apply, only if the request hits the cache

    add_header "X-Cache" "HIT - WP Super Cache";

Any ideas on how to diagnose why Nginx is not picking up the cached file? Looking manually at the folders on our server, the files do exist. I can also query the files with the path name manually typed in browser for the supercache path. Note that the https is hardcoded in our case, because we only have forced https. No http version of the site.

Welcome any thoughts!

[pothi]

Best way to debug is to enable debug log in Nginx and run a single request to diagnose further. Please see https://nginx.org/en/docs/debugging_log.html#clients under the header "Debugging log for selected clients" to debug selected clients.

From what I can guess, the cached content may be located at /cms/wp-content/cache/supercache/$host${uri}index-https.html in your particular installation.

[pkiula]

Thank you. This is very helpful. Unfortunately our Nginx is not compiled with --with-debug capability. You're right, we should have the /cms/ at the front. Even with that though it doesn't seem to be bringing the super-cache page. Hmm..