[wp-trac] [WordPress Trac] #34544: Attaching metadata to shared terms can result in data corruption

WordPress Trac noreply at wordpress.org
Sun Nov 1 15:04:58 UTC 2015


#34544: Attaching metadata to shared terms can result in data corruption
--------------------------+-----------------
 Reporter:  boonebgorges  |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  high          |  Milestone:  4.4
Component:  Taxonomy      |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------
 WP 4.3 splits shared taxonomy terms on a cron job, which means that there
 may be sites where shared terms still exist after upgrading to 4.4. If a
 `$term_id` is shared between two or more taxonomies, you'll get unexpected
 results if you `add_term_meta( $term_id, 'foo', 'bar' )`. You could, for
 example, intend to add metadata to a category that shares a `term_id` with
 a post_tag, then have the term split so that the category gets a new
 term_id, at which point your metadata is associated with the post_tag
 rather than the category.

 After some discussion with @dlh, @aaronjorbin, @mboynes, @dhshredder, I
 think the correct approach is to bail out of `add_term_meta()` or
 `update_term_meta()` if we detect that the `$term_id` is shared. A couple
 of implementation details to decide on:

 a. Checking to see whether a term is shared introduces a non-trivial
 amount of overhead. We should probably set a flag if we know that the
 installation has no shared terms, and skip the check if that's true. We
 already have a 'finished_splitting_shared_terms' flag for wp-cron, but I'm
 not 100% sure that it'll be reliable in all cases. We may need a flag
 that's set via a more direct database query, maybe at the end of
 `_split_shared_term()`.
 b. Currently, `*_metadata()` functions and their wrappers return `false`
 on error. This is not very helpful. When a term is shared, we could throw
 a `_doing_it_wrong()`, though this can't be caught programatically. Or we
 could return a `WP_Error`, though it'll add yet another kind of return
 value.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34544>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list