[wp-trac] [WordPress Trac] #34544: Attaching metadata to shared terms can result in data corruption
WordPress Trac
noreply at wordpress.org
Wed Nov 4 00:38:24 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 | Resolution:
Keywords: has-patch 2nd-opinion | Focuses:
-----------------------------------+------------------
Changes (by johnjamesjacoby):
* keywords: has-patch => has-patch 2nd-opinion
Comment:
34544.diff gets the job done, but seems backwards to me. It's also
possible I don't fully understand the harm that adding metadata to a
shared term might cause.
Most of the time terms are not shared across taxonomies, so potentially
hitting the database on each metadata add/update is kinda sucky, though
there's not really any better way to know for sure.
If the problem is that splitting terms causes metadata to be orphaned, I
expect the newly split term to have the same metadata as it's origin. Less
of a split; more of a clone? The term splitting code could check for
metadata at the origin and copy it to the new term. This approach would
allow us to leave the metadata functions unmodified, and guarantee
metadata exists as it's intended to after terms are split.
Other, more silly thoughts. How about the edge-case where installations
are choosing not to run the term-splitting code, but do want term
metadata. Regarding the newly proposed `finished_splitting_shared_terms`
option, would it make more sense to compare to the `db_version` instead,
or to separately version each database table and come up with a naming
convention for doing that to other tables in the future?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/34544#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list