[buddypress-trac] [BuddyPress Trac] #8037: WP 5.1 `wp_parse_id_list()` check breaks `parent_id` parsing
buddypress-trac
noreply at wordpress.org
Tue Jan 15 21:50:23 UTC 2019
#8037: WP 5.1 `wp_parse_id_list()` check breaks `parent_id` parsing
--------------------------+---------------------
Reporter: boonebgorges | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 4.2.0
Component: Groups | Version:
Severity: normal | Resolution:
Keywords: |
--------------------------+---------------------
Comment (by dcavins):
Hi @boonebgorges. I'm pretty sure that "intended behavior" is a mild
overstatement. :)
The logic as originally written was
• `parent_id` that is `null` => don't take the `parent_id` into account
for the query.
• `parent_id` that's not `null` => pass the parameter to
`wp_parse_id_list()` to sort it out.
The note in the code was just to remind users that passing `parent_id ===
false` would be equivalent (because of a quirk in `wp_parse_id_list()`) to
passing a `parent_id` of `0` (and the query would return top-level groups
only).
Your patch maintains the behavior as it was, quirks and all, but whether
it's the best, most predictable behavior I can't say. The code note for
the parameter says "Optional. Array or comma-separated list of group IDs.
Results will be limited to children of the specified groups. Default:
null." So we don't really make any promises about what `false` might do.
Honestly, converting `false` to `0` seems to make less sense than treating
`false` like `null`, except it would change `BP_Groups_Group::get()`'s
behavior.
Thanks for catching this change!
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8037#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list