Extend the url alias capability

node.module inserts a callback for node/11/edit in node_menu() and without that in place the local tasks won't be created. The backtrace for the call to node_menu() is:

node_menu(false) file: unknown line: 0
call_user_func_array("node_menu", Array[1]) file: /home/mel01/public_html/drupal47/includes/module.inc line: 192
module_invoke_all("menu", false) file: /home/mel01/public_html/drupal47/includes/menu.inc line: 1144
_menu_append_contextual_items() file: /home/mel01/public_html/drupal47/includes/menu.inc line: 220
menu_get_menu() file: /home/mel01/public_html/drupal47/includes/menu.inc line: 333
menu_execute_active_handler() file: /home/mel01/public_html/drupal47/index.php line: 15

As you can see, the callbacks are inserted from within menu_get_menu(). Which is called before you expand the alias.

The attached patch parses the query string and replaces the first (i.e. longest) alias it finds. It does this before the menu is built, so modules have access to GET['q'] containing the internal path and callbacks can then be registered properly.

It's not quite as elegant as yours, requiring the $path to be parsed twice. But this is only done once per page view so the performance hit should be minor.

Can this break anything? All it is doing is converting GET['q'] to what it would be if URL aliases were not enabled.

Going to put this on hold for 4.8.

I agree... there needs to be changes right throughout core to take advantage of this feature. Best to hold off.

I'd like to toss in my vote for 'put it in, this hurts nothing and helps a lot.' Modules that accept parameterized urls are essentially un-aliasable in drupal at present. Views.module in particular -- one of the most powerful tools since ecommerce, in my opinion -- would benefit greatly from this patch.

Is there any reason to keep this OUT of 4.7, other than minimizing changes for the beta?

bumping postponed issue to HEAD.

I guess that there could be a performance issue from this patch due to the call to drupal_get_normal_path which eventually does a query. But, it's a query on a unique index so it should be quite fast.

Ever week there is about 1 support/feature request for this exact feature in the Pathauto issue queue. Adding this would be a feature worthy of mention in the CHANGELOG.txt in my opinion.

Reviewed patch 1 style fix for string concatenation and one unit test fix in the taxonomy module on a dangling / for a path on a drupal post. Will write additional unit tests for coverage of this if anyone has specific ones theyd like to see covered please speak up.

Crap sorry, reviewing too many patches on my desktop. (that is a good thing right?!?!) Here is the patch for the issue please ignore the previous patch.

Is the test you mention in #15 implemented? Because that exact functionality does not work for me, though it could be a local problem.

I like this feature. Neat!

Very nice, subscribing.

Lovely. I'd love an inline comment explaining WTF is going on.

This is a lovely, lovely feature. I have to say it seems a little odd to query the database six times for a path like admin/build/views/edit/myview/somearg. I guess greggles is right in #10 that it's a query on a unique index so it shouldn't be much of a hit, but it just feels wrong. Would it make sense to instead pass an array through drupal_get_normal_path to drupal_lookup_path?

Great functionality!... but I agree that it would make more sense to put the code in drupal_lookup_path(). Not only would that open up the possibility of optimizing the database calls, but also, it would allow people who call functions like drupal_get_normal_path() and drupal_get_path_alias() to get this aliasing functionality also, which I assume is the desired behavior? (The way the patch works now, if you have an alias pointing from my/url/alias to node/1, then visiting my/url/alias/edit in the browser gives you the edit page, but clicking on the "edit" link itself still sends you to node/1/edit...)

Also, although this feature is very useful, I can imagine situations where someone might want to turn it off. If I have an alias pointing from my-amazing-site-dashboard to admin, maybe I don't want every single path underneath admin to inherit that alias too? (If this turns out to be complicated, I definitely wouldn't want to see the patch held up for it, but it could be as simple as adding an extra column to the {url_alias} table. No need for core to provide a user interface for it, IMO.)

Looks like solving David's original request, that all outbound links have these nice aliases, is a major performance hit. It is also a prerequisite IMO. We need some fresh ideas on this one.

Working, but different implementation: http://drupal.org/project/subpath_alias

Bumping to 8.x.

Does this belong to core anymore?

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Wow Drupal 4?!? Is this still a valid request?

It's still valid but it should probably be won't fix for core - the performance issues look unsolveable and it would have to be opt-in to avoid conflicts between implicit and explicit aliases.

Thanks @smustgrave for the queue maintenance and the trip down memory lane. It looks to me like subpathauto is the current contrib option for people who want this feature.

Thanks for following up!