Get Sub-pathauto working with Global Redirect

Subscribe.

Subscribe

subbed

Most recent release of Global redirect seems to have resolved this issue (we were experiencing a redirect loop but now we are not). Can anyone else verify?

I'm using the latest stable releases of subpathauto and global redirect, and my subpath pages are NOT being redirected by global redirect.

EG user/1/my-view is NOT redirecting to user-name/my-view automatically. Both paths are accessible.

Last devel version of this module and the las version of global redirect

When I try to go user/user-name/edit I will receive access deny

did anyone managed to solve this problem?

I've tested this with the latest dev releases of both Sub-pathauto and Global Redirect and this is still an issue.

An easy test case for this is:

• Enable the Global Redirect and Sub-pathauto modules.
• Set up an alias for nodes (example: node/[nid] --> content/[title])
• Verify Sub-pathauto is working by going to content/[title]/edit . This should load the node's edit page.
• Verify Global Redirect is working by going to node/[nid] . This should redirect to content/[title]
• Go to node[nid]/edit . This should redirect to content/[title]/edit but it does not.

Is there any chance of a fix for this issue?

I've been looking for a solution to this issue for a few days and I think I've come up with a potential fix. Hopefully the maintainer of this module and/or the community can weigh in and see if this makes sense.

In a custom module, I added a function:

function mymodule_init() {
  $alias = subpathauto_lookup_subpath('alias', current_path(), current_path());
  if (!empty($alias) && $alias != request_path()) {
    drupal_goto($alias);
  }
}

This is essentially what Global Redirect does to redirect the standard Drupal paths - this is just doing the same thing specifically for Sub-Pathauto paths. Any thoughts on this approach? Perhaps we could add this function to Sub-Pathauto (possibly with a configuration option to enable/disable it).

Marking as Needs Review to see if the approach in #10 resolves this issue for anybody else.

Approach #10 works for me!

(how many 'works for me' are needed?)

#10 should be:

function mymodule_init() {
  $alias = subpathauto_lookup_subpath('alias', current_path(), current_path());
  if (!empty($alias) && $alias != request_path()) {
    drupal_goto($alias, array(), 301);
  }
}

For a patch to be committed to the module there first needs to be a patch.

No amount of "works for me"'s will help without the patch.

Setting back to "Active" until there is a patch to review as per https://www.drupal.org/node/156119

why?

Because module maintainers commit patches, so if there isn't a patch there is nothing to commit.

Issues with patches will almost always get preference from a maintainer than ones without and issues with already reviewed patches will get an even higher preference.

There are just too many issues for most maintainers to do every issue in their queue.

If I end up needing a fix for this I will make a patch but otherwise I probably won't get to it.

There is information on how to make patches at https://www.drupal.org/patch/submit

Moving issue to Global Redirect.

Thanks to Andre-B & jlapp, I've been using #10 & #13 during the past few months. And special thanks goes to KeyboardCowboy for providing the patch, as #20 works flawlessly for me. Thank you all.

@KeyboardCowboy, the patch doesn't work with multilingual site with language detection by prefix. Look for the next values dump before the patch changed lines on ru/node/12/edit page requested:

var_dump($request_path); // 'ru/content/test/edit'
var_dump($current_path); // 'node/12/edit'
var_dump(current_path()); // 'node/12/edit'
var_dump($alias); // 'content/test/edit'

and in this case we get infinity redirect loop.

As for me, the problem is in $request_path rewrite - it should be the same, user requested in browser path, to allow globalredirect work as expected. There is also a chanse, that other modules, that alters outbound URL path, can break globalredirect module with $request_path rewrite. Also, the same variable is stored to hook_url_outbound_alter() as $path and $path_original - that is incorrect.

So I propose to fix the issue with $request_path protection. The patch is attached.

Per #22, the patch in #20 doesn't work with multilingual site with language detection by prefix.