"Forced" path redirect - override the existing path or alias

Seems like many use cases would be to redirect valid urls from one place to another (only reason i need it). It seems like we're being over cautions to put any limitation on this, I mean the admin could always undo it from the DB if they did something really messed up like redirecting /user (though perhaps you might want to do that exact thing).

In fact the help text suggests that you can do this.

The project page says "This module allows you to specify a redirect from one path to another path or an external URL" - no mention of a limitation.

The path field help text says: "Enter an interal Drupal path or path alias to redirect (e.g. node/123 or taxonomy/term/123). Fragment anchors (e.g. #anchor) are not allowed." - again, no mention of a limitation.

The list page says "Here you can set up URL redirecting for this site. Any existing or non-existing path within this site can redirect to any internal or external URL." - definitely suggesting that you can use "existing" paths.

Is this limitation new?

We do need to provide some kind of protection for overwriting existing paths, which this issue will accomplish with a two-step form process, but still allow you to do it.

The limitation is not new, but it's best practice that existing paths should not have redirections, they should have aliases (and you can use global redirect in order to peform redirections from alias to path).

Hi Dave, could you describe this best practice in a little more detail or point us to another post? Im trying to get things like "taxonomy/term/id" to redirect to an access denied page or a homepage and I need to do it on several node pages as well (full post at http://drupal.org/node/618824). I imagine many other pseudo-newbies like me would be really grateful if you could give us further clues... Many of us look into Path redirect and start getting the "You cannot create a redirect from a currently valid path" error.

How does Global redirect perform redirections from alias to path?

Thanks!

I suggest an access role, so only admin and privileged users can use forced redirect feature.

If root user caught XSS, it doesn't matter, as he will able to change anything in any case, so what for we should make some special logic? Plus, on 99% of sites only admins are the people who manage redirects, so why should we provide more access? To get them even more rights, which they already have? As for me, max. we should do it's provide very noticing warning if user wants to make dangerous redirect (/admin/* → ..., /user/1/* → ...).

I guess admin can grant access to path redirect for specific users, in that case a different rule might be useful.
But anyway i'm agree that a warning is a useful reminder

Hi everyone, I wrote comment #3 because Im looking for a way to do some of these "valid path" redirects (since it doesnt seem possible to tell Drupal not to create those paths from the start to avoid all this hassle).

How can I tell "taxonomy/term/id" to redirect somewhere else? I dont want those pages to be seen (or indexed).

+1 for this. Here's our scenario:

the 'taxonomy/term/%' path is good for most needs, but for a handful of terms (all in the same vocabulary) would like to use a view to override how they look.

It is possible to use a view to override all term output (this is what the disabled-by-default taxonomy term view does) but this isn't what we need as it's an all or nothing case and we only need a single vocabulary (or handful of terms) overriding.

I can set up a view on some other path, eg: 'some_other_path/%' and use taxonomy names as an argument (eg: 'some_other_path/term-name'. This is great with the exception of the taxonomy links under nodes always link to 'taxonomy/term/tid'.

Hence, I'd like to setup a handful of redirects from 'taxonomy/term/tid' -> 'some_other_path/term_name'.

In the absence of a better solution I made a small module and used hook_term_path to place alternate URLs to those the default taxonomy module would use.

Re: #8... scrub that, there are two further options that aren't really anything to do with paths but achieve the same result so will post as someone might find them handy:

1. Override each specific taxonomy term with a view. Not nice as you have to create a page override for every term.

2. Create a custom module for and menu entry for 'taxonomy/term/%my_tid_check'. Create a my_tid_check_load function and have it return FALSE for any tid that you aren't interested in. Then the page callback you specify will only be called for terms you want. Have that callback return the output of views_embed_view using the argument given and you're done.

Option 2 is definitely the better of these two and is what I have used.

Adding tag.

Merging the idea from #511322: Redirect setting to overrule path-alias into this issue. The idea is to allow the redirect creator to decide if instead of overriding an url alias, to delete the alias when creating the redirect instead of just overriding it. Not sure what I think of it yet however.

I've been thinking about this more. Current core's path alias lets you create an alias on any path. I could create an alias from admin => 'node/1'. Maybe we just need to reconsider loosening this up completely and only validating creating redirects with the same path as aliases should not be done.

I just wanted to add a case that I've come across where I've wanted to override a valid path.

We have a site that was migrated to Drupal from a static HTML site. It seems there are a lot of crawlers and bots out there that still have old .html pages in their indexes and keep trying to hit them on the new site where they don't exist. I haven't recreated all the old .html pages on the new site but I have a place where I want to redirect crawlers to.

The problem seems to be that I have a valid Drupal path that contains the same word as the beginning of the old .html path.

I have this:

domain.tld/name-of-page

The crawlers have these sorts of paths in their indexes:

domain.tld/name-of-page/some/outdated/paths/to/pages.html

I can't add a redirect from the .html path to anywhere else because the initial directory in that path exists now as a path in the Drupal site. (And they don't have anything to do with each other.)

Hope this example is relevant to this discussion, and if anyone has any other suggestions for me, I'd welcome them.

Subscribe

when creating a redirect, the from field description is "Enter an interal Drupal path or path alias to redirect (e.g. node/123 or taxonomy/term/123). Fragment anchors (e.g. #anchor) are not allowed."

If we cant do this, the description is wrong. right?
and why the autocomplete? what's it looking for if it can't exist already?

when creating a redirect, the from field description is "Enter an interal Drupal path or path alias to redirect (e.g. node/123 or taxonomy/term/123). Fragment anchors (e.g. #anchor) are not allowed."

If we cant do this, the description is wrong. right?
and why the autocomplete? what's it looking for if it can't exist already?

I have to completely agree with this. I was under the impression that redirects should be used for paths that do not exist to an existing path. The way the functionality seems to work now with the instructions indicate something else.

Why would we redirect from a currently valid path to another currently valid path? Isn't that what path aliases are for?

If you'd actually look into it, the autocomplete lists paths of 404 errors on your site, not actual pages.

I'm still unable to redirect urls that only contain query string like "mainid=5" => "/node/255". So here is the require code for making it work.

In path_redirect.module after "function path_redirect_load_by_source($source, $language = '', $query = array()) {" :

if ($query) {
    $source=str_replace('<front>','',$source);
    $source.='?'.urldecode(drupal_query_string_encode($query));
}

@sinasalek: Your 'from' path should be entered as <front>?mainid=5

Thanks Dave, that's great , i confirm that it works now.
Query for fixing the records :

UPDATE `path_redirect` SET source=CONCAT('<front>',source) WHERE source LIKE "?%"

Why would we redirect from a currently valid path to another currently valid path? Isn't that what path aliases are for?

If you have conditional redirect, which was discussed in related queues, it's more than useful. E.g. redirecting authenticated users from "/user/register" to "/user"

I'm definitely in favor of this. I ran into a situation where I have a summary view at /category and listings of things per-category at /category/%. I had to rename a cateogry, and wanted to be able to redirect from /category/foo to /category/foobar, but it won't let me since both /category and /category/% are technically valid paths, even though for arguments that don't validate in views, you still get a 404. I haven't read the whole thread closely yet and all the various proposals, but it sure seems like admins should be able to add redirects like this. If I get a chance to think about this more, I'll write up a more solid proposal.

Thanks,
-Derek

subscribe. I need this because I have a panel that uses two nodes. However, google is indexing the nodes instead of the panel. I want to have the view of the node be redirected to the panel.

Subscribe, definitely needing this, for example to redirect all requests to /node to go directly to front

+1. I need this because I use Panels to display my homepage. Panels makes you create a unique URL for it, so I did "home". In turn, Panels changes your "default front page" setting at admin/settings/site-information to "home". I then expected /node to redirect to /home, which redirects to /, but nope. Then of course tried to redirect /node to /home with Path Redirect, but nope: "You cannot create a redirect from a currently valid path."

I'm need this for redirecting my old site links to their alternatives on the new site in proper way.

I need this for exactly the same reason as @sinasalek in #26

+1

subscribing

It works fine if you just comment out the validation in path_redirect.module -- I've been using that fix for a while now.

My only complaint is that it uses $_GET['q'] so you have to enter the internal URL when creating the redirect from an aliased path. I tend to redirect vanity or placeholder URLs, but if I come back later and create a node with that alias (i.e. to build out a site IA or menu hierarchy), the redirect no longer works. Using $_REQUEST['q'] fixes that issue, but I don't know if it breaks anything else. Maybe that design was intentional, but it seems like a possible bug that the module isn't checking the aliased URL for a redirect before checking the internal URL.

+1

subscribing

Subscribing.

Here is another use case: I have a news content type I use to create a series of news items. I use a view to display the news items and their teaser on the front page. For most news items, clicking on the title takes you to the full node. Once in a while however I want a news item to take you not to its node but to another location. In the past I have used path redirect for these with no problem. The last time was for a news item in July 2009, so I assume the existing url check is a relatively recent addition that came after that.

So yes it would be nice to have the option to do that again use path redirect...

Doing this with aliases is messy... Example:
1. I want an alias for node/55, so I create alias, for instance superduper;
2. Later I create node/73 for instance. I want node/73 to redirect to node/55. I can indeed create another alias for node/55, and call it node/73, and the redirect will work BUT now with globalredirect the url on top shows node/75, not superduper because it is using the latest alias that I created...

Here's a case where Drupal sees a URL as valid, that is not and I want to override it. Maybe I'm doing something wrong in Views, but I can't find an explanation to save my life. I have a views page at http://myurl.com/list-articles, where I display a list of articles. I have a content type article, that I set the default URL to http://myurl.com/list-articles/article-title, and the article displays. If I append anything to the article url like http://myurl.com/list-articles/article-title/any-text, If defaults me back to the view page. The same thing occurs if I were to misspell an article title such as http://myurl.com/list-articles/article-tytle. I can set null arguments in to force a page not found, but when I try to redirect a url under these circumstances, I can't because Drupal sees it as a Valid URL. This also has consequences for indexing content. With Google Search appliance, you page per page, and views like this can get into infinite loops, and return the same page many times as search results if you don't take precaution. I realize that this may be a views issue, but I'd really like to quickly solve my main issue of overriding a valid URL.

Thank you.

subscribing.

I got this from a view where extra arguments are silently ignored, which means that path_redirect sees it as a valid path :/

jrstmartin use node.tpl.php and drupal_goto() function

pd: Subscribing!!!!

Comment lines 426 to 430 from the file path_redirect_admin.inc

Then the validation about existing paths disapear.

/ Cannot create redirects for valid paths.
//$menu_item = menu_get_item($element['#value']);
//if ($menu_item && $menu_item['page_callback'] != 'path_redirect_goto' && $element['#value'] == $menu_item['path']) {
// form_error($element, t('The source path %path is a currently valid path. You cannot override existing paths. You can however, create URL aliases for them.', array('%path' => $element['#value'])));
//}

Subscribing, Would be great if this override possibility would become an option within path_redirect!
EDIT: Latest beta7 allows this. Great!
greetings, Martijn

subscribing

I needed this, and it looked easy enough to patch. Unfortunately I went through the effort of patching this without first updating to the latest path_redirect, so this is a patch against beta4.

edit: this patch adds a setting "Allow redirects from valid paths"

Hi, did you read my edit. Latest beta 7 already has this inside!
greetings, Martijn

Comment lines 426 to 430 from the file path_redirect_admin.inc

worked for me with RC2

Latest beta 7 already has this inside!

Have not found that in RC2... ?

Use case here:
We have two views pages, each for one language, and we want to have two different aliases per language, thats not working without ovveriding each alias in the other language...

best regards,
sandro

thats not working without ovveriding each alias in the other language...

with "working" i mean that the language switcher is working as expected, linking to the other views page... :)

May I ask what happened with this idea? A comment above says it made it into beta 7?
I have rc2 and do not see it. Are there plans to work on this?

Thank you! :)

This most certainly has not been included yet.

I would like this feature aswell. My case senario is that i use panels troughout the whole theme. That way we can redirect user/$uid/edit/cat options to a panel page with a drupal_get_form inside them.

Another thing i would use this for is that i also use privatemsg_module in panels, by using the methode above (drupal_get_form()). But now my /messages* paths are not needed since i have created own paths. If i could force a redirect from /messages* to my own panel page path, that would be great.

I'm using 6.x-1.0-rc2 without the patch above but just realized that valid paths can be saved with an extra slash on the head of the internal path (which shouldn't be necessary). When it's saved this extra slash is automatically removed from URL.

For example,

From: http://my-site.com/ "my-page-view-path"
can't be saved but

From: http://my-site.com/ "/my-page-view-path"
can be saved and then automatically remove the slash. "From path" will be eventually http://my-site.com/my-view-page-path.

This is probably a bug regarding the validation but it just work fine. In my case I have two languages on my site Japanese and English. Japanese is the default language and English has the prefix "en". However I need to make some pages ( e.g. a views page and the front page ) available only in Japanese.So I decided to redirect the English page to the same URL but without the prefix "en" by setting the same path for "From" and "To", "language" = English. And it works fine for my need.

Adding the extra forward slash worked for me--I needed to redirect default rss.xml to custom site feed.

@chinita7 Thanks for the tip!

Thanks chinita7.

Thanks chinita7!

@chinita7: Saved the day!

Tried #48. It saves no problem but somehow it doesn't redirect as if nothing has happened.