Add support for custom query strings in Umbraco URL redirects

[rickbutterfield]

Prerequisites

• I have added steps to test this contribution in the description below

Description

This PR adds the ability to pass a QueryString value into RedirectToCurrentUmbracoUrl(). This will form part of a fix for Umbraco Forms so that forms posting back to virtual pages can be redirected correctly whilst respecting a custom IContentFinder.

Information on how to test can be found at: https://github.com/rickbutterfield/UmbracoVirtualRedirectsTest/
There is more information/discussion on this issue: umbraco/Umbraco.Forms.Issues#1456

The same code works in v16/dev and should be able to be cherry picked.

[Copilot]

Pull Request Overview

This PR adds support for custom query strings in Umbraco URL redirects by extending the RedirectToCurrentUmbracoUrl() method with an overload that accepts a QueryString parameter. This enhancement enables proper handling of form postbacks to virtual pages while respecting custom IContentFinder implementations.

Key changes:

• Added overload method to accept custom query strings in redirects
• Enhanced redirect result class to handle custom query string parameters
• Maintained backward compatibility with existing redirect functionality

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/Umbraco.Web.Website/Controllers/SurfaceController.cs	Added overload method RedirectToCurrentUmbracoUrl(QueryString queryString)
src/Umbraco.Web.Website/ActionResults/RedirectToUmbracoUrlResult.cs	Enhanced constructor and execution logic to handle custom query strings

[AndyButland]

This maybe needs a comment, as it seems a little unintuitive to me.

Given we are using OriginalRequestUrl.PathAndQuery that presumably should include the querystring already. So why do we need to pass it in?

If we do, then I guess it's because we are allowing someone to override the original query string with a different one - but in that case, maybe it's better to just expect them to do Redirect directly, and have full control over the URL that's used?

So just trying to understand the use case for this, and if you do believe there's a real one, maybe you could add in a comment for future reference? Thanks.

[rickbutterfield]

Agreed Andy, the fact that the method that calls this is RedirectToCurrentUmbracoUrl() makes me think that it shouldn't include the querystring by default. RedirectToCurrentUmbracoPage() handles this in the same way with an optional querystring.

[lauraneto]

The latest commit changed the default behavior so that if you are in /virtual-test?abc, you would now get redirected to /virtual-test instead of /virtual-test?abc as before.
While I agree that this would make it more in line with RedirectToUmbracoPageResult, it is a behavioral change that I don't think we should introduce at this point (at least in V13).

I think the main question from @AndyButland (correct me if I'm wrong Andy) was: if you want a custom url, you can also easily use the built-in ASP.NET Redirect(), and have full control, like:

var redirectUrl = UmbracoContext.OriginalRequestUrl.AbsolutePath + QueryString.Create("abc", "123");
return Redirect(redirectUrl);

So, is there a need to have this in the core?
If there is, we might adjust the behavior, but most likely for a major.

[rickbutterfield]

I appreciate all your thoughts @lauraneto! I have gone back to the drawing board with my original Forms bug and you're right, I can just take the current OriginalRequestUrl and Redirect() from there rather than relying on something in core!

I'll close this PR

[Copilot]

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.