Clarifications

Good point about the lack of configuration requirement...

Say, for example, you have node/123 with and alias pages/about-me. If you access either one of those addresses with Drupal - you'll get the page requested. Thing is - that means you have 2 unique URL's for the same content; AKA Duplicate content.

Global Redirect does a lookup on the current URL to see if it has an alias, if so it will redirect to that alias. In the above example, if you accessed node/123 Drupal would do a 301 redirect (permanent redirect) to pages/about-me thus telling any search engine's that the path its followed to that URL is permanently moved to somewhere else.

I hope this helps - if you'd like any further clarifications, please let me know!

What it means is that if you are on a page which has an alias, but you're not using that alias then it will redirect.

In THEORY it doesn't necessarily have to be an alias:node relationship. You could map an alias to a view URL such as taxonomy/term/12+15 (say the alias is tag/sunset-photo). Now if you were to access the alias, all is fine (Drupal tries to do a lookup but fails to find one) however if you were to access taxonomy/term/12+15 then Drupal will see that the url_alias table has an alias for that system path.

In fact, IN THEORY, if you were to manually enter a URL into the url_alias table which mappped url1.html to url2.html then Global Redirect should direct those two across even though neither are system URL's (but thats theory).

hi
sounds like a nice module..but how does this work with speed?
does it reduce the speed of the page load due to more queries..
and u mentioned permanent redirect..does this mean that once if the redirect has been made then for any further trys by any user to go to that page..an automatic redirect will happen..and hence no more page load delays?

can i uninstall or disable the module and have things the same as they were before..meaning the permanent redirects will disappear?

pls let me know so that i can use this module :)

does it reduce the speed of the page load due to more queries..

Inevitably, any module you install WILL slow down the page load - even if its just inclusion of extra code which will need compiling. This module will, for every page load, have up to 3 more queries - all be it small ones. It will do a lookup on the current URL in the url_alias table to see if it has an alias. Thats one query. Another potential one will be to see if it has a slash on the end of the URL and, if so, do an alias check for that too but without the slash... For example, going to…

• example.com/node/123
• example.com/node/123/

…will both yield the same page - however only 1 is likely to precisely resolve to an alias. Global Redirect will do a check for an alias on a path without the slash (if a slash is on the end).

The final check GR does is in terms of the frontpage. If you were to set your frontpage URL to node/12345 and you were to browse to either its system or aliased URL - Global redirect should send you to the frontpage of your site. Again - this is to stop dupe content.

The module has been designed so that if a match occurs on a pattern then it will immediately redirect, rather than hitting the system for further matches. The order of checks are:

• Frontpage check
• Alias check for current path
• Alias check for current path minus trailing slash (if present)

One thing to bear in mind is that as this module uses the drupal_get_path_alias function, it is likely that Drupal itself will have already done the lookup on the current URL to convert it to the system URL anyway so it knows what to do with the URL in terms of menu callbacks… or at least if it hadn't done it already, it would need to do it at some point anyway and as http://api.drupal.org/api/5/function/drupal_get_path_aliasdrupal_get_pat... uses drupal_lookup_path which cache's its results, its possible that the hit is simply made earlier rather than later. I think this only may apply to the direct URL lookup though. I would expect the frontpage check and optional slashed check to add to the page load.

u mentioned permanent redirect..does this mean that once if the redirect has been made then for any further tries by any user to go to that page..an automatic redirect will happen..and hence no more page load delays?

This means it does a 301 redirect. Drupal, by default, will do a 302 redirect when you use drupal_goto(). Maybe some browsers will cache that a certain URL did a 301 to another - I don't know. What it really means is more status in nature. It tells Search Engines like Google that the URL has permanently moved somewhere else and should no longer be considered existing at the current URL. Compare the differences here:

• 302 (www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3)
• 301 (www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2)

can i uninstall or disable the module and have things the same as they were before..meaning the permanent redirects will disappear?

This module does nothing to change the system - it simply adds in a few checks during a "bootup" of a page using hook_init. There is no 'uninstall' as such as it doesn't need one. If you want to go back to the way things were (say, for example, if you expose a bug which needs fixing) then simply disable the module from your module administration page.

I hope this answers your questions - if not, shall we try to take them to a new support request post as this one was originally about clarifying the definition of the module rather than specifics about how it works.

Thanks, Nick

I am noticing a problem with how Google indexes my site, and I wonder if this module will help.

When it comes to duplicate content, an article could exist on the front page (for a while, until it is pushed on to the next page by additional content) and under any of the taxonomy pages it is listed under (I often use multiple tags for a single article) and under any multiple URL aliases that might exist in the system.

What I am seeing is that Google is directing search results to one of the taxonomy summary pages rather than to the clean URL for the article itself. The main problem with this is that the article may have been pushed off the first page of the taxonomy listing, and besides, visitors have to hunt for it, rather than just arriving at the article they were looking for.

Will this module help? If not, how can I make sure that search results are always directed at the clean URL for the article, not to any other page?

Thanks

Can you please open this in a new issue... This issue is marked as fixed.

Oh, you are right, I missed the "fixed" status.

I've opened a new issue.