WordPress Page Rule using pipe operator "or" | in a single rule

While using Free plan, I wonder regrading regex and Bypass on Cookie which are available on higher plans, is it possible to setup a functional single Page Rule for example for WordPress CMS with needed options as Cache Level: Bypass?:

  1. www.domain.com/wp-admin*|*preview=true

Does that “pipe operator” (or) | work like that, or I have to keep the two separated Page Rules with the same options as follows?:

  1. www.domain.com/wp-admin* → Cache Level: Bypass and other …
  2. www.domain.com/*preview=true → Cache Level: Bypass and other …

I tried to enter it as a single and it accepts it, just haven’t tested if it works like that, or it’s just meant to work with Bypass on Cookie on higher plans.

Article source (just here is stated for Bypass on Cookie, while I need bypass cache level):

Thank you for feedback!

Tested, working as needed.

Really? I’m quite surprised a pipe actually works in Page Rules.

As a test, I did this:
Match: example.com/page/2|3|4/
Forwarding URL: some other website

It doesn’t work.

2 Likes

Interesting :thinking:

I have realized at one of my websites, having 14-17 Page Rules active, as I combined them with your help, now it’s only 3 “the golden ones” which are so far working as needed.

Except maybe it doesn’t work :zipper_mouth_face:, but as far as I understand and as it is configured, by “standard” the JS, CSS and images are “HIT” (as I want them actually) being cached under wp-admin* (Caching Level: Standard in Cache → Configuration and Browser Cache TTL: Respect Existing Headers).

Either cached under a custom path masked/* - where is some ajax-like product comparasion application.

On both scenarios + *preview=true articles (draft, not yet published) the “login version” or a “comparasion cart with products” webpages are not cached (as a static HTML), as far by the 1st rule Cache Everything is setup while below ones are on Bypass - meaning it works as I want it with a W3TC plugin.

Maybe in a wrong order as I look at them now :roll_eyes: :grimacing:

Sharing below:

That’s part of regular expressions which are not supported in page rules. I would not expect that to work. If it does, we should really have a closer look :slight_smile:

2 Likes

Rule #2 and #3 should never fire as #1 is a catch-all.

So yeah, | should still not work :slight_smile:

2 Likes

Which also means you really are making good use of Cloudflare’s cache, @fritex :wink:

You cache every byte there is, every single one of them :smile: - just something to take into account.

1 Like

Hm, could be I do not understand this so good, from the above example, the AMP URLs either of the WordPress on the main domain and either of the “sub-directory application”, first time visit (if not already being in a cache - for some time setup as I have 15minutes) is MISS, after a refresh they are cached HIT.
And the important thing that Rocket Loader doesn’t load on these /amp/ URLs (which would cause a broken and not a valid AMP page).

As the stats say, approx. ~70% bandwidth saved.
Is that enough? :wink:

I remember year or two ago, there were days when I got regular traffic via Google search engine as double than the below one from the last week (while the server CPU usage was barely on 13% at the time):

1 Like

The first rule to match will fire. As rule #1 is /* it will fire on every request, rules #2 and #3 will never fire. You’d need to place rule #1 last.

As long as you don’t have anything that is login dependent, you should be fine.

But yeah, the | won’t work I am afraid.

Okay, now I am totally confused :joy:

How come? :grin:

1 Like

With your current setup rules #2 and #3 will never fire because #1 catches everything.

You’d need to move #1 to the end of the list, but (current) rule #2 will still not work because the pipe does not work like in a regular expression here but will be expected literally in the request, so right now that rule will probably never fire.

1 Like

Do not get me wrong here, I am not arguing, neither say I am correct, but by the statemens from above from both of you, “it should not work” or “put the 1st rule on the last place”, “login dependend”, may I freely ask considering the rules from above screenshot, could or does it actually work to accomplish the below?

I 100% admit you are right about this one considering only the Page rules, but without you actually knowing what’s behind the background, I believe it could change the perspective (or not) - as far as I currently see it is working as expected.

Just to note, it working over Nginx and W3TC plugin being configured (Page Cache and Browser Cache, including other).

Which now brings me to questioning myself, maybe it could actually depend on this settings which W3TC is sending and serving out?

Also having this:

While the separate “sub-app”, is serving the URLs via PHP / (homepage) , /product-name/, /productA-vs-productB/, /product-name/amp/ with:

cache-control: no-store, no-cache, must-revalidate
pragma: no-cache

Nginx:

set $cache_uri $request_uri;

if ($request_method = POST) {
    set $cache_uri 'null cache';
}

if ($query_string != "") {
    set $cache_uri 'null cache';
}

if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
    set $cache_uri 'null cache';
}

if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
    set $cache_uri 'null cache';
}

location / {
    expires modified 900s;
    add_header Vary "Accept-Encoding, Cookie";
    add_header Pragma "public";
    add_header Cache-Control "max-age=900, public";
    add_header Referrer-Policy "no-referrer-when-downgrade";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";
    add_header Refresh "600; URL=https://$host$request_uri";
    try_files /wp-content/cache/page_enhanced/${host}${cache_uri}_index_ssl.html $uri $uri/ /index.php?$args;
}

location ~ ^/wp-content/cache/minify/[^/]+/(.*)$ {
    try_files $uri /wp-content/plugins/w3-total-cache/pub/minify.php?file=$1;
}

location /my-sub-app/ {
    index index.php;
    try_files $uri $uri/ /my-sub-app/index.php?$args;
}

location ~* \.(css|htc|less|js|js2|js3|js4)$ {
    expires 2592000s;
    etag on;
    if_modified_since exact;
    add_header Pragma "public";
    add_header Cache-Control "max-age=31536000, public";
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    access_log off;
}

location ~* \.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|webp|json|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|_otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|_ttf|wav|wma|wri|woff|woff2|xla|xls|xlsx|xlt|xlw|zip)$ {
    expires 2592000s;
    etag on;
    if_modified_since exact;
    add_header Pragma "public";
    add_header Cache-Control "max-age=31536000, public";
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    access_log off;
    if ($request_uri ~ ^[^?]*\.(ttf|ttc|otf|eot|woff|woff2|font.css)(\?|$)) {
        add_header Pragma "public";
        add_header Cache-Control "max-age=31536000, public";
        add_header Access-Control-Allow-Origin "*";
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        access_log off;
    }
}

I am not sure, or better to say, I can change the rules order and see - not sure what will I get then - but, should I?

  1. Cache all the requests (CSS, JS, images - by default) and URLs - which are mostly WordPress posts as www.domain.com/post-name/ - as HTML (they are actually saved on the server as .html pages by W3TC) and not the Ajax requests

  2. If request www.domain.com/wp-admin/ (clean one - actually redirects to wp-login.php if user not logged-in yet), BYPASS it, while cache each request under /wp-admin/ (CSS, JS and images) while do not cache requests to the dashboard pages like edit.php, post.php, etc.

  3. If request contains for example preview=true, meaning user is being logged into WordPress dashboard and is previewing his post which will be published or tempered, and all requests under /wp-admin/ are cached (CSS, images, JS) while the URL to the post preview=true to him is not being cached - BYPASS (by settings in the W3TC)

  4. If request www.domain.com/post-name/amp/ (they are actually saved on the server as .html pages by W3TC), then cache that one too as HTML, but do not load Rocket Loader on them

  • just to note here, a behaviour when the user was or wasn’t previously on the www.domain.com/post-name/amp/, logged into WordPress and visits or hits refresh button www.domain.com/post-name/amp/, he sees it as BYPASS with “admin bar” on the top (as needed to be)
  1. If www.domain.com/my-sub-app/ - which is homepage, BYPASS it (as there could be some “comparasion box” for the product comparasion - (not good if all the visitors see the same box of added products to compare), but cache the standard CSS, JS and images under that sub-directory-app (again, not Ajax one - which actually is the “comparasion box containing products the visitor added to compare”)

  2. If www.domain.com/my-sub-app/some-other-page/ - product page, same as 5th

  3. If. www.domain.com/my-sub-app/productA-vs-productB/ - comparasion page, same 5th

  4. If www.domain.com/my-sub-app/productA/amp/ - it is BYPASS either due to /my-sub-app/ from the 2nd rule, or due to my server sending no-cache, etc., or due to having it in combination with Origin Cache Control: On (despite the Page Rules), but also do not run Rocket Loader on these

For the end, maybe having Origin Cache Control: On for all three of the rules could also have an impact here.

Furthermore, www.domain.com/my-sub-app/productA/amp/ says BYPASS always (even the server sending no-cache, etc.), while www.domain.com/post-name/amp/ is either a MISS or a HIT.

  • my-sub-app defined in 2nd rule, while amp (should trigger both WordPress post AMP URL and my-sub-app AMP URL?)

Okay, now I really think this one is a bit complex to handle even to Cloudflare itself as far as the origin is doing good job as configured, then Cloudflare just carries it further on with “keep peace and respect the origin as is” :smiley:

1 Like

I am slightly confused.

My overall point was, in your current setup, you don’t need rule #2 and #3 as they will never fire. As for rule #2, even it fired, it would not do what you expect as that syntax is not supported. You’d actually have to send a request with | in the URL.

1 Like

Ou, okay.
I got it now!

Yes, actually, if Cloudflare wouldn’t respect what and how the origin is serving, meaning if I wouldn’t have the origin setup correctly, it would end up as I would even have the cached pages which shouldn’t need to be cached at all.
So, the 2nd rule for example is actually call it a preview rule of what is expected to be (hopefully the origin is configured as is to do exactly what and how it’s meant to do).

True, obviously.

I am really sorry for misunderstanding from the first, and thank you both for your time and explanation :slight_smile:

Each day something new to learn :wink:

1 Like

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