This is my first issue submission to Drupal, so please be gentle. I tried searching and found no reference to this issue anywhere.
I've been playing with a new node-type, one that can accept parameters in the URL. For pretty URL's, I've followed the convention of just appending the parameter onto the Drupal URL and using the arg() function to retrieve the parameter.
For example, my custom node type id is 2, so my URL is '?q=node/2'. With a parameter, the url becomes '?q=ode/2/1', with the parameter being the '1' tacked onto the end. When accessing the node via this URL, the parameter is easily pulled from the URL with the 'arg()'; function.
The problem appears when I turn on the Path module and assign a URL alias to '?q=node/2'. Through the node -> edit screen, I assign the node the alias '?q=custom_alias'. When I access the node with "?q=custom_alias, the node appears and everything is fine. When I try to access the node using "?q=custom_alias/1", I get a 404.
I'm running Drupal beta 4. To recreate this issue, ensure the path module and php filter are enabled. As user #1, create a new page and enter the following content:
<?php
echo "<pre>";
print_r(arg());
echo "</pre>";
?>
Assign the new node a custom url alias, and then try the test with the following urls, assuming your node id is 10 and your alias is 'custom_alias'.
"?q=node/10/1"
"?q=custom_alias/1"
The second should result in a 404.
If this problem is confirmed, I'd be happy to write a patch to fix it. As I said, I'm learning about this process, so please be gentle. :-)
Thanks,
Mike Hostetler
Comments
Comment #1
Crell commentedThat's actually how the path aliasing system works. It aliases the entire path, not a subset of it.
When a request comes in for custom_alias, The very first thing Drupal does is look up the exact string "custom_alias" in the path table. If it finds a match, it replaces the incoming query with whatever custom_alias maps to. Any code then sees only that "internal path".
If you request custom_alias/1, then Drupal looks up "custom_alias/1" in the path table. It presumably finds nothing, and so doesn't alter the requested path. The menu system then looks for a handler attached to the internal path of "custom_alias/1", finds nothing, and issues a 404.
While I agree that sub-path aliasing would be nice, it can also get very complicated very fast. Complicated means slow, and for something that happens at the start of every page request slow is a bad thing (unless we can get some major performance gains elsewhere).
If you can come up with a non-slow way to do sub-path aliasing, we'd love a patch for Drupal 7 when it begins development. Until then, this is by design.
Comment #2
gregglesI get this bug report a lot related to pathauto. Someone creates an alias for user/1 to user/admin and then they assume that user/1/contrib_module_path will be aliased to user/admin/contrib_module_path
I think this is a known and accepted limitation of Drupal and we should welcome someone who wants to fix it. Probably part of that willingness to accept it is the potential complication that Larry mentioned, but I don't think "complexity === slow" in this case. At least that's not completely for certain.
For one thing, it would improve performance of url_alias system greatly.
Pahtauto currently provides aliases for (among others)
user/1
user/1/tracker <- no longer needed if this feature were added
blog/1
blog/1/feed <- no longer needed if this feature were added
taxonomy/term/tid
taxonomy/term/tid/feed <- no longer needed if this feature were added
etc.
If you go crazy with user related contrib there may be 8 additional aliases per object that would no longer be needed if this feature were available.
Reassigning to feature, and to 7.x since 6.x is not the right home for this now. It's hard to say what the right component is since this is a mix of the path system and also the menu system's router function. Leaving as base for lack of a more accurate area.
Comment #3
smk-ka commentedFWIW, I just released the Sub-path URL Aliasing module, which acts as an add-on to core's path rewriting, yet keeping an eye on performance. It basically tries to match the longest sub-path for any known alias, anchored to the beginning of the URL.
Comment #4
alexanderpas commentedsubscribe
Comment #5
bleen commentedsubscribe
Comment #6
Crell commentedI can't see anyone getting to this in Drupal 7. Someone can try again in Drupal 8.
Comment #7
alexmoreno commenteda fast solution could be using path_save(), as I comment here:
http://stackoverflow.com/questions/4811065/drupal-how-do-i-programatical...
Comment #8
alexmoreno commentedI have some code working for Drupal 7. The approach is simple, the admin selects which arguments wants to attach to their pages (for example prices, similar,etc ), and then the module creates an alias for that (ex. one-product/prices).
I'll try to commit it soon.
Comment #9
panchoThis is very intersting functionality for core inclusion. It really feels like a blank spot in core's path aliasing.
http://drupal.org/project/subpathauto will certainly be a good starting point.
However for core inclusion we need to figure out a way to resolve alias collisions with an easy, straightforward UI, i.e. without blacklisting or whitelisting. And we need to keep an eye on performance.
Comment #18
afagioli