[wp-trac] [WordPress Trac] #5809: Updating a term in one taxonomy affects the term in every taxonomy

WordPress Trac noreply at wordpress.org
Sun Nov 2 00:39:07 UTC 2014


#5809: Updating a term in one taxonomy affects the term in every taxonomy
--------------------------+---------------------------
 Reporter:  rmccue        |       Owner:  boonebgorges
     Type:  defect (bug)  |      Status:  accepted
 Priority:  high          |   Milestone:  4.1
Component:  Taxonomy      |     Version:  2.3
 Severity:  major         |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------------
Changes (by boonebgorges):

 * owner:  garyc40 => boonebgorges
 * status:  reopened => accepted
 * milestone:  Future Release => 4.1


Comment:

 [attachment:5809.2.patch] is a refresh of 5809.patch that adds some logic
 for preventing duplicate term creation. See the lines in the patch that
 are labeled "Sanity check".

 This refreshed patch follows from a discussion I had earlier today with
 nacin. We talked about the risk, given the lack of UNIQUE index on the
 wp_terms:slug, that duplicate terms would be incorrectly created in
 certain circumstances, such as in environments where a master database is
 replicated to one or more slaves. The INSERT call in `wp_insert_term()`
 will always point to the master, but the change may take time to be
 replicated to the read-only slaves; and during this time, a
 `term_exists()` check might point to an out-of-date slave where the new
 term does not exist, which may allow a duplicate term to be created. The
 solution he suggested was this: in these replicated environments, a single
 INSERT statement will trigger all subsequent queries in the request to be
 performed against the master database. So, we allow `wp_insert_term()` to
 create the term; then, knowing that subsequent SELECT statements will hit
 the master, we check to see whether there's an older item that shares the
 slug+parent+taxonomy with the term just created. If so, we have a
 duplicate, and we should use the older term/tt and delete the just-created
 one. (Phew.)

 The idea behind this updated patch is that it should catch the majority of
 cases where it's possible for duplicate terms to be mistakenly created,
 which should give us a good deal more confidence that we can go forward
 with starting the process of solving this ticket during the 4.1 release.

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


More information about the wp-trac mailing list