Page rules are now deprecated without good replacements?

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

10 Likes

@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.

1 Like

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?

6 Likes

@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!

1 Like

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.

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%.

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.

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

6 Likes

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.

4 Likes

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.

1 Like