Document that URL redirects work from node/{nid} but not alias

Not 100% sure what happens first. You could also try if #2704213: "Redirect from non-canonical URLs to the canonical URLs" not working with language code in url changes anything about it.

If de-alias really happens first, then we could de-alias when creating the redirect maybe

I'm not sure.

The thing is, I don't understand why you would even have both an alias and a redirect for the same path? Aliases are for existing things, redirects are to go from a not-actually existing thing to an existing thing. Why would you have an alias for something that doesn't exist?

So maybe instead of trying to do something automatically, we should actually validate and prevent such redirects, possibly with an easy way to drop the alias?

Sure, feel free to do that.

Fair enough, https://www.drupal.org/project/rabbit_hole might be a better way to solve that use case, though?

Great.

Lets keep this open, though. I just closed a duplicate of this and there might be conflicts with left-over aliases, so it seems like a good thing to de-alias or warn or something.

Hey, just checked that redirect is not working for node alias , so mentioned that in Help page and Readme.txt file .

I just tried to get into details how the redirect process works and found that fetching of rid (request object) is based on generation of hash. Now, this generation of hash while saving redirects from form is based on the input URL, so let's say we have 2 nodes and they have following path alias:
node/1 -> /abc
node/2 -> /def

Now, if we try to redirect from /abc to /def then while saving redirect hash is generated making use of /abc.

Now when we hit /abc, expected behavior is to redirect to /def but the route subscriber of Redirect module when tries to find any corresponding redirect rid, it is not able to find any. This is because Route Subscriber uses processInbound function of PathProcessManager service to do inbound processing which changes path to internal path and hence the hash generated for matching in db is different than the one stored there.

Proposed Solution:

As of now, IMO Route Subscriber should not convert request URL to internal path for hash generation. So, what we can do is instead of using core PathProcessManager service we should create our own service extending the core one and override processInbound to exclude alias manager's inbounding so that URL is not converted to internal system path. This way we will end up with perfect match.

Need views on this.

Thanks

Also, we have found out an alternative workaround on this: Using Redirect Domain Submodule

Thanks

The submodule doesn't really scale to a large number of redirects, though.

I don't think what you describe is necessary. All we IMHO need to do is do the same path processing when actually saving an alias so that we convert the alias to the system path.

Converting the alias to system path and then generating the hash from that has the tendency to create ambiguity as we can have scenarios where multiple path aliases would have same system path and in that case the hash generated would be same for all such cases which are definitely not good from the current module architecture point of view.

Thanks

I just stumbled upon a similar problem as described in #11 in my project - if I have a redirect automatically generated during a node edit where the node's url alias changes, or if I manually input a 'source' path and try to redirect it to another path, then none of these redirects work and they simply return a 404 page not found.

After some debugging I found that when the redirect source gets saved in the table the has created is:
source_path + language + source_query
where the source query is empty since no query parameters are specified at that point.

However, when the findMatchingRedirect function is called in the onKernelRequestCheckRedirect function in the file RedirectRequestSubscriber.php, the $request_query contains Drupal's 'hidden' q=source_path parameter which causes the hash to not match the one saved in the database when the redirect was created initially.

I have created a simple patch for this by removing the 'q' parameter from the $request_query array, while leaving any other paramaters that might exist intact.

This has solved my problem and aliases and manually added redirects work perfectly fine.

It turns out for me it was an issue with the nginx configuration not getting rid of the ?q parameter correctly.

After reading more into the common drupal configuration for nginx (https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/) I changed my main location to the following

location / {
  # try_files $uri @rewrite; # Drupal <= 6
  try_files $uri /index.php?$query_string; # Drupal >= 7
}
</coded>

This means that the patch I submitted above is no longer required as the source query array no longer contains the rogue <code>q

parameter.

+1 for this issue. It seems silly to pop up a message saying "it's recommended to use a URL alias instead" when that doesn't cover the typical use case of wanting the browser's URL to change... And also fail to mention in that pop up message that what you're trying to do isn't just "not recommended" but it's not even going to work at all. Since using the alias here will result in nothing happening I don't see what the harm could be in having it convert that into a node/xyz URL automatically since that will make it work.

multiple path aliases would have same system path

I can't imagine this use case at all. So you have multiple aliases going to the same system path... But you want them each to redirect to different places? In that case it seems like you don't want those aliases and should delete them so you can add the redirects you want.

My use case is like, my customer wants to be able to add redirects from certain pages in the IA that they don't have content for yet to one of their child pages. Later they would like to add content to the higher level page and remove the redirect... So in that case they would like the one single alias for the page to remain in place for when they remove the redirect.

Who is the person who wants multiple aliases to the same path and have them redirect differently and why do they want that?

I may end up using rabbit hole instead... I just hope nobody ends up wanting redirects from non-node pages too... It's too bad this module doesn't seem to be lined up to be such a general solution.

My use case is: I have an unpublished node. If a visitor loads the page he gets a 403. So, I want to add a redirect for it. Of course, for ease of use, I would like to add the alias, but it doesn't work. I also agree that at least an alert message should be added.

See also #2879648: Redirects from aliased paths aren't triggered as a related/duplicate issue which attempts to make aliased paths work.

Hi everyone, I just posted a rewrite of the patch in #2879648: Redirects from aliased paths aren't triggered.
Feedback there are most welcome and appreciated.
Cheers :)

Creating a merge request for a new idea that I mentioned in the linked issue.

Proof of concept for the UI, not functional yet:

@Berdir I quite like this idea. Although it'd be nice to just be able to use aliases, this is a decent compromise.