Wordpress 4.4: Update all taxonomy meta stuff to use the new WP_Term

[benlk]

https://make.wordpress.org/core/2015/10/23/4-4-taxonomy-roundup/

Largo currently uses posts in the hidden _term_meta post type to store metadata associated with a term. This is done by a collection of functions in inc/term-meta.php.

WordPress 4.4 introduces a Term Meta API, which would allow us to remove this code from Largo, but we'll have to migrate all the existing metadata in _term_meta posts to the official storage methods.

Things this will need:

• [ ] migration in the Largo update function, checking the WordPress version.
• [ ] tests for the migration function
• [ ] changes to metaboxes/save functions to make sure that term meta saves to WP_Term_Meta rather than to the Largo custom post type.
• [ ] ~optional:~ docs for cleaning up/removing the _term_meta posts
  • [ ] how to identify
  • [ ] how to remove

[benlk]

Note: When doing this, tear it all out of Largo and make it a plugin.

If we're dropping pre-4.4 support, then we can get rid of all the shim code that Largo has for creating a post to contain the term meta. And that means that we don't need to use Largo's featured media dialog for this, but instead switch to a simple file upload dialog like used in Largo's Theme Options.

The plugin should have a boilerplate output function that displays the media, and can be easily hooked by themes onto theme-provided hooks. This function should also be accompanied by docs explaining how to roll your own function for the purpose.

[benlk]

Something to be aware of: in current/recent versions of Largo, saving the term meta settings page creates a new term meta post instead of updating the old one. If we write a shim to update this in The Next Largo, we're going to want to grab the latest term meta post, not just the first one to pop up.

[benlk]

Addendum to the Dec 9, 2016 post: "creates a new term meta post" is not always true.

[benlk]

From WP 5.1, there's new sanitization options available: https://make.wordpress.org/core/2019/01/23/improved-taxonomy-metabox-sanitization-in-5-1/

[benlk]

Addendum regarding the occasional creation, from a member's dev:

OK, this is unrelated to the workflow, but I’m wondering if you can shed any light. SELECT * FROM wp_posts WHERE post_type = "_term_meta" AND post_title = ":"

I’ve been wondering why the database is so freaking HUGE, and it turns out that there’s a lot of posts (4396622, by my count) with blank custom fields. (See https://codex.wordpress.org/Function_Reference/add_term_meta) These should be key-value pairs, but they’re all null:null. I’ve never seen this before. Is this possibly due to some rogue plugin? Or custom fields that were later deleted? Or some WordPress bug? I’d like to fix this! Let me know if you have any insights.

If and only if the post's title is ":", it may be safe to delete those posts outright, but this requires further testing.

[benlk]

From that same dev:

On my local installation of the database I just did a DELETE FROM wp_posts WHERE post_type = "_term_meta" AND post_title = ":"

and then optimized the wp_posts table. It was 1.5 Gb before optimizing, and 264.7 Mb afterwards. As far as I can tell, deleting those rows hasn’t affected the site at all, but of course we should test this on the staging server. And I guess /inc/term-meta.php should be modified to not insert blank metadata? Or maybe you’re phasing that out altogether.

[MirandaEcho]

term meta --> WP_Term_Meta