Validation issue on adding url redirect

Another +1 for #43 🐛 Validation issue on adding url redirect Needs review

#53 is working well for me!

Assigning to myself as I'm triaging all RTBC issues.

Several people have tested #53 and confirmed it's working for them. I do see that the tests were updated so that's good. I have confirmed that patch still applies.

I'm not seeing anyone who obviously reviewed the code in #53. So that's the next step here.

No more manual testing is needed.

I did a quick scan of the code but it still needs a proper code review.

Some nitpicks to fix:

1. +++ b/src/Form/RedirectForm.php
   @@ -143,6 +145,32 @@ class RedirectForm extends ContentEntityForm {
   +    // If creating a new Redirect and the source path is an existing path, recommend an alias instead.
   

   More than 80 chars.

2. +++ b/src/Form/RedirectForm.php
   @@ -143,6 +145,32 @@ class RedirectForm extends ContentEntityForm {
   +      //
   

   Empty comment.

3. +++ b/src/Form/RedirectForm.php
   @@ -143,6 +145,32 @@ class RedirectForm extends ContentEntityForm {
   +      // @todo Exception driven logic. Find a better way to determine if we have a valid path.
   

   More than 80 chars.

The code in #53 is basically the same as all previous patches, which have been through several rounds of review.

Fixing comment lengths.

Thanks @acbramley :)

No more manual testing is needed.

Still needs a proper code review.

The patch 3057250-65.patch is working fine , i have tried and tested it .

Reviewed code. One issue with AccessDeniedHttpException - with the catch in place, the user can create the redirect, but will not receive the warning that it's a valid path or the suggestion to use an alias instead. Is it possible for the user to get AccessDeniedHttpException for a path that doesn't exist?

If not, the same warning could be added inside the catch.

If so, the message could be modified to indicate that *if* it's a valid path an alias is recommended.

Applied existing patch #65 to the fork and changed the warning message as suggested in #69 also added that the message shows on both access denied and if the route exists. Any non existant routes still have no message. I was not entirely sure where i could find the formatting standards so i did not make any changes to fix those.

I'm not sure what's going on in #72 as the issue fork commit is identical to #65.

This patch is the same as #65 plus these additional changes:

* Allow the user to add a redirect from an internal path to an external URL without an unhelpful validation warning to consider using a URL alias instead.
* Remove some use statements from RedirectSourceWidget.php (their usage having been eliminated in previous revisions of this patch).

I applied the patch at #74 to the 8.x-1.x branch.

The module no longer presents the "unhelpful validation warning to consider using a URL alias instead" when adding a redirect from an internal path to an external URL.

The patch removes the unnecessary use statements, as indicated in the second point. 👍🏻

Allow the user to add a redirect from an internal path to an external URL without an unhelpful validation warning to consider using a URL alias instead.

Is this in scope for this issue? It sounds like it's separate.

I think it's in scope insofar as it's a regression of sorts -- the unpatched module doesn't hinder the user in the situation I've raised because the unhelpful warning message was displayed automatically using AJAX, before the form was even submitted.

With the patch, the warning doesn't happen until the user submits the form, which then means they now need to submit the form a second time to make it stick, when previously once was enough.

I.e. Because we've removed the AJAX in this patch, I think we need to also remove any false-positive warnings.

As noted in #9, this is a core issue 🐛 Submitting a form during an ajax request: field data not in $_POST. Needs work . The description in that ticket differs from this description, but it comes down to the same thing.
Can confirm that the core patch in comment 57 🐛 Submitting a form during an ajax request: field data not in $_POST. Needs work addresses the issue reported here.
I know that core issues can drag on forever (12 years and counting), but ideally any further efforts should go towards moving along the resolution there instead of in this module.

Attached a static redirect--2024-08-11--3057250-79.patch file
After Redirect 8.x-1.10 → was released

I was not able to push changes to the issue fork

This fixes this long-running bug, and I agree with #78 that it is prudent to fix this in the contrib module rather than wait for core to fix the underlying issue. Marking as RTBC.

That's OK with me, but this has no merge request, so tests didn't run. Please ensure there is a merge request with the latest and tested version of the patches here.

MR up and green.

I note that the functional change in #74 has been lost (it wasn't included in #79).

https://www.drupal.org/project/redirect/issues/3057250#comment-15524338 🐛 Validation issue on adding url redirect Needs review

Perhaps that issue was dealt with in some other way in the interim. Either way, it probably needs to be reviewed.

@jweowu sorry I missed that, feel free to contribute to the MR.

This is a major bug because if you spend time entering a url and then press submit you lose the URL you've just entered which is quite frustrating and data loss of a sort because you have to re-enter it completely. Also the problem is very bad if you add a redirect from an existing node because you have no reason to enter information in any other field.

If anyone is here looking for a temporary workaround, using the tab key instead of a mouse/trackpad worked for me.

I note that the functional change in #74 has been lost (it wasn't included in #79).

I added the additional check to the MR via https://git.drupalcode.org/project/redirect/-/merge_requests/133/diffs?c... .

This is again ready for review!

https://www.drupal.org/project/redirect/issues/3057250#comment-15723568 🐛 Validation issue on adding url redirect Needs review

Works perfectly with Drupal version 10.4.5 and Redirect module version 1.11.0.

tested latest MR with drupal 10.4.3 and redirect 1.11

Just bumping visibility on this issue. It's now RTBC. This would be a great item to merge and included in a new release, given that it has been indicated as a "Major" level bug. Thanks for the consideration, maintainers!

Redirects with source paths starting with /media result in a 404 after saving. This happens because the module attempts to resolve the path, and if no route match is found (as with file-system paths), it throws an uncaught ParamNotConvertedException.

I've fixed the MR to redo the check if the change the source path and I've added test coverage to ensure that you can save a redirect that overrides a path still.

Posted a review.

Looks like the 1.12.0 release introduces merge conflicts into this merge request and any patches included here fail to apply. I am locking redirect to 1.11.0 for now and may re-visit this if/when I get a chance.

rajab natshah → changed the visibility of the branch 3057250-fixes-with-coding-standard-and-DrupalPractice to hidden.

Thank you for this work everyone. As #95 it looks as though old patches cannot apply to 1.12.0. Is this ready for a new patch after the latest commits from @RajabNatshah or still needing some more work before review?

Tony, still testing with one more MR under Drupal 10.5.x and 11.2.x
🐛 Redirects from aliased paths aren't triggered Needs work
🐛 Validation issue on adding url redirect Needs review
Noticed the big changes

      "drupal/redirect": {
        "Issue #2879648: Redirects from aliased paths aren't triggered":
        "https://raw.githubusercontent.com/vardot/varbase-patches/refs/heads/patches/redirect--2025-08-30--2879648--mr-109.patch",
        "Issue #3057250: Validation issue on adding url redirect":
        "https://raw.githubusercontent.com/vardot/varbase-patches/refs/heads/patches/redirect--2025-08-30--3057250--mr-133.patch"
      },

acbramley → changed the visibility of the branch 8.x-1.x to hidden.

@rajab natshah please be careful when resolving conflicts that you don't break the changes. You had reverted large chunks of the MR here and left it in a broken state. It's usually best to just do a single merge commit when resolving conflicts, or try to rebase the branch.

It then becomes very hard for other contributors because we must then painstakingly go through each file and compare changes before the conflict resolution to see what was been broken.

Thanks, @acbramley, for pointing that out, and your follow-up fixes.
Taken
You are totally right, I got mixed up with fixes from 🐛 Redirects from aliased paths aren't triggered Needs work
As I had both fork issues in the same folder.
I will use the rebase method next time and create a separate folder for each issue fork.

Patch applies on 1.12 and works for me!

For me the the MR133 does not apply anymore (tested against 1.11.0 and 1.12.0):

Gathering patches for dependencies. This might take a minute.
  - Installing drupal/redirect (1.12.0): Extracting archive
  - Applying patches for drupal/redirect
    https://git.drupalcode.org/project/redirect/-/merge_requests/133.patch (#3057250: Validation issue on adding url redirect)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/redirect/-/merge_requests/133.patch

I have used the MR diff as a patch against 1.12 and #105 reports it is working for them as well.

FYI it's not a good idea to use .diff MR urls directly in your composer patch files. This is a security risk as anyone can gain push access and push code to it which could cause all sorts of issues.

Instead, download the diff and store it locally and reference the local patch file instead.

Thank you acbramley, you are completely right about the local patch files.
In addition i was not aware of the .diff url which indeed applys against 1.12.0.

Gathering patches for dependencies. This might take a minute.
  - Installing drupal/redirect (1.12.0): Extracting archive
  - Applying patches for drupal/redirect
    patches/redirect/3057250-mr133.diff (#3057250: Validation issue on adding url redirect)

@acbramley thank you for resolving those conflicts. Regarding guidance in #107 - any reason for us not to upload a patch from the diff here for folks to use ( as was the case with previously in #79 ) ?

I see the guidance → (Making changes locally point 18) still says this is okay: "Consider uploading a patch file to the issue in addition to making a merge request, especially if your changes solve a problem. Although the recommended way to contribute source code changes is via merge requests, patches can be easier for others to install via Composer."

Including the file here.

any reason for us not to upload a patch from the MR diff here for folks to use

The main reason is it confuses contributors, if someone sees a patch they may start contributing fixes via patches again rather than the MR. It then becomes hard to track which changes have been made and whether they have been pushed to the MR or not. It's also very frowned upon in the core queue as it can confuse the needs-review-bot which will put an issue into needs work if the patch no longer applies even if there is an MR, therefore I usually discourage it.

The main reason is it confuses contributors, if someone sees a patch they may start contributing fixes via patches again rather than the MR. It then becomes hard to track which changes have been made and whether they have been pushed to the MR or not. It's also very frowned upon in the core queue as it can confuse the needs-review-bot which will put an issue into needs work if the patch no longer applies even if there is an MR, therefore I usually discourage it.

Good to know! Thanks :)

FYI it's not a good idea to use .diff MR urls directly in your composer patch files. This is a security risk as anyone can gain push access and push code to it which could cause all sorts of issues.

Yes! or on a lesser note, I have seen it result in surprise breaking code changes. Documentation is here:
https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → .