While this is a case of data in an unexpected state, it causes a difficult to track down problem.
After manually importing some url_aliases using SQL I ended up with a records where both src and dst were blank. After that, my client complained that they got the error message "The path is already in use" when trying to save a node which I easily reproduced. You can reproduce the problem by running this SQL code:
INSERT url_alias SELECT 0,'',''
It took a while, but with my PhpED debugger I was able to track down that line 218 in path.module where the line containing the following SQL query was the culprit, falsely reporting the error message:
case 'validate':
$node->path = trim($node->path);
if (db_result(db_query("SELECT COUNT(dst) FROM {url_alias} WHERE dst = '%s' AND src != '%s'", $node->path, "node/$node->nid"))) {
form_set_error('path', t('The path is already in use.'));
}
Although there are other potential workarounds that would actually clean the data I'd like to suggest a patch that I think would work around this problem and not give users an unrelated error message that is hard to track down:
case 'validate':
$node->path = trim($node->path);
if (!empty($node->path) and db_result(db_query("SELECT COUNT(dst) FROM {url_alias} WHERE dst = '%s' AND src != '%s'", $node->path, "node/$node->nid"))) {
form_set_error('path', t('The path is already in use.'));
}
Note that I added !empty($node->path) and to the if statement's conditional expression.
HTH.
Comments
Comment #1
EvanDonovan commentedThis fix worked for me even though I wasn't able to find any cases where src & dst were both "" in our DB. However, I did notice that now when I submit pages of a particular content type (Volunteer Opportunities - a CCK content type we created) that have URL aliases already, their URL aliases are lost.
Comment #2
EvanDonovan commentedBumping this up to D7. Does anyone see any problems with adding this?
Of course, the "patch" would need to be re-rolled...
Comment #3
mstrelan commentedI just experienced this issue in D6. The src was set to node/150 but dst was an empty string. Deleting that record solved the problem. It would be good if we could track down how an empty dst gets inserted.
Comment #4
attiks commentedMoving to Drupal 8 first
Comment #5
cweagansUpdating tags per http://drupal.org/node/1517250
Comment #6
xjmComment #15
quietone commentedThere are three reports of this issue. The first is the original, against Drupal 5.7, then a comment confirming the fix suggested in the IS and another one for Drupal 6. There are no reports for a current version of Drupal.
A look at the suggested fix for path.module in Drupal 7 shows that the validate function has changed and does include a check that the path is not empty.
Since there are no reports of this problem for a current version of Drupal, closing this as outdated.
IIf you are experiencing this problem reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").
Thanks!