Skip to:
Content

BuddyPress.org

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#7142 closed defect (bug) (fixed)

User queries using the 'bp_pre_user_query_construct' action to filter 'member_type' return all members instead matching members.

Reported by: rekmla Owned by: r-a-y
Milestone: 2.6.1 Priority: normal
Severity: normal Version: 2.6.0
Component: Members Keywords: has-patch needs-unit-tests
Cc:

Description

We're attempting to set query_vars['member_type'] using the 'bp_pre_user_query_construct' action. All members are being returned, not just members with a specific member type. I've traced the problem to the function get_sql_clause_for_member_types() in the class BP_User_Query which is failing to preg_match the where clause of the intermediate taxonomy query this function performs. Said where clause has a leading 'AND' and is wrapped in '()' which is not accounted for in the regex used when converting this clause to a subquery.

A second issue found is that restore_current_blog() happens too early resulting in the wrong $wpdb->term_relationships value being used in this optimization.

Attachments (2)

7142.patch (1.5 KB) - added by rekmla 3 years ago.
7142-1.patch (721 bytes) - added by rekmla 3 years ago.
Simplified patch

Download all attachments as: .zip

Change History (7)

@rekmla
3 years ago

#1 @rekmla
3 years ago

Oddly, I cannot recreate the problem I had with a null return value for the function get_sql_clause_for_member_types().

However, the second issue - restore_current_blog() happening in too early is still true.

Patch adjusted accordingly.

@rekmla
3 years ago

Simplified patch

#2 @rekmla
3 years ago

  • Priority changed from high to normal

Update on recreating this issue. This is a similar issue to the issue reported in https://buddypress.trac.wordpress.org/ticket/7144.

This issue occurs when using the 'bp_get_taxonomy_term_site_id' filter to override the default table location for the 'bp_member_type' taxonomy.

All members are being returned, not just members with a specific member type. I've traced the problem to the function get_sql_clause_for_member_types() in the class BP_User_Query which is failing to preg_match the where clause of the intermediate taxonomy query this function performs. The match is failing if the value of $wpdb->term_relationships is different than the value at the time the taxonomy query is generated.

This is because restore_current_blog() happens too early resulting in the wrong $wpdb->term_relationships value being used in the match.

#3 @r-a-y
3 years ago

  • Keywords needs-unit-tests added
  • Milestone changed from Awaiting Review to 2.6.1

Thanks for the proposed fix and for your investigation, @rekmla.

This sounds right to me. If you are able to, if you are able to write a unit test that triggers this problem, your fix will be committed faster.

#4 @r-a-y
3 years ago

  • Owner set to r-a-y
  • Resolution set to fixed
  • Status changed from new to closed

In 10912:

Taxonomy: Fix usage of restore_current_blog() when using bp_get_taxonomy_term_site_id().

See #7077 where we introduced bp_get_taxonomy_term_site_id().

Props remkla.

Fixes #7142, #7144 (2.6-branch).

#5 @r-a-y
3 years ago

In 10913:

Taxonomy: Fix usage of restore_current_blog() when using bp_get_taxonomy_term_site_id().

See #7077 where we introduced bp_get_taxonomy_term_site_id().

Props remkla.

Fixes #7142, #7144 (trunk).

Note: See TracTickets for help on using tickets.