swcfpc query string missing on backend?

Resolved

(@wpwebdevj)

Hello,

I am testing this plugin and so far the results are amazing, I can’t believe this is even possible. Just had a few questions.

Test site: https://cachetest.anon4.com

1. I am not seeing the swcfpc query string on most pages of the backend. Sometimes it is there but usually not. I noticed that if I click on the “CF Cache” link on the top toolbar of the admin area then it does add the query string as below.

https://cachetest.anon4.com/wp-admin/options-general.php?page=wp-cloudflare-super-page-cache-index&swcfpc=1

But if I click on the link in Settings > WP Cloudflare Super Cache then I don’t get the query string, as below.

https://cachetest.anon4.com/wp-admin/options-general.php?page=wp-cloudflare-super-page-cache-index

Most other areas of the backend admin do not have the string although it seems to appear randomly sometimes in various places. I can’t seem to find a pattern.

I’m not sure whether is normal or not?

2. When I view the front end site https://cachetest.anon4.com in a browser that is logged in as admin, I am only seeing the admin toolbar if the page is not already in the Cloudflare cache. Once I load the page in an incognito window so it gets cached, then I go back to main browser as a logged in admin and the admin toolbar is now gone because the page is getting served from Cloudflare cache now.

If I click the “visit site” link from the wp-admin backend then it will add the query string and I will always see the toolbar. But if I just access the front end directly by entering the URL then I will only see the toolbar if the page hasn’t been cached yet.

After I purge cache and load the homepage or a specific page in a browser that is logged in as admin, these are the headers I am getting.

alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400
cache-control: no-store, no-cache, must-revalidate, max-age=0
cf-cache-status: BYPASS
cf-ray: 6741fa154f92f4a6-YVR
content-encoding: br
content-type: text/html; charset=UTF-8
date: Sun, 25 Jul 2021 02:32:17 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Sun, 25 Jul 2021 02:32:17 GMT
link: <https://cachetest.anon4.com/wp-json/>; rel="https://api.w.org/"
nel: {"report_to":"cf-nel","max_age":604800}
pragma: no-cache
referrer-policy: no-referrer-when-downgrade
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=jaEuejHPgI0%2FYhQI6x7iFNxHzeeIQKx2TQwqJ6K1Kr4xQXXemeLTa%2FKQ9rzZY%2FKIRkgplkRrPSmrjqdDod8NNbCGHCaXcBtW0CmA52nqEyszJL1xJhkG9PnvsUR%2Bp%2FbRKJSdhrIj"}],"group":"cf-nel","max_age":604800}
server: cloudflare
strict-transport-security: max-age=31536000
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-wp-cf-super-cache: no-cache
x-wp-cf-super-cache-cache-control: no-store, no-cache, must-revalidate, max-age=0
x-xss-protection: 1; mode=block

But once I have loaded the page in an incognito window, then these are the reponse headers when I refresh the page in the logged in browser (this is when the admin bar disappears).

age: 20
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400
cache-control: s-maxage=31536000, max-age=60
cf-cache-status: HIT
cf-ray: 6742045c08dd137a-YVR
content-encoding: br
content-type: text/html; charset=UTF-8
date: Sun, 25 Jul 2021 02:39:18 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
link: <https://cachetest.anon4.com/wp-json/>; rel="https://api.w.org/"
nel: {"report_to":"cf-nel","max_age":604800}
referrer-policy: no-referrer-when-downgrade
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=gQM0XmCrhZPMxQtLcmK43RAWv1JQ0Fc1ZSEXlXhG9bNl0Kdtwr6ImlsUj57sy68YdO1bAsWuC7EsXDR8TL%2BLK%2BeGOe1w%2Fghr4yBPSKyJ0kV6JTCVyYmD7j160QgSY2RjJZQ2Q5ZL"}],"group":"cf-nel","max_age":604800}
server: cloudflare
strict-transport-security: max-age=31536000
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-wp-cf-super-cache: cache
x-wp-cf-super-cache-active: 1
x-wp-cf-super-cache-cache-control: s-maxage=31536000, max-age=60
x-wp-cf-super-cache-cookies-bypass: swfpc-feature-not-enabled
x-xss-protection: 1; mode=block

Again, I’m not sure if this is the normal behavior or not.

I am on a self hosted server running NGINX. I noticed that many of the options for this plugin say that this code needs to be added for those options to work.

location ~* \.(xml|xsl)$ { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location /robots.txt { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location /wp-cron.php { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location = /wp-content/wp-cloudflare-super-page-cache/cachetest.anon4.com/debug.log { access_log off; deny all; }

Although I didn’t change any options, I added those rules to my custom NGINX config anyway. I am kind of confused about how these 4 rules can be exactly the same no matter which options you are trying to enable. How do these 4 rules relate to all of those different settings for the plugin?

The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)

Plugin Contributor iSaumya
(@isaumya)

4 years, 10 months ago

I am not seeing the swcfpc query string on most pages of the backend. Sometimes it is there but usually not. I noticed that if I click on the “CF Cache” link on the top toolbar of the admin area then it does add the query string as below.

– Don’t worry about that. The Backend is always bypassed from cache. The query parater is mostly important and when it gets added is when you check the front end of the website while being loggedin. As at that time without that query parameter (unless you are using the worker mode) you won’t see the cache bypassed version of the page.

When I view the front end site https://cachetest.anon4.com in a browser that is logged in as admin, I am only seeing the admin toolbar if the page is not already in the Cloudflare cache. Once I load the page in an incognito window so it gets cached, then I go back to main browser as a logged in admin and the admin toolbar is now gone because the page is getting served from Cloudflare cache now.

– When you are logged in the best way to open the page is by click on the Visit Site link inside the dashboard or and preview page link inside the editor as in that case the query parameter is automatically added at the end of the link. But if you are manually entering the URL without the query parameter, then you will not see the bypassed cache version. Screenshot: https://i.imgur.com/GZWNAA6.png

If you want to get rid of the query parameter all together then you need to use the worker mode as in the worker mode there is no query parameter involved.

I am kind of confused about how these 4 rules can be exactly the same no matter which options you are trying to enable. How do these 4 rules relate to all of those different settings for the plugin?

– The 4 rules will remain exactly same no matter which option you select as those rules are about making sure that the XML, xsl, robots.txt, wp-cron.php files are never gets cached by Cloudflare.

Also the last rule is about making rule the plugin’s debug.log file cacnnot be directly accessed in public internet.

I will also recommend you to enable the Add browser caching rules for static assets option under the Cache Tab inside the plugin settings and once you enable it the plugin will show you a few nginx rules for better static files caching and you can add those rules to your nginx config as well.
Thread Starter wpwebdevj
(@wpwebdevj)

4 years, 10 months ago
Thanks for your explanation. Good to know that what I am seeing is normal.

I understand what those 4 NGINX rules do, I was just confused about how those 4 rules related to some of the settings of the plugin. I didn’t realize that the list of rules in that link changed after updating settings.

I will also recommend you to enable the Add browser caching rules for static assets option under the Cache Tab inside the plugin settings and once you enable it the plugin will show you a few nginx rules for better static files caching and you can add those rules to your nginx config as well.

When I enable browser caching, I see that you are recommending these cache-control headers for static assets.
```
location ~* \.(css|js|pdf)$ { add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=2592000, stale-while-revalidate=86400, stale-if-error=604800"; expires 30d; }
location ~* \.(jpg|jpeg|png|gif|ico|eot|swf|svg|webp|avif|ttf|otf|woff|woff2|ogg|mp4|mpeg|avi|mkv|webm|mp3)$ { add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=31536000, stale-while-revalidate=86400, stale-if-error=604800"; expires 365d; }
```
It appears these rules are not only for browser caching (cache-control: public, …)?

Currently I am using cache-control: max-age=315360000 for all static assets. Why do you recommend only 30d for css and js?

If I want to keep my current browser cache settings, should I still add the “public” part of these rules, as below.
```
location ~* \.(css|js|pdf)$ { add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=2592000, stale-while-revalidate=86400, stale-if-error=604800";}
location ~* \.(jpg|jpeg|png|gif|ico|eot|swf|svg|webp|avif|ttf|otf|woff|woff2|ogg|mp4|mpeg|avi|mkv|webm|mp3)$ { add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=31536000, stale-while-revalidate=86400, stale-if-error=604800";}
```
Doesn’t Cloudflare ignore these headers anyway when you are using the cache everything page rule?
Thread Starter wpwebdevj
(@wpwebdevj)

4 years, 10 months ago
I think there is something not quite right with some of the NGINX rules (the basic 4 with default settings).
```
location ~* \.(xml|xsl)$ { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location /robots.txt { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location /wp-cron.php { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location = /wp-content/wp-cloudflare-super-page-cache/cachetest.anon4.com/debug.log { access_log off; deny all; }
```
The location /robots.txt block never matches because I already have another location block in my config.
```
location = /robots.txt {
        try_files $uri $uri/ /index.php$is_args$args;
}
```
There is no actual robots.txt file in the webroot, it is created by WordPress /index.php. So even if I add the header in the above block, it won’t get processed because it gets forwarded to index.php location block. However, I don’t think it’s necessary because this plugin is already adding the necessary header when page caching is enabled even without adding this rule.

cache-control: no-store, no-cache, must-revalidate, max-age=0

When page cashing is disabled in this plugin then that header disappears so I’m pretty sure it’s added by the plugin.

The location ~* \.(xml|xsl)$ block causes a 404 on /sitemap.xml because there is no actual file sitemap.xml in the webroot. As with robots.txt, it is generated by WordPress /index.php. As I don’t have a specific location that matches, it relies on matching the default location block.
```
location / {
        try_files $uri $uri/ /index.php$is_args$args;
}
```
Unlike with robots.txt, this plugin is not adding the correct header to sitemap.xml. Rather, it is adding the same header as other static files.

cache-control: s-maxage=31536000, max-age=60

The header is not present with page cashing disabled in this plugin.

For sitemap.xsl this plugin doesn’t appear to add any cache-control header. I am getting the below header for sitemap.xsl but it is present whether page caching is enabled in this plugin or not.

cache-control: max-age=1800

I’m not sure where that header is coming from, maybe added by WordPress core or another plugin. I don’t have any rules for xsl in my server config.

I’m not sure if there is a bug in your plugin that is preventing the cache-control header being set for sitemap.xml like it does for robots.txt (without relying on adding custom NGINX rules). If the plugin can add the header for robots.txt without additional NGINX rules, it should be able to do the same for sitemap.xml?
Plugin Contributor iSaumya
(@isaumya)

4 years, 10 months ago

It appears these rules are not only for browser caching (cache-control: public, …)?

– No it is not. It is for browser caching as well as Cloudflare CDN caching. As you can see the values have many parameters besides public and maxage.

Currently I am using cache-control: max-age=315360000 for all static assets. Why do you recommend only 30d for css and js?

– Not good. The reason CSS & JS are recommended for 30 days browser caching is because, CSS & JS are mostly the files that gets constantly updated as you update the theme, plugins etc. If they are cached for 1 years which which surely you will update things multiple times, chances are your regular users won’t see any changes for a very long time.

If I want to keep my current browser cache settings, should I still add the “public” part of these rules, as below.

– I will recommend to use the browser caching rule suggested by the plugin as that will give you the best result no matter which Cloudflare plan you are on.

Doesn’t Cloudflare ignore these headers anyway when you are using the cache everything page rule?

– Absolutely not. Cache Everything follows the instructions in the cache-control header. That’s why. When you setup the plugin it automatically change the settings under the CF Dashborad Cache Tab > Browser Caching TTL to Respect Headers.

The location /robots.txt block never matches because I already have another location block in my config.

– Yes because just like the sitemaops you do not actually have a robots.txt file and instead the system is using some PHP to generate the file in an abstract manner. So, ofcourse it won’t work.

There is no actual robots.txt file in the webroot, it is created by WordPress /index.php. So even if I add the header in the above block, it won’t get processed because it gets forwarded to index.php location block. However, I don’t think it’s necessary because this plugin is already adding the necessary header when page caching is enabled even without adding this rule.

– In your case it is not necessary as it is not gonna work anyway if you don’t have an actual robots.txt file.

Unlike with robots.txt, this plugin is not adding the correct header to sitemap.xml. Rather, it is adding the same header as other static files.

– Yes because the plugin do not know it’s a sitemap file. To it it’s a PHP file which is abstracted as sitemap.xml file. For this the SEO plugin people needs to add the proper cache-control header for the sitemap. This same issue was there for rankmath but after reporting it they have fixed it.

For sitemap.xsl this plugin doesn’t appear to add any cache-control header. I am getting the below header for sitemap.xsl but it is present whether page caching is enabled in this plugin or not.

– Run a search in the server to see fro where it is coming from. Probably the SEO plugin is adding it.

I’m not sure if there is a bug in your plugin that is preventing the cache-control header being set for sitemap.xml

– Not really, again to the plugin it’s another PHP file and not a sitemap. Try using rRankmath as an example and see. You can also try putting the /sitemap* in the prevent following URLs from caching setion and see if that makes any difference.

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘swcfpc query string missing on backend?’ is closed to new replies.