[wp-trac] [WordPress Trac] #39984: wp_insert_term can return wrong ID when multiple existing terms are found with the same name but differnet parent
WordPress Trac
noreply at wordpress.org
Thu Mar 2 03:14:24 UTC 2017
#39984: wp_insert_term can return wrong ID when multiple existing terms are found
with the same name but differnet parent
--------------------------------------------------+--------------------
Reporter: mikejolley | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 4.8
Component: Taxonomy | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch dev-feedback needs-testing | Focuses:
--------------------------------------------------+--------------------
Changes (by boonebgorges):
* component: General => Taxonomy
* milestone: Awaiting Review => 4.8
Comment:
Thanks for the detailed report and the patch, @mikejolley. I've attached a
second patch that includes a test demonstrating the problem and the fix.
Regarding your point 2 - I would like to talk through what's happening
here, since it seems like a change in behavior. I believe that your patch
for 1 has turned up a bug, along the following lines:
- It's possible for there to be more than one member of `$name_matches`,
either because of accented characters (see the following block) or because
of hierarchy branches like the one described in this ticket.
- When no slug is provided to `wp_insert_term()` and there's a name match
(in the relevant part of the taxonomy), we generally want to return an
error - this is one of the legacy error conditions of `wp_insert_term()`
- It's usually the case that the first member of the `$name_matches` array
will have the non-prefixed slug. That is: under normal circumstances
(entering category names from the Dashboard), WP is responsible for
generating slugs; so the first 'Child' will get the slug `child`, the
second will get `child-foo`, etc. Since the default sort order of
`get_terms()` is by ID, `child` will practically always be first.
- This means that the `$name_match->slug === $slug` condition on line 2066
is usually met. But it's sorta coincidental that this works: if you first
created 'Child' with the manual slug `child-foo` and then created a second
'Child' with `child`, you'd surface the bug, independently of the
hierarchy issue described in this ticket.
Does that sound right to you? If so, there are really two bugs to fix
here.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/39984#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list