Make WordPress Core

Opened 12 years ago

Closed 22 months ago

#21734 closed enhancement (fixed)

Completely remove global terms

Reported by: scribu's profile scribu Owned by: desrosj's profile desrosj
Milestone: 6.1 Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords: has-patch needs-dev-note
Focuses: multisite Cc:

Description (last modified by 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.

Attachments (5)

21734.diff (14.3 KB) - added by scribu 12 years ago.
remove-global-terms.diff (15.8 KB) - added by wonderboymusic 12 years ago.
21734.2.diff (15.8 KB) - added by scribu 12 years ago.
remove-global-terms-for-plugin.diff (16.1 KB) - added by wonderboymusic 12 years ago.
54240.diff (1.4 KB) - added by desrosj 22 months ago.

Download all attachments as: .zip

Change History (39)

@scribu
12 years ago

#2 @scribu
12 years ago

  • Keywords has-patch added

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.

#3 @wonderboymusic
12 years ago

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

#4 @scribu
12 years ago

  • Description modified (diff)

@scribu
12 years ago

#5 @scribu
12 years ago

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

#6 @wonderboymusic
12 years ago

  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to 3.5

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)

Last edited 12 years ago by wonderboymusic (previous) (diff)

#7 follow-up: @scribu
12 years ago

Why is the change in get_blog_permalink() needed?

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

#8 in reply to: ↑ 7 @SergeyBiryukov
12 years ago

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.

#9 @nacin
12 years ago

  • Keywords punt added

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.

#10 @scribu
12 years ago

  • Keywords punt removed
  • Milestone changed from 3.5 to Future Release

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

#11 @kawauso
12 years ago

  • Cc kawauso added

#12 @wonderboymusic
11 years ago

  • Keywords needs-refresh added; has-patch needs-testing removed
  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from new to closed

I don't think this matters right now

#13 @pento
9 years ago

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

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.

#14 @DrewAPicture
9 years ago

@pento Is this still in pursuit?

#15 @pento
9 years ago

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

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


7 years ago

#17 @spacedmonkey
4 years ago

  • Component changed from Taxonomy to Networks and Sites
  • Focuses multisite added

This ticket was mentioned in PR #3079 on WordPress/wordpress-develop by desrosj.


2 years ago
#18

  • Keywords has-patch added; needs-refresh removed

#19 @desrosj
2 years ago

  • Keywords 2nd-opinion needs-dev-note added
  • Milestone changed from Future Release to 6.1

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.

This ticket was mentioned in Slack in #core-multisite by desrosj. View the logs.


2 years ago

#21 follow-up: @johnjamesjacoby
2 years ago

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?

#22 in reply to: ↑ 21 ; follow-up: @desrosj
2 years ago

  • Keywords changes-requested added
  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.

#23 in reply to: ↑ 22 @desrosj
2 years ago

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.

#24 @johnbillion
2 years ago

  • Keywords 2nd-opinion removed

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.

#25 @desrosj
22 months ago

  • Keywords commit added; changes-requested removed

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.

#26 @desrosj
22 months ago

  • Owner set to desrosj
  • Status changed from reopened to assigned

#27 @desrosj
22 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#29 @desrosj
22 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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
22 months ago

#30 @desrosj
22 months ago

  • Keywords commit removed

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

This ticket was mentioned in Slack in #cli by desrosj. View the logs.


22 months ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


22 months ago

#34 @desrosj
22 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.