WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 3 days ago

#5809 reopened defect (bug)

Updating a term in one taxonomy affects the term in every taxonomy

Reported by: rmccue Owned by: garyc40
Milestone: Future Release Priority: high
Severity: major Version: 2.3
Component: Taxonomy Keywords: has-patch early needs-unit-tests
Focuses: Cc:

Description (last modified by lloydbudd)

As reported by klawd on #wordpress and reproduced by me, editing a category will affect a tag with the same name.

Steps to reproduce:
1. Create a category called Testing
2. Create a tag called Testing
3. Rename the Testing category to Another Test
4. Check the name of the tag

Attachments (6)

structure.txt (416 bytes) - added by rmccue 6 years ago.
Proposed new structure of tables (by klawd)
5809.diff (838 bytes) - added by greuben 4 years ago.
5809-2.diff (963 bytes) - added by greuben 4 years ago.
garyc40.5809.diff (3.8 KB) - added by garyc40 3 years ago.
create new tag instead of modifying existing one if the user changes its name or slug and the term is in multiple taxonomies
terms.diff (2.7 KB) - added by wonderboymusic 2 years ago.
5809.03.diff (859 bytes) - added by imath 5 weeks ago.

Download all attachments as: .zip

Change History (130)

comment:1 rmccue6 years ago

Oops, I meant:

Steps to reproduce:

  1. Create a category called Testing
  2. Create a tag called Testing
  3. Rename the Testing category to Another Test
  4. Check the name of the tag

rmccue6 years ago

Proposed new structure of tables (by klawd)

comment:2 rmccue6 years ago

  • Cc klawd@… added

comment:3 lloydbudd6 years ago

  • Description modified (diff)

comment:4 asmodai6 years ago

  • Version set to 2.5

I can verify that this is a problem in the released 2.5.

comment:5 asmodai6 years ago

The problem is that wp_term_taxonomy refers to wp_terms for the name of the category/tag for both category and tag. One could argue that tagging a post filed in a category with the same name as the tag is redundant. klawd's restructuring makes sense to me though, proper separation might be better overall.

comment:6 Denis-de-Bernardy5 years ago

  • Component changed from General to Taxonomy
  • Owner changed from anonymous to ryan

comment:7 tenzochris5 years ago

Confirmed this is still a problem in 2.8.4 - good to see it's on the list for 2.9, though.

comment:8 ryan5 years ago

  • Milestone changed from 2.9 to Future Release

There won't be taxonomy schema changes, at least for a long time. This will have to be addressed by creating a new term when changing the name of a term present in multiple taxponomies.

comment:9 archon8104 years ago

Hi guys,

I had a similar situation just now and I think this behavior is very confusing and limiting to WP users.

Here's what happened:

  • I created a few posts with tags, such as "HTC".
  • I then decided to add a few categories, one of which is Phones, with a child one called "HTC"
  • The categories were created OK but the slug was not, because it is set as UNIQUE in the DB table. Instead, the current logic falls back on the slug comprised of parent categories, until the slug is made unique (such as phones-htc).
  • Now, the url to the post will have phones/phones-htc (and if I had more problematic slugs like this, it could get even uglier: phones/htc-phones/hero-htc-phones-phones). This is bad for SEO and is straight up confusing to the user who enters a slug but gets another slug when he or she refreshes the page.

In summary, it's a shortcoming of the application to not allow the same category name as the tag name. There are workarounds, of course, such as renaming the slug slightly, but it's still a bug.

Now, as far as the solution, because the wp_terms table doesn't have the term type, it's not possible to make a composite unique key. Therefore, the unique key would need to be dropped and proper behavior would need to be enforced from the application (WP).

Any other suggestions are welcome.

Thanks, guys.

comment:10 sainz4 years ago

  • Severity changed from normal to major
  • Version changed from 2.5 to 2.9.2

I have this problem too.

I use WPMU 2.9.2 and Buddypress 1.2.1.

Thanks!

comment:11 nacin4 years ago

  • Keywords needs-patch added
  • Severity changed from major to normal
  • Version changed from 2.9.2 to 2.3

Please do not change the version number. This tells developers when the bug was introduced, reported, etc. Restoring severity as well.

There was a suggestion made above for how we should address this. This needs a patch.

comment:12 kevinB4 years ago

  • Cc kevinB added

greuben4 years ago

greuben4 years ago

comment:13 greuben4 years ago

  • Keywords has-patch 2nd-opinion needs-testing added; needs-patch removed

Attached two patches. The first patch creates unique slug at wp_insert_term, the second patch creates unique term at wp_update_term.

Personally, I like the first patch.

comment:14 garyc403 years ago

  • Owner changed from ryan to garyc40
  • Status changed from new to assigned

garyc403 years ago

create new tag instead of modifying existing one if the user changes its name or slug and the term is in multiple taxonomies

comment:15 follow-up: garyc403 years ago

Just attached a patch that does what ryan wants in comment 8:

  • If the tax is present in multiple taxes and the name or slug in one tax is changed:


+ create a new term with the new settings

+ reassign posts in the old term to the new term


+ delete the old term in the current tax

  • As a result, the original term in other taxes is untouched

comment:16 in reply to: ↑ 15 jghazally3 years ago

worked for me, :D

comment:17 scribu3 years ago

  • Cc scribu added

comment:18 mikeschinkel3 years ago

  • Cc mikeschinkel@… added

comment:19 follow-up: scribu3 years ago

Related: #16936

comment:20 scribu3 years ago

Duplicate: #16941

comment:21 follow-up: garyc403 years ago

  • Keywords 3.2-early added

This issue has persisted for quite a long time now. I know some plugin that depend on this being fixed. Would be great if it can be in 3.2 :)

If not, please remove the 3.2-early keyword I just added.

comment:22 voidtrance3 years ago

Hi,

Is there any update on this issue? I have a site on which most of the category/tag archive links return 404 errors due to this.
Also, there is no way for me to fix it since WP updates the slugs for both the category and tag at the same time.

Site address: http://www.voidtrance.net

Thank you

comment:23 voidtrance3 years ago

  • Severity changed from normal to major

3.2 does not seem to fix the issue. I still can't change either the category slug or the tag slug without the change affecting both category and tag.

What this means in my case is that the majority of my categories/tags return 404 errors when accessed.

I am raising the Severity to major because to me this is a major issue that should have been fixed by now.

comment:24 follow-up: ab-tools3 years ago

  • Cc ab-tools added

I just came across exactly the same issue now and can't believe that such a major bug that produces really unexpected behavior has not been fixed for 4 years now!

It looks like as there are already patched available:
so what's the reason why they don't get integrated into the main system for such a long time?

Is there any planning when this will get fixed?

comment:25 follow-up: nacin3 years ago

  • Keywords needs-unit-tests added; 2nd-opinion needs-testing 3.2-early removed

I'm happy to support this, but we need unit tests. The quicker those happen...

comment:26 coombesy3 years ago

I'm reporting this as well. Using wp 3.2.1 MU.

Just built an app that used hierichal custom taxonomy called 'warehouse'.
Now found out I can't have:
Old Stock-> Cameras-> Chargers
and
New Stock-> Chargers
In my new taxonomy

comment:27 in reply to: ↑ 25 ; follow-up: havahula3 years ago

Replying to nacin:

I'm happy to support this, but we need unit tests. The quicker those happen...

I would like to see this make it sooner than later. happy to help with testing.

comment:28 in reply to: ↑ 27 ; follow-up: SergeyBiryukov3 years ago

Replying to havahula:

I would like to see this make it sooner than later. happy to help with testing.

http://codex.wordpress.org/Automated_Testing#Writing_Tests

comment:29 in reply to: ↑ 28 havahula3 years ago

Replying to SergeyBiryukov:

Replying to havahula:

I would like to see this make it sooner than later. happy to help with testing.

http://codex.wordpress.org/Automated_Testing#Writing_Tests

thanks.

comment:30 follow-up: SergeyBiryukov3 years ago

Related: #6211

comment:31 johnbillion2 years ago

  • Cc johnbillion added

comment:32 follow-up: ryan2 years ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from assigned to closed

comment:33 johnbillion2 years ago

Any reason given for the maybelater?

comment:34 ryan2 years ago

  • Milestone set to Future Release
  • Resolution maybelater deleted
  • Status changed from closed to reopened

comment:35 ryan2 years ago

nacin seems interested, so have fun. :-)

comment:36 lkraav2 years ago

  • Cc lkraav added

comment:37 Viper007Bond2 years ago

  • Cc viper007bond added

comment:38 TomAuger2 years ago

  • Cc tomaugerdotcom@… added

comment:39 scribu2 years ago

Positive consequence if this gets fixed: #20536

comment:40 nacin2 years ago

I suggest we stop trying to look into wp_terms for an existing name/slug when creating a term. So on a new install, term_id would always equal tt_id — shared terms would no longer occur.

Needs unit tests. With them, I will see to this for 3.5.

comment:41 TomAuger2 years ago

Yep. That sounds right. Would need to be rigorously tested though, as you have pointed out.

comment:42 duck_2 years ago

This is particularly confusing when you have a nav menu with the same name as a tag/category/custom taxonomy term, see #20707.

Last edited 2 years ago by duck_ (previous) (diff)

comment:43 sc0ttkclark2 years ago

  • Cc lol@… added

comment:44 husobj2 years ago

  • Cc ben@… added

comment:45 batmoo2 years ago

  • Cc batmoo@… added

comment:46 tott2 years ago

  • Cc tott@… added

comment:47 SergeyBiryukov2 years ago

#21275 has another patch.

comment:48 follow-up: wonderboymusic2 years ago

can someone point me to where unit tests would be included / uploaded / patched, etc?

wonderboymusic2 years ago

comment:49 follow-up: wonderboymusic2 years ago

both counts need to be updated when tt_id is updated in term_relationships - I updated my patch

comment:50 anointed2 years ago

+1 for inclusion sooner than later. I keep getting hit by this 'bug' myself.

comment:51 sirzooro2 years ago

  • Cc sirzooro added

comment:52 hsatterwhite2 years ago

  • Cc whsatterwhite@… added

comment:53 SergeyBiryukov2 years ago

Closed #21557 as a duplicate.

comment:54 wonderboymusic23 months ago

Closed #21639 as a duplicate

comment:55 wonderboymusic23 months ago

Is there any particular reason this conversation is stalled? My patch works, and I'm sure there are other patches that work. I don't have Unit Tests set up, but if someone does and wants to help in this arena: that would rock.

comment:56 sc0ttkclark23 months ago

If no one has made a unit test or said they will within a week, I'll volunteer my time to set one up.

comment:57 in reply to: ↑ 48 nacin23 months ago

Replying to wonderboymusic:

can someone point me to where unit tests would be included / uploaded / patched, etc?

Unit tests can go into tests/term.php or tests/term/shared.php (for shared terms, or the demise thereof).

I'm really excited about getting this into core as I think it sets the stage for potential future changes to our taxonomy API and schema.

terms.diff looks like it handles quite a bit more than 5809.diff. That also means it would be *great* if there were individual tests for all of the different moving parts.

If this is fully tested and ready to go within the next few weeks, I want to land this in 3.5.

Last edited 23 months ago by SergeyBiryukov (previous) (diff)

comment:58 tollmanz23 months ago

  • Cc tollmanz@… added

I'm willing to work on these unit tests. I have everything setup and have committed unit tests before. The only catch is that I likely won't have time until late next week. Would also be happy to coordinate efforts with someone else as well.

comment:59 wonderboymusic23 months ago

  • Keywords needs-unit-tests removed

comment:60 in reply to: ↑ 49 SergeyBiryukov23 months ago

Replying to wonderboymusic:

both counts need to be updated when tt_id is updated in term_relationships - I updated my patch

Is there a reason to call _update_*_term_count() directly instead of wp_update_term_count_now()?

comment:61 SergeyBiryukov23 months ago

  • Keywords needs-unit-tests added

Per the IRC chat and http://core.trac.wordpress.org/report/37, it's better to keep the keyword until the tests are reviewed and committed.

comment:62 ryan23 months ago

Does it break global terms? ( global_terms_enabled(), install_global_terms(), sitecategories, etc. )

Last edited 23 months ago by ryan (previous) (diff)

comment:63 ryan23 months ago

Completely removing global terms is an option. But it should be discussed and not simply forgotten. :-)

comment:64 nacin23 months ago

The UNIQUE KEY slug in $wpdb->terms needs to be converted to a regular key as well.

comment:65 scribu23 months ago

Remove global terms. Do it: #21734

comment:66 johnbillion22 months ago

  • Summary changed from Categories affect tags of the same name to All terms affect terms of the same name

comment:67 scribu22 months ago

That new title makes no sense at all! Just read it out loud. :))

comment:68 wonderboymusic22 months ago

  • Summary changed from All terms affect terms of the same name to Updating a term in one taxonomy affects the term in every taxonomy

Let's keep changing it until we reach nirvana

comment:69 scribu22 months ago

To clarify, it might have made sense to those already familiar with the issue, but to outsiders, it's incomprehensible.

"All terms affect terms of the same name?! You mean you can have two terms with the same name?! What's a term? How did I end up here, anyway? I think I need some fresh air..."

comment:70 husobj22 months ago

  • Cc ben@… removed

comment:71 husobj22 months ago

  • Cc ben@… added

comment:72 wonderboymusic22 months ago

  • Milestone changed from Future Release to 3.5

Global terms were removed here: #21734. Nacin supported this ticket in dev chat 4 weeks ago. I'll write a Unit Test every day until December if we can make this happen. Moving this to 3.5 until someone says anything definitive about it / objects.

comment:73 JustinSainton22 months ago

+1. This is crazy. More than happy to help with unit tests, debugging, etc. @wonderboymusic, let me know if there's anything you need help on.

comment:74 scribu22 months ago

[UT1029], but still needs more. See #UT125

Last edited 22 months ago by scribu (previous) (diff)

comment:76 greenshady22 months ago

  • Cc justin@… added

comment:77 scribu22 months ago

  • Keywords needs-unit-tests removed

comment:78 scribu22 months ago

Say you have this configuration:

| Taxonomy | Term slug  | Term ID |
-----------------------------------
| A        | orange     | 1       |
| B        | orange     | 1       |
| C        | banana     | 2       |
-----------------------------------

What happens when you try to rename 'orange' to 'banana'?

I'm starting to think nacin's intuition that this should be handled at the same time with #21950 (which will require removing the UNIQUE constraint on wp_terms.slug).

Last edited 22 months ago by scribu (previous) (diff)

comment:79 follow-up: ryan22 months ago

I think this needs to use wp_update_term_count() instead of direct calls to _update_generic_term_count() and _update_post_term_count() so that deferred term counting still works. Deferred counting is more important when creating new terms vs. updating so it might not be a big deal here. Deferred counting is to avoid count update storms during imports.

Last edited 22 months ago by ryan (previous) (diff)

comment:80 scribu22 months ago

False alarm: [UT1048]

It will actually create a term with the title 'Banana', but the slug 'orange-2'.

The bad news is that users probably don't want 'orange-2' asthe slug for the 'Banana' term, so it doesn't seem like this would help that much.

The good news is that we don't need to touch the UNIQUE index and don't need to worry about #21950.

Version 0, edited 22 months ago by scribu (next)

comment:82 jkudish21 months ago

  • Cc joachim.kudish@… com added

comment:83 nacin21 months ago

#22153 was marked as a duplicate.

comment:3 mojowill21 months ago

#22226 was marked as a duplicate.

comment:4 mojowill21 months ago

  • Cc will@… added

comment:5 in reply to: ↑ 79 nacin20 months ago

  • Keywords punt added

Replying to ryan:

I think this needs to use wp_update_term_count() instead of direct calls to _update_generic_term_count() and _update_post_term_count() so that deferred term counting still works. Deferred counting is more important when creating new terms vs. updating so it might not be a big deal here. Deferred counting is to avoid count update storms during imports.

This remains important. I sense a sad punt, then reviving this in 3.6.

comment:6 nacin20 months ago

  • Keywords 3.6-early added; punt removed
  • Milestone changed from 3.5 to Future Release
  • Priority changed from normal to high

This is 3.6 territory.

comment:7 chriscarson20 months ago

Hi --

I'm new here, but am an experienced userland WordPress programmer who is conversant with the issue being discussed.

This thread worries me, because it addresses a symptom of the problem (term names and slugs updated willy-nilly across taxonomies,) rather than the fundamental problem (how WordPress handles taxonomy, custom post types and rewrites.)

I've got some ideas on the latter, fundamental problem. Where should I post them? Thanks,

Chris

comment:8 scribu20 months ago

Hello chriscarson,

I think the best place for high-level architecture discussion is the wp-hackers mailing list.

comment:9 WraithKenny19 months ago

  • Cc Ken@… added

comment:10 coreygilmore19 months ago

  • Cc corey@… added

comment:11 wonderboymusic19 months ago

  • Milestone changed from Future Release to 3.6

comment:12 aaroncampbell18 months ago

  • Cc aaroncampbell added

comment:13 nicokaiser18 months ago

  • Cc nicokaiser added

comment:14 teauser16 months ago

  • Cc martrober@… added

comment:15 follow-up: nikolov.tmw15 months ago

  • Cc ico.the.star.dust@… added

comment:16 markoheijnen14 months ago

Shouldn't this be punted to 3.7-early? Seems as something we want to deal early in a release.

comment:17 SergeyBiryukov14 months ago

  • Keywords 3.7-early added; 3.6-early removed
  • Milestone changed from 3.6 to Future Release

comment:18 LucasMS14 months ago

  • Cc LucasMS added

comment:19 follow-up: LucasMS14 months ago

I noticed that even the wordpress API functions are not dealing correctly with term IDs and category IDS. For exemple, the delete_category Hook will pass the TERM ID to the hooked function, not the term_taxonomy_ID, which should be the correct.

This is very serious, since plugins are storing the TERM IDs as if they were identifying numbers of categories.

comment:20 in reply to: ↑ 19 SergeyBiryukov14 months ago

Replying to LucasMS:

For exemple, the delete_category Hook will pass the TERM ID to the hooked function, not the term_taxonomy_ID, which should be the correct.

Term taxonomy ID is passed as a second argument:
http://core.trac.wordpress.org/browser/tags/3.5.1/wp-includes/taxonomy.php#L1838

You'll need to specify the number of arguments in your add_action() call:

add_action( 'delete_category', '...', 10, 3 );

There was, however, an error in the inline docs, fixed in #24343.

comment:21 follow-up: aaroncampbell11 months ago

  • Keywords early added; 3.7-early removed
  • Milestone changed from Future Release to 3.7

comment:22 DeanMarkTaylor11 months ago

  • Cc deanmarktaylor@… added

comment:23 in reply to: ↑ 21 nacin11 months ago

  • Milestone changed from 3.7 to 3.8

Replying to aaroncampbell:

Milestone changed from Future Release to 3.7

Based on http://make.wordpress.org/core/2013/07/28/potential-roadmap-for-taxonomy-meta-and-post-relationships/, I think this is dependent on #22023 which itself is dependent on #17689. As in, 3.8 at the earliest.

comment:24 follow-up: VCcreate10 months ago

We are absolutely astonished that this problem has persisted for OVER 6 YEARS!!!

For shame WP, for shame :(

comment:25 follow-up: VCcreate10 months ago

  • Cc VCcreate added

comment:26 SergeyBiryukov8 months ago

#26067 was marked as a duplicate.

comment:27 follow-up: wonderboymusic8 months ago

  • Milestone changed from 3.8 to Future Release

Gonna drag this in with my bare hands as soon as possible

comment:28 follow-up: leemon7 months ago

So sad this got punted again

comment:29 maorb7 months ago

  • Cc maor@… added

comment:30 follow-up: voilamedia6 months ago

Want to make sure this issues is related before posting another ticket. I tested this on a fresh install with WordPress 3.8.1.

When you create a custom taxonomy, (post types most likely would do this too but I didn't want to test it) then add terms to the taxonomy as you would. Then add a term of that taxonomy as the name of custom menu that you set up with the new menu manager feature, than add menu items it modifies the term and the menu it modifies both the menu term and the custom taxonomy term

To replicate.

  1. create custom taxonomy called centers with a term called "Western US / Los Angeles" with slug of la
  2. Create a menu called "Western US / Los Angeles"
  3. Add items to the menu and save it.
  4. Go back and check the taxonomy the slug has been updated to "western-us-los-angeles"
  5. The same thing happens if you use a slug or an id as the menu name. It changes the term name of the custom taxonomy to term Id.
  6. Once this happens If you update either the menu or the term of the custom taxonomy term it updates both terms.

After some looking it seems like once you create a term and than create a menu term of the same name,Id, or slug instead of creating a new menu term it updates the existing term.

If this issue is as big as it looks I really don't understand why this has not been resolved yet. This has been issue for years and it can cause a lot of issues. I propose this should be fixed in 3.8.2.

comment:31 in reply to: ↑ 24 voilamedia6 months ago

Want to make sure this issues is related before posting another ticket. I tested this on a fresh install with WordPress 3.8.1.

When you create a custom taxonomy, (post types most likely would do this too but I didn't want to test it) then add terms to the taxonomy as you would. Then add a term of that taxonomy as the name of custom menu that you set up with the new menu manager feature, than add menu items it modifies the term and the menu it modifies both the menu term and the custom taxonomy term

To replicate.

  1. create custom taxonomy called centers with a term called "Western US / Los Angeles" with slug of la
  2. Create a menu called "Western US / Los Angeles"
  3. Add items to the menu and save it.
  4. Go back and check the taxonomy the slug has been updated to "western-us-los-angeles"
  5. The same thing happens if you use a slug or an id as the menu name. It changes the term name of the custom taxonomy to term Id.
  6. Once this happens If you update either the menu or the term of the custom taxonomy term it updates both terms.

The custom nav_menu menus are actually stored in the terms tables. Now, when I tried to name the menu the same as an existing term, in the DB, instead of creating a "Menu Name" term, the system just linked to the existing term. So when one or the other is updated, it's changing "both", but they are actually the same term.

If this issue is as big as it looks I really don't understand why this has not been resolved yet. This has been issue for years and it can cause a lot of issues. I propose this should be fixed in 3.8.2.

comment:32 follow-up: voilamedia6 months ago

What can I do to make this happen sooner.

comment:33 in reply to: ↑ 32 helen6 months ago

Replying to voilamedia:

What can I do to make this happen sooner.

#17689 and then #22023 need to be resolved first. Believe me, I don't think it's much of an exaggeration if at all when I say that this drives all of us crazy, too. You may also be interested in this potential roadmap.

comment:34 in reply to: ↑ 30 MikeSchinkel6 months ago

Replying to @all in reference to voilamedia's comments:

When you create a custom taxonomy, (post types most likely would do this too but I didn't want to test it) then add terms to the taxonomy as you would. Then add a term of that taxonomy as the name of custom menu that you set up with the new menu manager feature, than add menu items it modifies the term and the menu it modifies both the menu term and the custom taxonomy term

Let me float an idea that I've thought about ever since I tried to use the menu system for in ways that required some significant custom coding. This idea would not at all address the issue of tag names and slugs changing when they were edited for a different context but would solve the menu issue mentioned above:

Let's deprecate the use of Posts and Taxonomies for menus and instead store serialized objects in the Options table.

I've posted another ticket for discussion of that proposal:

comment:35 helen5 months ago

#27010 was marked as a duplicate.

comment:36 SergeyBiryukov5 months ago

#27179 was marked as a duplicate.

comment:37 SergeyBiryukov3 months ago

#27596 was marked as a duplicate.

comment:38 helen3 months ago

#27966 was marked as a duplicate.

comment:39 imath5 weeks ago

Hi,

Sorry if my patch (5809.03.diff) is too simply, but i thought, if we make sure slugs are different before creating the term, then it can avoid the trouble.

imath5 weeks ago

comment:40 ircbot2 weeks ago

This ticket was mentioned in IRC in #wordpress-dev by simonwheatley. View the logs.

comment:41 rachelbaker2 weeks ago

  • Keywords needs-unit-tests added

comment:42 rachelbaker2 weeks ago

Any thoughts or feedback on imath's patch?

comment:43 jkohlbach3 days ago

Seriously.. how is this still a issue? Such a fundamental bug should have been fixed in the next release, yet we're 6 years on here.

Huge +1 to get this included in the next release. It effects much more than just WordPress core now that CPTs and Custom Taxonomies are commonplace.

Note: See TracTickets for help on using tickets.