Closed (duplicate)
Project:
Drupal core
Version:
9.5.x-dev
Component:
path.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
4 May 2012 at 15:53 UTC
Updated:
13 Jul 2023 at 23:33 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
kevin hankens commentedAdding patch.
Comment #2
gregglesPatch makes sense to me, let's see what testbot thinks.
Comment #4
gregglesThe failures are in PathAliasTestCase
Attempt to moved alias was rejected.
"The alias is already in use." found
I didn't dig in, but it seems like test is relying on this bug...?
Comment #5
kevin hankens commentedOh, that was my bad. I changed the dsm to have a more friendly message. The assertion was looking for the old error message.
This patch uses the old messages instead.
Comment #6
kevin hankens commentedComment #8
kevin hankens commented#5: path_validate_menu_router-1561372-5.patch queued for re-testing.
Comment #10
kevin hankens commentedI don't understand these failures, the only thing that changed from the first patch was the argument to form_error. Although, this did fix the path tests :) Any thoughts?
Comment #11
kevin hankens commentedIt appears that these five failures also happen locally on a fresh install /without/ the patch above.
Comment #12
moshe weitzman commentedI wonder if people use this feature to "take over" paths generated by modules.
Comment #13
chx commentedThanks for trying to fix this but the approach taken is not acceptable. Going around an API to work with a database table directly is, in general, wrong. Here, I would run
menu_get_item()first and then take a good look at the resulting$item['path']. This would deal with the problem of having a pathfooand an aliasfoo/bar. Something rather similar to http://api.drupal.org/api/drupal/includes%21path.inc/function/drupal_val... except you do not need to deal with dynamic path but need to be able to look at the$itemitself.Comment #14
gregglesHmmm, yeah, moshe is right. We shouldn't prevent that in path.module.
Comment #15
cweagansThere's already a good way to take over paths generated by modules. I don't think it makes any sense to allow somebody to create a node over the top of an existing menu_router path - at least, not without warning them.
Maybe this is a silly example, but what if somebody created a webform over the top of /user/login and started collecting user credentials from the users of the site? That would be less than ideal.
Comment #16
nmc commentedI'd like to see this "fixed" in core as well.
Along the same lines as @chx, why not do as Pathauto does in its _pathauto_path_is_callback?
Here's the revised version:
The second part of the code above seems ideal to me as well. That way we can avoid these situations: http://groups.drupal.org/node/20604
Comment #29
smustgrave commentedJust verified on 11.x that this can still happen.
Comment #30
smustgrave commentedActually seems like a duplicate