Can't use redirect paths as menu items.

This is really a menu problem and not a path_redirect problem per-se.

A possible workaround: create an alias for the path you want and point the alias at a random node. Create the menu item that points at that path. Delete the alias. Create a redirect.

Create the menu item that points at that path. Delete the alias. Create a redirect

Doesn't work. As soon as I delete the alias - the menu changes automatically to point to the node, not the alias.

+1 - i think it would be great if path_redirects could be used as menu items.

i often have the problem where i want two menu items to point to the same content, but i want one to be the "canonical" menu item that is used when menu-related modules make decisions that depend on where in the menu hierarchy a node is. i was hoping path_redirect would provide a workaround for this...

I need this because I have a non friendly landing url, which I also change sometimes, I have these menu links in a few places, so instead of having to change all occurrences - I tried to use redirect, so I could modify it in one place if I need.

HobbyBlob.com

This is really out of the context of the features path_redirect can provide, sorry. You are much better suited to add a menu item to your site's custom module to handle this for you.

As noted in #3, the solution in #1 doesn't work.

As noted in the original post, #4, and #5, this is a much-wanted feature. (I need it as well.)

Dave, I'd ask you to please reconsider including this feature as part of the path_redirect package. To help make the decision easier, I've attached a fully-functioning add-on module. It's very light-weight, but does require the (even-more-lightweight) patch in #1148476: Add an API similar to Drupal's standard for nodes, blocks, users, etc..

The add-on module does the following:

• When a redirect is added as a menu item, the menu module will no longer complain that the path "is either invalid or you do not have access to it", and will allow the redirect to be successfully added as a menu item.
• When the redirect is updated, the menu item will be updated as well.
• When the redirect is deleted, the menu item will be deleted as well.

In my opinion, this add-on module should come packaged with path_redirect. But if Dave disagrees with me, I hope someone will take the lead on spinning off the attached module as its own project. I do not have the time to do so myself, at the moment.

Again, please note that the attached add-on module DOES REQUIRE a simple patch of path_redirect as of now, which you can find at #1148476: Add an API similar to Drupal's standard for nodes, blocks, users, etc..

[Update:] I forgot to address the philosophical side, particularly Dave's comment that "This is really out of the context of the features path_redirect can provide". With all due respect, Dave, I think it is within the context. Any path that is made within a Drupal site should be able to be linked to within that same Drupal site (including via menus). (Of course, if we continue to disagree on this, spinning off the add-on module as a separate project is an easy compromise.)

Can you post that module as a sandbox?

IMO it is unlikely this belongs in path_redirect. This is really a core bug that should be fixed there, but I'd like to (easily) see the code to judge that.

Sure, check it out at http://drupal.org/sandbox/sbandyopadhyay/1153682.

Greggles, let's assume for argument's sake that the bug is in the core menu module. Even if that bug is fixed, a huge problem remains. Let me explain.

As best as I can tell, this is how the menu system works in D6:

1. A function like menu_overview_form() or menu_tree_all_data() is used to create and generate a menu tree. In doing so, these functions all run a query that looks up the menu_link's router_path in the menu_router table, and then use this router_path to pull in the access_callback (and access_arguments, etc). If the router_path does not exist, the access_callback comes back NULL.
2. Next, in _menu_tree_check_access() (which is called from menu_tree_check_access(), which is in turn called by the aforementioned functions), the menu $item is "translated" by _menu_link_translate($item). Skimming over the precise details for the sake of brevity, $item['access'] comes back FALSE if the access_callback was NULL (which happens when the router_path does not exist in the menu_router table).
3. When $item['access'] comes back FALSE, _menu_tree_check_access() drops the $item, and it is not rendered.

To see the huge problem, assume the following:

• There is one node, and it can be found at node/1.
• There is a path redirect from hypothetical/redirect/path to node/1.

Here is how the menu system will try to render this path redirect, if it were successfully added as a menu item:

1. hypothetical/redirect/path has no router_path, so the access_callback comes back NULL.
2. Since the access_callback was NULL, $item['access'] comes back FALSE.
3. Since $item['access'] came back FALSE, _menu_tree_check_access() drops the $item and it is not rendered.

The menu system fails to render our path redirect because it had no router_path.

So, solving the "bug" in the core menu module may be necessary, but it is not sufficient. We still need to give the menu link a proper router_path.

We could do this by:

• Creating a dummy menu item, <path-redirect>. [This is done in lines 7-15 of my module.]
• Dynamically prepending <path-redirect>/ to any menu link_path that happens to be a path redirect, so that <path-redirect> is used as the router_path. [See lines 51-56 of my module.]
• Dynamically remove <path-redirect>/ from the beginning of any link before it is rendered. [See lines 17-34, 41 of my module.]

This approach is necessary and sufficient to correctly render the menu item. This approach is also, coincidentally, sufficient to bypass the "bug" in the core menu module... because when a dummy menu item (<path-redirect>) is created, the act of dynamically prepending it to any path redirect path causes the validation to work correctly.

So, I'm not really sure that the bug in core, if there is one, needs to be fixed. It's the responsibility of path_redirect to offer a router_path that works, anyway.

sbandyopadhyay's fix from #7 is working well for me.

to weigh in on the philosophical conversation, the compelling reason for this feature is that drupal has a really hard time handling the common use-case of:
-wanting multiple menu items that point to the same node
-needing to specify which of the multiple menu items gets active trail when you're on the node (by default the menu item with the lowest mid gets the active trail).

so it's important that someone solves it (thank you!)

does it belong in path redirect? looking at the documentation, this module's stated purpose is to provide a *temporary* redirect, for urls that have an alias change - at some configurable amount of time after the last access of the redirect, the redirect goes away (by default, however, redirects are permanent).

this is more-or-less the same functionality that you get with path-auto when you set it to save a duplicate alias when an alias changes, except that you can configure the http status code of the redirect (for SEO purposes?) and that the redirect can expire, and that you don't have a really messy url alias table.

so, maybe my use case doesn't fit philosophically with path_redirect, but there might be other use cases that are met by the feature, that make more sense here?

another way to solve my use case without path_redirect would be to allow an admin to specify which of a set of menu items that point to the same path is "canonical" from an active trail perspective. that's not redirecty at all!

nodesymlinks sort of solves an opposite problem - it allows multiple aliases to a given path, and each alias has it's own active trail - so depending on which menu item you follow, you get a different active trail. maybe it would make sense to extend nodesymlinks to meet this use case.

thanks for listening, i know it's a little off-topic.

Glad you like it, firebus!

Greggles, looking forwarding to hearing your thoughts.

Meanwhile, with #1148476: Add an API similar to Drupal's standard for nodes, blocks, users, etc. fixed, we no longer have to apply the patch as noted in #7 above. But, for anyone looking to use this add-on feature, be sure to use a Path Redirect release dated May 19 or later.

subscribing, thanks.

I used the workaround in comment 1, but without deleting the alias. See http://mediatribe.net/en/node/47

Based on comment #12, does the 6.x-1.x-dev release now allow us to use redirect paths as menu items?

I have 6.x-1.x-dev installed but when I try to add a primary link menu item pointing to a redirect path, I get this error: The path 'my_redirect_path' is either invalid or you do not have access to it.

@todea: the dev release makes path_redirect compatible with my module from #7. You should use the dev release + the module from #7.

As this continues to be a requested feature, it would be great to get some resolution on this issue. I've got the add-on module ready to go, and I can post it as a separate module -- but only if the powers that be really don't want this as part of Path Redirect.

Thanks. Got it working after installing both parts as you said.

Just passing through and don't have this problem, but it'd be great if that zip was sandboxed. Courteous to reviewers :)

It's been sandboxed since Comment #9, at http://drupal.org/sandbox/sbandyopadhyay/1153682.

ack. my bad. sorry about that, but thanks man!

FYI, I've created a Drupal 7 version of @sbandyopadhyay's module at https://drupal.org/sandbox/sheldon/redirect_menu_item

re: #9
Another solution I stumbled across for something similar was to implement a menu load callback on a dummy menu item. See the documentation on Auto-Loader Wildcards at hook_menu(). If you implement your own loader and form alter away the drupal_valid_path() in menu_edit_item_validate(), then things work. The loader has to lookup and return the actual node id, but that isn't hard with db_select().