Page rules are now deprecated without good replacements?

[cherryjimbo]

As of [IMPORTANT] Page Rules Deprecation and [Rules] Update Page Rules references by pedrosousa · Pull Request #14566 · cloudflare/cloudflare-docs · GitHub, it seems Page Rules are now deprecated. This is a significant downgrade for customer experience, and I’d like to describe why.

The UX of Page Rules is still vastly superior to other Rules products, and some features are simply not reproducible anymore with any level of ease. They might be powerful, and that is awesome! But they suffer greatly with UX for things that were once trivial with Page Rules.

• Simple stuff like https://jross.dev/example.txt becomes (ssl and http.host eq "jross.dev" and http.request.uri.path eq "/example.txt"). Not the end of the world, but much more verbose, requires wayyy more understanding of ruleset syntax. A theme moving forward.

• https://jross.dev/test/*/*.zip in page rules now becomes something like http.request.uri.path matches "^/test/[^/]+/.*\.zip$" with other rules products. This is… awful UX. And is a direct loss of functionality for folks on free plans that don’t have access to regex.

• For simple redirects like www.jross.dev/* 301-ing to www2.jross.dev/$1, this now has to look something way more complex, matching on http.host eq "www.jross.dev" and then a dynamic redirect with concat("https://www2.jross.dev", http.request.uri.path). Do-able, but again, sooo much more understanding required.

• For more complex redirects, like www.jross.dev/*/downloads/*.txt redirecting to downloads.jross.dev/texts/$1/$2.txt, I wouldn’t even know where to start with ruleset engine, and whatever output would support that would be sooooo much less maintainable than the previous page rules solution. And I’m a power user. And would almost certainly again require regex.

• Or jross.dev/files/*/* where I’d want to match jross.dev/files/foo/bar.txt, but not jross.dev/foo/baz/bar.txt. Trivial in Page Rules, not in other Rules products. You could do it with regex I guess, if you’re on a plan that supports that, but with significantly more effort.

To be clear, the power and control you get with new rules products is great, but there has to be a better migration (and creation) path for rules like this that I would consider extremely common. These aren’t contrived examples - some of these are very similar to rules we use at my business every single day. Specifically, wildcard handling in Page Rules in trivial. Wildcard handling in other Rules products is anything but, and this really needs to be considered before you drop functionality.

This is an extremely critical concern I have both personally and professionally moving forward. How is it a product can be deprecated when the new product creates significantly worsened UX and in some cases, doesn’t even replicate the old behaviour depending on plan level?

Who can I ping to chat about this with further? As of right now, I am extremely disappointed with this deprecation announcement, and really hoped we’d see serious UX improvements to Rules products before this announcement came. cc @cloonan @mbullock @ncano

[ncano]

@cherryjimbo, thank you for your thoughtful feedback! It’s great to see our announcement sparking discussion and driving improvements to our new Rules products.

I can confirm that Managed Redirects are indeed on our roadmap, and wildcard pattern matching is a priority for us. We’ve been actively working on integrating these features into our new Rules products, with plans to roll them out later this year. Rest assured, we won’t enter maintenance mode without these enhancements.

Simultaneously, we’re dedicated to refining the Rules UI for a more intuitive and cohesive user experience. We’re investing resources into this area to ensure a smoother transition.

As stated in our migration guide, we’ll continue updating it in the coming months with additional information about the migration process. Some instructions may change as we simplify configuration deployment as part of this project.

While we believe our new Rules products offer full feature parity with Page Rules, we acknowledge that the implementation may differ. However, the Ruleset Engine is already capable of addressing a wide range of use cases, and this is ultimately why we believe it is the right time to initiate this transition.

Our decision to do this now is driven by the recognition that migrating millions of zones away from Page Rules, a product with high adoption over more than a decade, will take time. It’s impractical to encourage users to adopt a legacy product shortly before its deprecation. Hence, we’re proactively preparing users for the change now.

Hope this answers your concerns, and happy to discuss our deprecation plans in more detail if needed.

[cherryjimbo]

Thank you for the relpy @ncano. I appreciate the information and insight, however I still have some significant concerns with this approach.

I can confirm that Managed Redirects are indeed on our roadmap, and wildcard pattern matching is a priority for us. We’ve been actively working on integrating these features into our new Rules products, with plans to roll them out later this year. Rest assured, we won’t enter maintenance mode without these enhancements.

Can you expand on the timeline here please? Are you committing to have this ready by 2025, but not before? So what happens in July when this functionality is lost for new free zones, or August for Business, and October for Ent? Will my business be completely stuck without this functionality on any new zones we create in the latter half of this year?

Simultaneously, we’re dedicated to refining the Rules UI for a more intuitive and cohesive user experience. We’re investing resources into this area to ensure a smoother transition.
As stated in our migration guide 1, we’ll continue updating it in the coming months with additional information about the migration process. Some instructions may change as we simplify configuration deployment as part of this project.

This is good to hear. I hope this is more effectively called out and communicated in any future comms around this deprecation.

While we believe our new Rules products offer full feature parity with Page Rules, we acknowledge that the implementation may differ. However, the Ruleset Engine is already capable of addressing a wide range of use cases, and this is ultimately why we believe it is the right time to initiate this transition.

“The implementation may differ” is a very nice way to describe a fundamental reduction in the quality of life and usability of the new products in many of the scenarios I have outlined.

So if it does offer full feature parity, can you or someone on your team please share a way to reproduce the following Page Rule, exactly, using the Ruleset engine, which I previously shared?

• Redirect www.jross.dev/*/downloads/*.txt to downloads.jross.dev/texts/$1/$2.txt

Or even further:

• Redirect www.jross.dev/*/downloads/*/*.txt to downloads-$2.jross.dev/texts/$1/$3.txt

Both of these are trivial with Page Rules, so I would love it if you could share the equivalent rule please, both with and without regex, so we can ensure even free users will still be able to do this.

Hope this answers your concerns, and happy to discuss our deprecation plans in more detail if needed.

Sadly, it doesn’t really. You’re telling me that improvements are coming to bring the ruleset engine to parity with some of the great UX with Page Rules, but then also telling me that this might not happen until 2025 (the maintenance mode date). So for potentially half a year, people will be without this (or experience severely diminished) behaviour? Am I understanding that correctly?

[ncano]

@cherryjimbo, sure. Thank you for raising your concerns and advocating for a great user experience.

I understand your frustration around migrating from legacy Forwarding URL to Single Redirect Rules, and the need for wildcard support. We are committed to providing wildcard support before making any changes to Page Rules (important: this product is deprecated, read more here https://developers.cloudflare.com/rules/reference/page-rules-migration/) for existing accounts and zones.

Our data shows that out of all active legacy URL forwarding rules with wildcards, less than 9% capture and expand more than one wildcard to redirect traffic dynamically. This means the vast majority of URL forwarding rules can be effectively replicated using Redirect Rules with simple operators like “contains” and functions like “starts_with” or “ends_with”, instead of relying on wildcards. We will be adding more URL forwarding examples, including those for API and Terraform users, to the migration guide to demonstrate how to achieve the same results with Redirect Rules and assist with this transition.

For users requiring advanced URL forwarding with capturing multiple wildcards, regular expressions are currently supported. We know regex requires advanced knowledge of Ruleset Engine syntax and is only available for Business and Enterprise plans. Thus, introducing wildcard support to the Ruleset Engine and making it available to everyone is our top priority. Our engineering teams are working to implement this before any changes affect existing Cloudflare users.

For posterity, here is an example of implementing advanced URL forwarding using the Ruleset Engine according to your requirements:

{
  "name": "default",
  "phase": "http_request_dynamic_redirect",
  "kind": "zone",
  "rules": [
    {
        "expression": "http.host eq \"www.jross.dev\" and http.request.uri.path matches r\"^/.*/downloads/.*/.*\\.txt$\"",
        "action": "redirect",
        "action_parameters": {
          "from_value": {
            "target_url": {
              "expression": "regex_replace(http.request.uri.path, r\"^/(.*)/downloads/(.*)/(.*)\\.txt$\", \"https://downloads-${2}.jross.dev/texts/${1}/${3}\")"
            },
            "status_code": 301,
            "preserve_query_string": true
          }
        }
      },
    {
      "expression": "http.host eq \"www.jross.dev\" and http.request.uri.path matches r\"^/.*/downloads/.*\\.txt$\"",
      "action": "redirect",
      "action_parameters": {
        "from_value": {
          "target_url": {
            "expression": "regex_replace(http.request.uri.path, r\"^/(.*)/downloads/(.*)\\.txt$\", \"https://downloads.jross.dev/texts/${1}/${2}\")"
          },
          "status_code": 301,
          "preserve_query_string": true
        }
      }
    }
  ]
}

I’d love to have a real-time conversation with you to address any outstanding questions and gather more feedback to help inform our decisions on how to roll out these changes with the best possible user experience in mind. I will reach out via DM to schedule a call if you are available. Thank you!

[cherryjimbo]

@ncano

We are committed to providing wildcard support before making any changes to Page Rules (important: this product is deprecated, read more here https://developers.cloudflare.com/rules/reference/page-rules-migration/) (important: this product is deprecated, read more here Page Rules migration guide · Cloudflare Rules docs) for existing accounts and zones.

Thank you. This is good to hear, and alleviates a lot of concerns around missing wildcard support assuming this lands before July when the first wave of changes happen.

@ncano

Our data shows that out of all active legacy URL forwarding rules with wildcards, less than 9% capture and expand more than one wildcard to redirect traffic dynamically.

9% for a product that has over a decade of usage, documentation, blog posts, and advice throughout this forum, discord, and all over the web sounds like an awful lot to me. And even with a single wildcard like /downloads/*/info.json, that’s significantly more complex in the new rules products, and I’ve bet that’s much higher than 9%.

@ncano

For posterity, here is an example of implementing advanced URL forwarding using the Ruleset Engine according to your requirements:

I appreciate the example, thank you. However, I hope you can very quickly see how much more complex this is for customers. Especially those that are less technical. It’s very easy to describe to people how to use wildcards and Page Rules (important: this product is deprecated, read more here https://developers.cloudflare.com/rules/reference/page-rules-migration/), and I think most people would quickly understand something like www.jross.dev/*/downloads/*.txt vs http.host eq \"www.jross.dev\" and http.request.uri.path matches r\"^/.*/downloads/.*/.*\\.txt$\" and then "regex_replace(http.request.uri.path, r\"^/(.*)/downloads/(.*)/(.*)\\.txt$\", \"https://downloads-${2}.jross.dev/texts/${1}/${3}\")" .

I completely understand that this is more powerful, flexible, and allows for much deeper configuration and fine-tuning. But the additional complexity for customers can not be overstated enough here.

---

Page Rulez (can we please not expand “Page Rulez” with an “S” to include a ridiculously verbose disclaimer? @cloonan) has been a fundamental part of Cloudflare’s product offering for over a decade. There are thousands and thousands of blog posts both first-party and third-party, videos, and documentation written around them, their uses, and how to get the most of of them. Some serious care and additional hand-holding needs to be done here to make this as seamless as possible.

Right now, users are being scared with red/yellow warnings everywhere, scary emails, and a real lack of easy migration path other than essentially “good luck have fun, here’s the docs, hope it covers your use-cases”. There’s a serious lack of empathy here for customers that have been using and relying on this product in some cases for over a decade.

Some ideas to help streamline this:

• In-dash wizard, similar to what we saw with the WAF upgrade (this was handled so much better)
• A tool that lets you input a Page Rule syntax and be given back the syntax for the new Ruleset engine
• Cut down the scary red/yellow “deprecation” warnings, and make this process feel like an “upgrade”. Hold people’s hands through the process in the dash, reassure them nothing is going to change with their functionality after the migration, just configured in different places, etc. Other product deprecations/upgrades in the past have done this well.

@ncano

I’d love to have a real-time conversation with you to address any outstanding questions and gather more feedback to help inform our decisions on how to roll out these changes with the best possible user experience in mind. I will reach out via DM to schedule a call if you are available. Thank you!

Sure, happy to chat further. Thanks for reaching out. I’ll reply to your DM shortly.

[cherryjimbo]

Speaking of red/yellow notices that unnecessarily scare or confuse users:

This is at the top of every single zone. Free, pro, biz, and ent, and shows up no matter if you have Page Rules in use on the zone or not. I really don’t understand why this deprecation strategy has felt so aggressive throughout, especially while there’s still not even feature parity with old Page Rules if you you’re on a plan that doesn’t support regex.

[RyderCragie]

@cherryjimbo

So if it does offer full feature parity, can you or someone on your team please share a way to reproduce the following Page Rule, exactly, using the Ruleset engine, which I previously shared?

• Redirect www.jross.dev/*/downloads/*.txt to downloads.jross.dev/texts/$1/$2.txt

Or even further:

• Redirect www.jross.dev/*/downloads/*/*.txt to downloads-$2.jross.dev/texts/$1/$3.txt

Both of these are trivial with Page Rules, so I would love it if you could share the equivalent rule please, both with and without regex, so we can ensure even free users will still be able to do this.

Further to that, how can I replicate the below Page Rule with another type of Rule? Perhaps a Redirect Rule?

It forwards all subdomains of the .co.uk domain to the .com domain, with the path included from the original request.

A tool that does this for users would be great, or a manual “Migrate Sooner” button so the wait isn’t a factor. Any advice would be greatly appreciated.

[dazzz]

I’m sure that Cloudflare has their reasons for this change but I want to express that - as a customer who just had their annual plan renew - I am not happy with this change. I use rules periodically and found the older Page Rules better than the newer Rules products, at least for my use case.

And for my long-term systematic rules, I now need to allocate dev time to replicating and testing them using the other products, as I’m pretty sure the auto-migration that will apparently occur in 2025 will not be perfect, given rule complexity.

But… why?

[ncano]

@RyderCragie

It forwards all subdomains of the .co.uk domain to the .com domain, with the path included from the original request.

I would do it this way:

Filter: ends_with(http.host, ".example.com")
Expression: concat("https://", regex_replace(http.host, r"^(.*).com", "${1}.co.uk"), http.request.uri.path)

If you’re not on Business or Enterprise, it’d be easier to wait until wildcard support in Rules is released later this year.

@dazzz

I use rules periodically and found the older Page Rules better than the newer Rules products, at least for my use case.

I would love to chat more about this and see what else we can do to improve new Rules to match the experience on top of the changes we have already planned. Let me know if I can reach out via DMs and schedule a call.

@dazzz

I now need to allocate dev time to replicating and testing them using the other products, as I’m pretty sure the auto-migration that will apparently occur in 2025 will not be perfect, given rule complexity

I wouldn’t assume this. We will be running migration with wildcards already in place, in small chunks, and for all 37 Page Rules types separately. If for some reason an outcome of a specific rule cannot be matched exactly by new Rules, we will be reaching out to affected users a few months in advance with suggested actions.

Hence, you can safely skip investing time in doing this if you do not have to be in control of your own migration due to compliance, regulatory or other sensitive requirements.

[Chaika]

@ncano

While we believe our new Rules products offer full feature parity with Page Rules, we acknowledge that the implementation may differ.

One thing that noticed recently is that even on free plan, Page Rules can be used to disable Origin Cache Control. However in Cache Rules, the option is Enterprise only. The migration guide makes no mention of this limitation other then just saying “Select the option in the new Cache Rules” which of course simply isn’t possible for non-Enterprise users.

It’s specifically documented as Available to all plans in Page Rules:

Settings | Page Rules (deprecated) · Cloudflare Rules docs

and Ent Only in Cache Rules:

Cache Rules settings · Cloudflare Cache (CDN) docs

Simple fix would just be making it available for all plans.

[akrivit]

Hello -
Is there particular behavior that disabling OCC gives you that you cannot define using existing rules that would help us understand how you’d like us to interact with cache-control directives we receive from your origin?

[Chaika]

It was more of a user request/confusion “why is Cloudflare trying to turn a feature available on free plan via Page Rules into Enterprise only in Cache Rules”. I can think of a few though, mostly ones that are do with Edge Caching Behavior. For example, if you have an origin that you can’t control responding with no-transform, and you want to use Polish on it, it seems your only option is disabling Origin Cache Control. Transform Rule Response Headers are too late, and nothing else applies, at least from my testing. Probably same for proxy-revalidate/must-revalidate, things that aren’t covered by Cache Rules

[akrivit]

Is this a real problem you have or just a hypothetical argument? I think there are a few ways to accomplish this outside of turning “occ off”… which also shouldn’t add a no-transform directive. This also isn’t feedback we get very frequently so I’m trying to assess the actual impact on polish users.

[marek.jakubcik1]

By the way, old rule system is no longer marked as deprecated, so what is the situation now?

[cherryjimbo]

They changed a lot of the language away from “deprecated” instead to “legacy”, and made it clear that Cloudflare will be handling the migration for everyone, and that no interruption of service (creating new page rules) should occur.

[IMPORTANT] Page Rules Migration

Just a heads up that the original post has been updated with our revised migration plan. In this update, we are making it clear that Cloudflare will handle the migration of existing Page Rules, so customers do not need to migrate their own rules unless they wish to do so. Additionally, Page Rules will remain available for all accounts and zones, including new ones, until the start of the migration. We have also added more examples on how to convert Page Rules URLs to Rules filter expressions a…

[sjr]

wildcard_replace seems to have appeared as a fuction for dynamic redirects…

Functions reference · Cloudflare Ruleset Engine docs

wildcard_replace(source, wildcard_pattern, replacement [, flags])

• Replaces a source string, matched by a literal with zero or more * wildcard metacharacters, with a replacement string, returning the result. The replacement string can contain references to wildcard capture groups (for example, ${1} and ${2}).

[ncano]

Yes, wildcards are now supported by Ruleset Engine, and we’re working on releasing a simplified UI for Single Redirects to allow users to benefit from wildcard_replace() without having to use the function in the dashboard at all: Wildcard Support in Ruleset Engine Products.

[cherryjimbo]

It looks like wildcard options landed in the ruleset editor today.

[ncano]

And we have a new simple UI for redirects now too: Go wild: Wildcard support in Rules and a new open-source wildcard crate