Completely remove global terms

[scribu]

It's an obscure WPMU feature that 1) hasn't been maintained 2) hardly anyone uses and 3) slows down development on the regular taxonomy code:

#5809 #18609 #18617

There isn't much code to remove, but the idea is to not have to worry about "global terms" anymore at all.

[ocean90]

ticket:12666#comment:8

[scribu]

21734.diff​ takes care of the raw code removal.

To be completely back-compat, we'd need to automatically install a plugin, when upgrading a WPMU network which had global terms enabled.

[wonderboymusic]

whoops - I added a patch at basically the exact same time

[scribu]

21734.2.diff​ resurrects global_terms_enabled() and adds TODO for where the code for installing the plugin should go.

[wonderboymusic]

Patch refreshed to accomodate plugin, which is now here: ​http://plugins.svn.wordpress.org/global-terms/trunk/global-terms.php (first rev, needs love / testing)

[scribu]

Why is the change in get_blog_permalink() needed?

$link = set_url_scheme( get_permalink( $post_id ) , 'http' );

[SergeyBiryukov]

Replying to scribu:

Why is the change in get_blog_permalink() needed?

That was from ticket:19420:blog-perma-set-url-scheme.diff​ on #19420.

[nacin]

Not sure I have the stomach for this right now. It's fairly unobtrusive code that we've not needed to maintain or touch since we disabled global terms by default in 3.0.

[scribu]

If it doesn't block #5809, I'm fine with it.

[wonderboymusic]

I don't think this matters right now

[pento]

Global terms is a buggy hell hole, and I think term splitting broke it, at least on WP.com.

Because no-one in their right mind uses it, let's remove it, and auto-install ​the plugin on upgrade.

[DrewAPicture]

@pento Is this still in pursuit?

[pento]

Yep, we'll hopefully have a plan for WP.com after next week, which will guide how we remove it from Core.

Trac ticket: https://core.trac.wordpress.org/ticket/21734

[desrosj]

I think it's time to revisit this and follow through. A summary of some fact finding:

• The UI was completely removed in [14854]. (WordPress 3.0)
• The "on" switch was removed from Core in [14880]. A plugin was then required to trigger install_global_terms(). (WordPress 3.0)
• The ​Global Terms plugin that was created to push folks using the feature to does not work, and ​appears to have been broken since WordPress 3.5.
• After term splitting, there are lots of strange behaviors, problems, and broken-ness when changing terms that exist on multiple sites in my limited testing.
• The concept of term meta now exists, but is not a thing in the context of global terms. There are likely lots of problems here as well.
• Searches of the plugin directory confirm that ​no one is ​actually ​using the ​feature. Most matches are plugins defensively using global_terms_enabled(), or false positives.

I've created a PR to further deprecate and remove global terms. The PR:

• Removes global_terms_enabled() calls within conditional logic making the assumption that global terms will never be enabled.
• Moves all related functions to ms-deprecated.php.
• Removes all default filter and action hooks calling these deprecated functions.
• Introduces the concept of "old multisite global tables" mirroring "old tables" in WPDB and moves sitecategories into that list.

One thing I was uncertain of was how to properly deprecate a pluggable function. I couldn't find any examples searching through the code base. If the function is moved to ms-deprecated.php, then I believe that it's technically no longer "pluggable" because of the file loading order (and the ​unit tests demonstrated this). But leaving it in pluggable.php also felt wrong.

If there's agreement this can happen, I'll close out global term related bug reports as wontfix. Also marking as needs-dev-note. One should be published as a courtesy to summarize this decision just in case there are sites still utilizing this.

[johnjamesjacoby]

Hey @desrosj 💫

1. Your summary was helpful.
2. Your PR makes sense and looks good at a cursory. I specifically like that you thought to carry over the "old multisite global tables" the way that you did (other wpdb issues not-withstanding...)
3. I believe this is why wp-includes/pluggable-deprecated.php exists! Everything in there internally calls _deprecated_function() and still does what it did before it was deprecated. I'd plunk them all in there.
4. I am in agreement that this can and should happen. I agree that wontfixing related bug reports seems appropriate in this instance. Also agree about developer note.

Question (for anyone): should we add more committers to the Global Terms plugin to preemptively/separately maybe/possibly update it to not be broken at the same time, or just close it, or something else?

[desrosj]

1. I believe this is why wp-includes/pluggable-deprecated.php exists! Everything in there internally calls _deprecated_function() and still does what it did before it was deprecated. I'd plunk them all in there.

Ah ha! Today I learned that file existed!

Looking at this again, sync_category_tag_slugs() and install_global_terms() are actually admin facing functions, so these should not be added to a deprecated file within wp-includes. wp-admin/includes/deprecated.php exists, but that would result in the functions being present for non-Multisite installs as well. There's also no admin facing pluggable-deprecated.php counterpart, and no Multisite specific pluggable-deprecated in either context.

We could introduce the missing Multisite specific files, but it feels wrong with only one function to include in each. It's possible there are some functions that would fit better in these new files, but none popped out on a quick glance.

Question (for anyone): should we add more committers to the Global Terms plugin to preemptively/separately maybe/possibly update it to not be broken at the same time, or just close it, or something else?

Personally, I vote for just closing the plugin. It has not worked in 25 major releases and counting, and the level of effort to move the needed code into the plugin and make the feature actually work in a supported version of WordPress is unknown, but likely to be pretty high and makes me shiver.

If a trusted core contributor is interested in adopting the plugin, I think it would be fine to let them own the effort, but a ground up rework would probably be much easier.

[desrosj]

Replying to desrosj:

wp-admin/includes/deprecated.php exists, but that would result in the functions being present for non-Multisite installs as well.

Sorry, I missed wp-admin/includes/ms-deprecated. But the points about pluggable-deprecated in wp-admin seem accruate.

[johnbillion]

If global terms hasn't worked for nine years my vote would go to also no-oping the functions that are moved to ms-deprecated.php. Let's not pretend that the feature works and it's just being deprecated.

+1 for closing all existing tickets reported against the feature.

[desrosj]

Refreshed the PR and I think that this is good to go pending a courtesy confirmation that this will not break something on .org/ or wp.com.

[desrosj]

In 54240:

Networks and Sites: Officially remove global terms.

Global terms was a feature from the WordPress MU days where multisite and single site installs used different code bases.

In WordPress 3.0, WordPress MU was merged into one location and the UI [14854] and “on” switch [14880] for global terms were completely removed.

Even before this merge, global terms was bug infested and unreliable. After [14854]/[14880], the feature was no longer maintained and became increasingly broken as taxonomies progressed without it (term splitting and term meta do not work at all). At this point, the feature has not worked in 12+ years and there’s no hope for saving it.

This deprecates the remaining global terms related code and no-ops the functions.

Global terms, you don’t have to go home, but you can’t stay here.

Props scribu, wonderboymusic, SergeyBiryukov, nacin, pento, desrosj, johnjamesjacoby, johnbillion, dd32.
Fixes #21734.

Merged in https://core.trac.wordpress.org/changeset/54240.

[desrosj]

Reopening this to address an issue that was raised post beta 1.

​https://github.com/wp-cli/search-replace-command/issues/173.

Looks like global_terms_enabled() was incorrectly moved to ms-deprecated.php, when that should have been moved to just deprecated.php.

[desrosj]

54240.diff​ should fix the issue despite being named after the problematic changeset and not the ticket number.

[courane01]

Thanks @expresstech for ​https://github.com/wp-cli/search-replace-command/issues/173

[desrosj]

In 54283:

Network and Sites: Move global_terms_enabled() to its proper final resting place.

When initially deprecated in [54240], global_terms_enabled() was incorrectly moved to the wp-includes/ms-deprecated.php file. This file is only loaded for multisite installs.

The function previously lived in wp-includes/functions.php, which is loaded for all sites. The proper deprecated file is wp-includes/deprecated.php.

Props vikasprogrammer, davidbaumwald, courane01, desrosj.
Fixes #21734.