wp_sitecategories does not account for different taxonomy

[axelseaa]

We have a legacy version of WordPressMU (Now MultiSite) that had global_terms_enabled in the wp_sitemeta table.

When this is enabled, if the same term name is added to different taxonomies (for example - tags and categories), the global_terms function in wp-includes/ms-functions.php will update the value of the last entered term, which will cause duplicate term ID errors (see ​https://stackoverflow.com/posts/72523491)

This line is the to blame - only checking the nice name, and not the ID.
​https://github.com/WordPress/WordPress/blob/73a2d87eaea88a16b45bbe2867df5fb856d55414/wp-includes/ms-functions.php#L2085

[ironprogrammer]

Thanks for the report, @axelseaa!

Would you please provide some additional context so that others may attempt to reproduce this issue? For instance, the version of WordPress being used, any special configuration required (e.g. replicating the global terms setting), and if the issue exists after updating WordPress to 6.0+. Thank you!

[axelseaa]

Replying to ironprogrammer:

Thanks for the report, @axelseaa!

Would you please provide some additional context so that others may attempt to reproduce this issue? For instance, the version of WordPress being used, any special configuration required (e.g. replicating the global terms setting), and if the issue exists after updating WordPress to 6.0+. Thank you!

This issue does still persist on our legacy install of 6.0+ when "global_terms_enabled" is set to 1.

Steps to reproduce:

1) Set "global_terms_enabled" to 1. (This likely only impacts install that have the sitecategories table in the database)
2) Create a Post Category and then a Post Tag with the exact same name/slug. For example, a category of "asdf" and a tag of "asdf".
3) Try to edit either the category or tag. You will receive a permissions error due to the incorrect values in the DB.

[ironprogrammer]

In response to @axelseaa:

... (This likely only impacts install that have the sitecategories table in the database)

Do you know under what conditions that table is created? E.g. a specific original WordPress version? Under my multisite test environment (originated at 5.9.3, upgraded to 6.0) that table does not exist, though global_terms_enabled is set. I have test cats/tags from before/after the enablement of global terms, but haven't received any errors when updating them.

I did see that the cat/tag UI changed with the setting in place, where it doesn't allow direct editing of slugs. Though in the database (wp_N_terms tables), I see that modified items are named with the updated value, but the slug field is assigned the old term name. This seems like it would be problematic as a different issue, but I haven't dug deeper into that behavior.

[axelseaa]

Replying to ironprogrammer:

Do you know under what conditions that table is created? E.g. a specific original WordPress version?

I started trying to track back to when that table may have been created, but I was not able to figure that out yet. We started out this wordpress installation way back with WordPress 1.5 MU. There are references to that table in some of the database creation scripts for WordPress install / updates though.

[SergeyBiryukov]

Replying to ironprogrammer:

Do you know under what conditions that table is created?

As far as I can tell, the table is created by the install_global_terms() function, but it's never called in core as of [14880] / #12666. Per comment:5:ticket:12666, a plugin can call it if needed.

Related: #21734

[desrosj]

Updating version to 4.2 with the (unconfirmed) assumption that term splitting/shared terms is the culprit to this issue, but this could span back to 3.0.

I'm going to mark this as a candidate to be closed, pending the discussion over on #21734 (see my latest comment ticket:21734#comment:19) resulting in the remaining related code being deprecated.

Global terms was "soft" deprecated in WP 3.0 12+ years ago, and is very broken in modern WordPress (shared terms and term meta do not work at all). I'd advise finding an alternative way to accomplish this.

[desrosj]

Global terms is now officially deprecated and the functions have been no-opped as of [54240]. Closing this as a wontfix.