Page rule and logged-in user exclusion


We have just activated this page rule but wanted to get expert opinion that this will not effect Logged-In users? We are a membership / career site where Employers post jobs and candidates apply to those jobs.


Thank you for asking.

By default, everything under /wp-content/uploads/ should already be cached - usually the uploaded images, pdf documents, etc. in the WordPress Media Library.

More information about what kind of type of files (extensions) are cached by default can be found on the list from link below:

From my point of view, you don’t need a Page Rule with the option Cache Level: Cache Everything, except you’d have some kind of a content extension which isn’t already being listed at the link above, therefore you can remove that option while keep the others.

Furthermore, regarding a WordPress website and login forms and cached content, using Cache Level: Cache Everything would not be suitable over the whole domain (only on a part of it such as sub-directory, etc.) as far as non-logged visitors would end-up seeing a cached logged-in version of a homepage or an article with the Admin Bar / Logged-in user bar at the top, which would make nosense and confuse and create bad user experience.

For example, if you’d setup your Page Rule like that, but for like*, then you’d have the issues as mentioned above and even more like you’d keep that cached at Cloudflare for a month and in user’s device web browser for 5 days. So, even you might not see any new posted content too. That would be an issue then. In case if that happens, disable the Page Rule which is affecting and messing around your Website and use “Purge Everything” from the Cloudflare dashboard → Caching → Configuration tab to clear the cache at the Cloudflare (at least).

If that’s the only Page Rule you have with Cache Level: Cache Everything for the /wp-content/uploads/ then you’re good to go.

There could be an issue if, but from what I know and use WordPress, by default WordPress would add some suffix to the same filename (abc.jpg, abc-1.jpg, abc-2.jpg…) being uploaded multiple times by the same or different applicants. Otherwise, you’d have one file cached and not being able to see the “new” one / overwritten.

I hope my above answer helps you a bit at least :slight_smile:

Dear Fritex,

Thank you so much for this advice. Here are all the pages rules we have setup, having no experience in this off course.

When you mention that by default everything under __*/wp-content/uploads/*__ should already be cached. Cached by who? Based on your recommendation I have removed the cache-everything. The thought process was to cache just the images in all formats to decrease page-load times.

I have also disabled the 2nd page rule and cleared CF cache as I am not sure if there are ‘real-world’ benefits in having this rule in the first please. Could you please shed some light on that as well? Should we enable this rule of not, if by default wp-content/uploads is already being cached?



A bit off topic, but your Rule 9 isn’t going to work. It has to be proxied for the Page Rule to work, but due to HTTPS, the connection will fail:

1 Like

Thank you for feedback information and sharing a screenshot of your Page Rules as well.

I am sorry, I now re-read and might have missed few words for more detailed or different re-phrasing.

Nevertheless, from what usually the “wp-content/uploads/” directory is being used for, most of those file extensions - images (the files we upload there and keep) are normally cached (even without the presence of the available option Cache Level: Cache Everything).
We can agree most of them are images, but there knows to be some different from time to time (word - doc(x), excel xls(x), pdf, etc.)

Well, not quite “by default”, rather “by default” the next extensions for images are cached: jpg, svg, gif, png, webp and other image formats (from the list on the mentioned link →

I’d suggest you to enable it, but Modify it so just remove the option Cache Level: Cache Everything from it as far as you’ve mentioned it’d be used mostly (or only) for images - which are cached “by default”.

I am sorry for possible missunderstanding or me using a bit tech terms to describe a thing with which you and some other might not be so familiar with (we all aren’t good at everything, that’s why we ask to get to know more) :wink:

Questions are welcome, so feel free to ask more if you have :slight_smile:

Thank you for pointing that one out. Frankly, I am not sure why it is there in the first place and what it means. I have disabled it.



1 Like

@fritex thank you for the clarification. I have enabled the rule and removed the cache-everything option. I hope the browser TTL & Edge TTL make sense? The website is not updated everyday. The only updates are new job posting requests once of twice a week after which we clear the URL specific cache. We are on RunCloud which is integrated to Cloudflare & WP Rocket so it does the job.

I am happy to assist you :slight_smile:

Yep, good to have them.

That sounds awesome!

I remember there were topics about WP Rocket + Cloudflare, therefore I suggest you to look up at the below articles in that terms just in case if you’d have some issue later - but you might not have or experience them. Some do, so I’d just like to share them below in case if happens in future:

I cant find the Bot Fighting Mode disable switch. Has this been moved? BTW WPR just reached out on another support ticket saying that Optimize CSS Delivery is not working even through their IP is whitelisted and option tuned on:

Might be the articles could not have an updated version of images or some links.

Bot Fight Mode can be enabled or disabled at the link from below:

In picture, should look like below example:

Sidebar menu:

This is what I see in the Bots tab

Check the “Configure Super Bot Fight Mode” link.

I did but it doesnt have the Bot Fight mode switch

Hi @sdayman not sure if you got a chance to see my screen shot but I dont have the Bot Fight mode switch?

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.