Path module allows one to override existing (non-aliased) paths.

I think just not allow to users change paths - this instrument is for site admins/editors only. Additional checks will slow down path module. If site admin want to allow users change paths to their own manner then such job must doing by separate module, which will offer interface for change paths with restrictions and additional checks.

When adrian said "user", he meant a site admin who is using one of our hosted installs.

The issue remains: anyone can alias "admin" or any other existing path, which will override existing pages.

" Additional checks will slow down path module." True. But IMO thats non-issue in the rare case of a path added. How will adding 100 aliasees a day (not sure if any site out there makes that) affect performance?
Performance issues on adminstrative functions should have a very low priority. Below all others like safety, useability and all.
For the rest: I agree upon a separate advanced path module.
We have more "unsafe" issues, such as people being able to add PHP, block themselves, block Superuser, etc. A line of documentation on this might suffice?

+1 for adding the menu_item_exists function even with its limitations that adrian has pointed out.

* When an additional module gets enabled, any already specified links will take precedence over the new links created by it.

Could you include a similar check when enabling a module. i.e. a function called from module.module that would look at the menu callbacks of the newly enabled module, check them against the menu array and post an warning on the admin/module page and add an entry to watchdog. Admins would at least be notified about the problem and could take appropriate action.

e.g. Warning: A path alias exists for $path. This path is in conflict with a registered path in the newly enabled module $module. This conflict will not allow module $module to function properly. The problem can be corrected by renaming $path to something else from linktoadmin/alias.

and watchdog could have something like a user error with a short description "path conflict" and a detailed message similar to the example above.

andre

How about setting a priority level as an attribute of the path item? Path module could use a lower priority than the default and thus "lose" any conflicts with existing paths. There are modules that need to override other paths and redefine the actions/access/etc for them. This would provide a means to support both of these needs.

This would also remove the current dependence on alphabetic module name preference for conflicting paths (later modules currently overwrite previous modules' path entries).

I tested this patch and it appears to work. It avoids having to iterate through the menu any more than necessary, and typically only adds one extra comparison to the process.

Modules would add an $item[n]['priority'] = -1; to the menu hook to keep from overwriting menu items with a default of 0. The only oddity that I've seen is that there are conflicts between cached and non-cached instances of a given path, though that could have just been from my testing.

When adrian said "user", he meant a site admin who is using one of our hosted installs.

I think only if the administrator has drunk a lot of beer, him can ovewrite 'admin' path. Don't drive if you drunken!

- 1 for patch which add uneccessary complexity to path module.

+1 for adding checkbox in site logon: "You are drunk today?" (instead of not worked "remember me"). This option will disable some "dangerous" functions like access to admin pages and so on.

I agree with the Anonymous user above: this is a useful feature and we should put in a warning instead.

I agree with Steven.

Is there interest in prioritizing menu path entries? This way, a module could explicitly override the path entries of other modules or allow other modules to override its own? Modules like path.module would need some way of setting this priority. Whether there's a user interface to override it or not could be discussed.

In the patch that I have above, the default path priority is 0. This could be changed for path.module to be -1 and all defaults would override anything specified in the path module. In the current state, there wouldn't be any indication that a path wasn't created, though. Any suggestions on what would be a good way to do this?

Should I bother moving forward with updating this patch?

No one has touched this in over seven months... I'm assuming noone is going to add the warning.