Steps to reproduce:

1. set "Create a new alias. Delete the old alias. " option
2. Go to Administer › Content management
3. Resave some term (even without changes)

Result:
Duplicate entry 'XXXXX' for key 'PRIMARY' INSERT INTO url_alias_extra (pid, dst, entity_type, entity_id, created_by) VALUES ...

This is because there’s assumption in the _pathauto_set_alias() that $new_pid returned by the query is always new one which is not always true. There should be more logic in this function to properly insert or update {url_alias_extra}.

  // Skip replacing the current alias with an identical alias
  if ($old_alias != $dst) {
    path_set_alias($src, $dst, $pid, 1, 10);
    $new_pid = db_result(db_query("SELECT pid FROM {url_alias} WHERE src = '%s' and dst = '%s'", $src, $dst));
    db_query("INSERT INTO {url_alias_extra} (pid, dst, entity_type, entity_id, created_by) VALUES (%d, '%s', '%s', %d, '%s')", $new_pid, $dst, $entity_type, $entity_id, 'Pathauto'); 
CommentFileSizeAuthor
#1 pathauto.inc_.patch2.67 KBvito_swat

Comments

vito_swat’s picture

Status: Active » Needs review
StatusFileSize
new2.67 KB

I think I found the solution. Changes need to be done in two places. One in pathauto_create_alias() to prevent creating feed aliases if alias for feed is the same as it was before. Second change is in _pathauto_set_alias() to properly insert or update {url_alias_extra} table.

Please test.

kmillecam’s picture

I patched 5.x-2.x-dev and did some testing.

I wasn't sure what vito_swat meant in step 3 above, "Resave some term (even without changes)" but since I was on the content management page, I opened a story node and saved it. No error.

I also made changes to the body and saved. No error.

HTH,
Kevin

greggles’s picture

Thanks for your help testing, Kevin.

The test is to visit admin/content/taxonomy click on a vocabulary to list terms. Edit a term. Save it. I think that is what triggered the bug previously.

kmillecam’s picture

Thanks for the clarification, Greg.

More testing: using the patched version,
I opened a taxonomy term's edit form and then saved it... No errors.
I opened a taxonomy term's edit form, made some changes and saved it... No errors.
I created a new taxonomy term... No errors.

HTH,
Kevin

greggles’s picture

Status: Needs review » Patch (to be ported)

Thanks for this, vito_swat. I've been testing it for a while and it worked fine in my testing.

After applying the image gallery patch this one had a hunk that failed, but I ignored that, did some tests and it seems to work well.

There was some extra cruft from the punctuation character comment that was left in there I'll need to remember to remove when I port this.

greggles’s picture

Status: Patch (to be ported) » Fixed

committed to HEAD as well.

MiMe’s picture

Status: Fixed » Active

Error still exists. From clean install with token and patuahto enabled + clean urls.

1. Create a story named "testing"
2. Remove that story
3. Create a story named "testing" --> error

The URL alias "content/testing" is never removed from the database table "url_alias_extra" when it should have been upon user/admin delete.

MiMe’s picture

Priority: Normal » Critical

Changing to critical

MiMe’s picture

Possible fix:

In function pathauto_nodeapi{...
add last in the case 'delete' before the break:
db_query("DELETE FROM {url_alias_extra} WHERE entity_type = 'node' AND entity_id = '%s'", $node->nid);

in function pathauto_taxonomy{...
add last in the case 'delete' before the break:
db_query("DELETE FROM {url_alias_extra} WHERE entity_type = 'taxonomy' AND entity_id = '%s'", $category->tid);

in function pathauto_user
add last in the case 'delete' before the break:
db_query("DELETE FROM {url_alias_extra} WHERE entity_type = 'user' AND entity_id = '%s'", $user->uid);

greggles’s picture

Status: Active » Fixed

Well, no the scenario that vito_swat was talking about is fixed.

The scenario that you describe should be fixed in the existing issue for it: http://drupal.org/node/206461

Also, can you provide your ideas as a patch?

Fayna’s picture

Is there a patch for MiMe's issue now? I'm not sure how/where to apply the code MiMe provided.

kilimanjaro’s picture

Ah, I got the same problem!

user warning: Duplicate entry '801' for key 1 query: INSERT INTO url_alias_extra (pid, dst, entity_type, entity_id, created_by) VALUES (801, 'blog/username/feed', 'blog', 7, 'Pathauto') in /home/sitename/public_html/community/includes/database.mysql.inc on line 172.

emilyf’s picture

Status: Postponed (maintainer needs more info) » Fixed
emilyf’s picture

Status: Fixed » Postponed (maintainer needs more info)

I think I am having the same error, but have been unable to fix with the patch provided. If I go to admin/user/user and edit a user's roles, then submit it. No matter what user I edit, I get all of this (replace the first user "bradley" with any user, but the replacement part is always for me!):

* Created new alias user/bradley for user/2, replacing user/emilyf
* Created new alias blog/bradley for blog/2, replacing blog/emilyf
* Created new alias blog/bradley/feed for blog/2/feed
* Created new alias user/bradley/track for user/2/track, replacing user/emilyf/track
* Created new alias user/bradley/track/feed for user/2/track/feed
* The changes have been saved.

* user warning: Duplicate entry '50960' for key 1 query: INSERT INTO url_alias_extra (pid, dst, entity_type, entity_id, created_by) VALUES (50960, 'user/bradley', 'user', 2, 'Pathauto') in /var/www/html/includes/database.mysql.inc on line 172.
* user warning: Duplicate entry '50961' for key 1 query: INSERT INTO url_alias_extra (pid, dst, entity_type, entity_id, created_by) VALUES (50961, 'blog/bradley', 'blog', 2, 'Pathauto') in /var/www/html/includes/database.mysql.inc on line 172.
* user warning: Duplicate entry '50962' for key 1 query: INSERT INTO url_alias_extra (pid, dst, entity_type, entity_id, created_by) VALUES (50962, 'blog/bradley/feed', 'blog', 2, 'Pathauto') in /var/www/html/includes/database.mysql.inc on line 172.
* user warning: Duplicate entry '50963' for key 1 query: INSERT INTO url_alias_extra (pid, dst, entity_type, entity_id, created_by) VALUES (50963, 'user/bradley/track', 'tracker', 2, 'Pathauto') in /var/www/html/includes/database.mysql.inc on line 172.
* user warning: Duplicate entry '50964' for key 1 query: INSERT INTO url_alias_extra (pid, dst, entity_type, entity_id, created_by) VALUES (50964, 'user/bradley/track/feed', 'tracker', 2, 'Pathauto') in /var/www/html/includes/database.mysql.inc on line 172.

Is this the same error? Why is it always replacing my user alias?

I tried patching from within the pathauto module directory with this command:
patch < pathauto.inc__2.patch

And got Hunk failed...This is the first time I am trying to patch, so forgive me if I've done something stupid. I would really like to resolve this issue. I have 5.x-2.x-dev which I was trying to patch.

emilyf’s picture

Status: Fixed » Postponed (maintainer needs more info)

Re-read up on patches and still couldn't get this patch above to work.

From /sites/all/modules/pathauto:

[efrazier@burlington pathauto]$ patch < pathauto.inc__2.patch
(Stripping trailing CRs from patch.)
patching file pathauto.inc
Hunk #1 FAILED at 258.
Hunk #2 succeeded at 357 (offset 35 lines).
Hunk #3 FAILED at 436.
2 out of 3 hunks FAILED -- saving rejects to file pathauto.inc.rej

Fayna’s picture

I think that patch in comment #1 is for a different issue. I don't think there is a patch yet for the problem we are having. :-(

greggles’s picture

Title: Duplicate entry in url_alias_extra » one instance of Duplicate entry in url_alias_extra
Status: Postponed (maintainer needs more info) » Fixed

This specific issue is fixed. The error message is a symptom of a variety of problems in the 5.x-2.x-dev release and this fixed one instance of them.

There are lots of Bugs with Pathauto5.x-2.x-dev including this one. If you have these problems, generally the best solutions is to use the Stable release (5.x-2.0).

greggles’s picture

ps - if you want to help fixing, the full list of bugs to fix the problem is http://groups.drupal.org/node/8318

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.