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

[rmccue]

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

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

Proposed new structure of tables (by klawd)

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

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.

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

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.

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.

I have this problem too.

I use WPMU 2.9.2 and Buddypress 1.2.1.

Thanks!

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.

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.

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

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

worked for me, :D

Related: #16936

Duplicate: #16941

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.

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

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.

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?

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

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

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.

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

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.

Related: #6211

Any reason given for the maybelater?

nacin seems interested, so have fun. :-)

Positive consequence if this gets fixed: #20536

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.

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

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

#21275 has another patch.

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

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

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

Closed #21557 as a duplicate.

Closed #21639 as a duplicate

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.

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

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.

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.

Unit Test added here: ​http://unit-tests.trac.wordpress.org/ticket/125

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()?

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.

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

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

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

Remove global terms. Do it: #21734

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

Let's keep changing it until we reach nirvana

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..."

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.

+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.

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

Related: #21950

​[UT1042]

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).

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.

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' as the 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.

Related: #22023

#22153 was marked as a duplicate.

#22226 was marked as a duplicate.

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.

This is 3.6 territory.

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

Hello chriscarson,

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

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

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.

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.