I just went through a bout of weirdness with path_alias_xt not working in a site I was upgrading from D6 to D7. A whole bunch of dsm()s later, I found the problem --

The module was in fact working the way it was supposed to, using my User Path pattern of "people/[user:name]" to turn links like 'user/1/edit' into 'people/joerandomuser/settings'. But this ONLY happened for users other than the logged-in user -- those links remained unchanged. (Of course, it took a long time to discover this, since I was looking at links on my own, logged-in user page.). I finally tracked the matter down to some code in path_alias_xt_get_extended_path_alias():

    if ($matches[1] == 'user' && $matches[2] == $user->uid) {
       // For logged-in user rather than applying 'user/%' alias, return 'user'
       // alias, if it exists.
      $internal_path = 'user';
    }

What is the point of this bit? Why would I not want my own link to map from 'user/1/edit' converted to 'people/joerandomuser/settings'? Beyond that, if this code is in place, the subsequent call to drupal_lookup_path() will only return anything if I've defined an alias that maps 'user' to 'people', and that will screw up all sorts of things. I'm puzzled, to say the least.

For the moment, I've commented out this bit of code, and now things are working the way I was expecting them to. But, in the bigger picture, I'm very confused; apologies if I'm sounding a bit overwrought. Can anybody explain what this code is supposed to do, how the module can work properly with it in place, and if I'm opening myself up for something by commenting out the above section of code?

Comments

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi Jim,
Not with a development environment at the moment, so can only comment on the intent of the module in this respect, not whether it's working that way...

It was a feature request explained in the FAQ at the bottom of the "Extended Path Aliases" project page and also here: http://drupal.org/node/808438#comment-3013352

Clearly not everyone likes it... If it "screws up all sorts of things" I may have to revert this feature.
Rik

jim_at_miramontes’s picture

jim_at_miramontes commented

Let me try to describe what I've found with a bit less frenzy and to make sure I've got the right understanding of all this... :)

To restate the overall situation: if I set up a URL Alias "Pattern for user account page paths" as something like "people/[user:name]", then the basic URL Alias system will map "user/123" to "people/joeuser" (and do comparable other things for all the other users). path_alias_xt is meant to extend this logic to other paths coming off user/n, so that "user/123/edit" would become "people/joeuser/edit". Cool; certainly the Right Thing.

Now, re the code in path_alias_xt_get_extended_path_alias(): If I hit a path that is associated with some user other than myself (the logged-in user), then the test:
if ($alias = drupal_lookup_path('alias', $internal_path, $path_language)) { ... will successfully find the alias for "user/123" set up by the URL alias pattern -- "people/joeuser" -- and ultimately return this alias with the matching bit tacked onto the end: "people/joeuser/edit". Right.

But now, if I'm generating a page with a link to my own stuff, the code in question will run and change $internal_path from "user/123" to simply "user". This will make the if ($alias = ... test fail, since there is no alias just for the path "user" in the standard configuration of the module. Thus $path is unchanged, and we get "user/123/edit". This means we can get different aliasing behaviors on the same page (and across users!), depending on who the link happens to be pointing to.

The "screwing up" I was referring to in my original note was the loss of the username in the path, which I wasn't expecting / didn't understand, and I wasn't sure (and am stil not sure) what impact that would have on getting to things like /user/password and the like. Anyway, having read the post you pointed to (http://drupal.org/node/808438#comment-3013352), I can kinda see what the guy would like to happen. But it strikes me that this is pushing the standard operation of the module off in a special-case direction, and not a particularly obvious one. It also requires setting up some hand-crafted and also not-real-obvious aliases, which are only documented in the Drupal discussion boards.

Anyway: if it were up for discussion, I'd pretty clearly vote for going the other way. But I can get what I want with a pretty trivial patch to the module (now that I know where to look :), so I'll survive.

Meanwhile, thanks a lot for putting the module together in the first place! It's so obviously the Right Thing, I'm not sure why it's not in Core.

rdeboer’s picture

rdeboer
Location Melbourne
commented
Assigned: Unassigned » rdeboer

Hi Jim,
Thank you for your clear, analytic comments. Makes sense, I see where you're coming from.
I may adopt your patch, i.e. revert to a simpler, less confusing operation.
Thanks for your kind words and liking the module!
Rik

rdeboer’s picture

rdeboer
Location Melbourne
commented
Status: Active » Fixed

In 7.x-1.x-dev (soon to become 7.x-1.1) this is now a configurable option. So no more fighting ;-)
Rik

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.