Skip to:
Content

BuddyPress.org

#8732 closed defect (bug) (worksforme)

Member-type-specific XProfile fields override 'exclude_fields' parameter in `bp_has_profile()` stack

Reported by: boonebgorges's profile boonebgorges Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Extended Profile Keywords:
Cc:

Description (last modified by boonebgorges)

Imagine a setup where you have a member type 'foo' and a profile field 123 that's associated with the member type.

Then, run the following sort of query:

<?php
$profile_args = [
  'member_type' => 'foo',
  'exclude_fields' => [ 123 ],
];

if ( bp_has_profile( $profile_args ) ) {
...

You'll end up with SQL that looks like this, in BP_XProfile_Group::get_group_field_ids():

SELECT id FROM wp_bp_xprofile_fields WHERE ... id NOT IN (123) AND id IN (123)...

As a result, field 123 *will appear* in the results (IN has precedence over NOT; see https://dev.mysql.com/doc/refman/5.7/en/operator-precedence.html)

This feels counterintuitive to me. Explicit exclusion via exclude_fields should take precedence over implicit inclusion via member_type. Moreover, in the current setup, there's no reliable way to exclude 123, except via filter.

The problematic SQL is generated at https://buddypress.trac.wordpress.org/browser/tags/10.4.0/src/bp-xprofile/classes/class-bp-xprofile-group.php?marks=554,573-586#L533. I think the proper fix is probably something like this:

  1. When querying for member-type-linked fields, save them in a separate member_type_fields variable.
  2. Compare this field to those fields passed into exclude_fields
  3. Remove any matches from $member_type_fields
  4. Only then can you merge $member_type_fields into $include_field_ids.

I can write a patch, but first:

  1. Do others agree with my intuition that the current behavior is incorrect?
  2. Does my proposed updated logic seem correct?

Change History (4)

#1 @boonebgorges
23 months ago

  • Description modified (diff)

#2 @boonebgorges
23 months ago

Actually, I'm now doing some additional testing and it looks like I might be wrong about SQL operator precedence. A query like ... NOT IN (123) AND IN (123) ... doesn't seem to include 123. I was seeing something different in my test case because of some other circumstances.

Can anyone confirm this? If so, I think it's probably OK to disregard my suggestions and close the ticket.

#3 @imath
23 months ago

Hi Boone, sorry I missed this one. I'll look at it asap.

#4 @imath
23 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

I confirm excluding a field linked to a member type isn't included into the list of retrieved fields even if the linked member type is part of the query arguments.

I'm closing the ticket :)

Note: See TracTickets for help on using tickets.