[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