When reordering using the drag & drop feature on admin/content/taxonomy/1 custom url aliases are deleted for any term that been moved. (And saved.)

Commenting out "path_set_alias($termpath);" near line 360 fixes the problem.

It looks like the line above used to be needed in the past because the test was "if ($term->path) {" in the past but now that it has been changed to "if (isset($term->path)) {" it's not needed anymore.

CommentFileSizeAuthor
#3 edit_term-500396.patch900 byteshalstead
#1 edit_term-500396.patch1.02 KBhalstead

Comments

halstead’s picture

StatusFileSize
new1.02 KB

A proper patch. I tested with pathauto it seems to work fine.

halstead’s picture

Status: Active » Needs review

Could someone take a look at this patch? Thanks.

halstead’s picture

Assigned: Unassigned » halstead
StatusFileSize
new900 bytes

I'm attaching a cleaner copy of this patch against DRUPAL-6--1 which seems to be more up to date then HEAD.

lotyrin’s picture

Status: Needs review » Reviewed & tested by the community

Tested.

tuffnatty’s picture

Tested the patch and it works.

tuffnatty’s picture

Priority: Normal » Critical
Status: Reviewed & tested by the community » Patch (to be ported)
dman’s picture

Status: Patch (to be ported) » Fixed

Yeah, that looks logical. Trusting that nothing too bad has come up in testing, I've committed to dev.

Thanks for that, and especially thanks for the testing!
Fixed in dev. Is it worth a point release? Lossage is bad, but maybe we can throw a feature in as well to make it worthwhile?

.dan.

tuffnatty’s picture

I've lost hundreds of term aliases a couple of times before I understood the nature of the bug, and had to reenter them manually, so I vote for a release.

dman’s picture

Fair enough!
#589934: edit_term 6.x-1.3
I found another fix to roll in, so it's worth it. Looks like a few other issues/conflicts with aliases may also have been related to this.

Status: Fixed » Closed (fixed)

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