[wp-trac] [WordPress Trac] #21734: Completely remove global terms

[WordPress Trac]

#21734: Completely remove global terms
-------------------------------------------------+-------------------------
 Reporter:  scribu                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.1
Component:  Networks and Sites                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion needs-dev-     |     Focuses:  multisite
  note changes-requested                         |
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * keywords:  has-patch 2nd-opinion needs-dev-note => has-patch 2nd-opinion
     needs-dev-note changes-requested


Comment:

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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/21734#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform