Skip to:
Content

BuddyPress.org

Opened 7 years ago

Closed 7 years ago

#4229 closed defect (bug) (no action required)

Member Search oddness.

Reported by: DennisSmolek Owned by:
Milestone: Priority: normal
Severity: normal Version: 1.5.5
Component: Members Keywords:
Cc: DennisSmolek

Description

I don't know if this is the right place but I'm having some odd handling of the members searching...

I have a BP site that I imported data from another service. I put all of this data into the wp_usermeta table as I noticed bp_core_get_users searches usermeta and I wanted to be able to use some other wp plugins.

So with 25,000 users everything seems to be working, the members page has 1700 pages, it says 25,000 users but the search results aren't right.

When I search "Smith" I first got 31 results. I ran the search on the back end and got 283 results (which is correct)

So clearly the front end search wasnt working right. So I found a user that wasn't showing up and went to their profile. Worked no problem. Then I searched for that user.

Suddenly that user shows up, AND the results jumps up 15 more people. I did it again, same thing! Each time I search for a user that is on the backend that wasnt on the front end they suddenly appear along with a dozen or so other records.

I get similar results with two different servers with very different configurations...

Also the back end search is pulling other data such as their email address while the front end search ignores it. This is annoying is I'm trying to push away from using the back end for anything.

Now I'm wondering if I should just switch to xprofile data and migrate this huge DB over, supposedly I'll be able to search by xprofile data too and there are firstname lastname fields in that. If that were to deliver more consistent results I'll do it..

Change History (4)

#1 @r-a-y
7 years ago

I have a BP site that I imported data from another service. I put all of this data into the wp_usermeta table as I noticed bp_core_get_users searches usermeta and I wanted to be able to use some other wp plugins.

bp_core_get_users() doesn't search on usermeta unless you specifically pass the 'meta_key' and 'meta_value' terms.

eg.

bp_core_get_users( array(
     'meta_key'   => 'THE_USER_META_KEY_YOU'RE_SEARCHING_FOR',
     'meta_value' => 'THE VALUE YOU'RE SEARCHING FOR'
) );

This isn't done by default in the member search form.

If you already know this and you're filtering bp_core_get_users(), then disregard what I wrote!

---

Now I'm wondering if I should just switch to xprofile data and migrate this huge DB over, supposedly I'll be able to search by xprofile data too and there are firstname lastname fields in that. If that were to deliver more consistent results I'll do it..

If you followed this approach, then the member search form would work the way you wanted it to.

Edit: Regarding first name and last name fields, view this ticket as well - #2434.

Last edited 7 years ago by r-a-y (previous) (diff)

#2 @DJPaul
7 years ago

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

Closing; seems to be a support request rather than a bug. If a bug, please re-state problem and re-open ticket. Thanks.

#3 @DennisSmolek
7 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

The issue is if you create users with wordpress it doesn't register any activity. BP ignores any users that have no activity with the default sorting. Wordpress doesn't use activity as a sorting method so it loads those users.

To combat this when I add a user with my script I also register a activity with:

bp_update_user_meta( $user_id, 'last_activity', bp_core_current_time() );

Now I havent written a patch but I'm sure BP could hook into wp_update_user() or wp_insert_user() and change last_activity to match..

#4 @boonebgorges
7 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

DennisSmolek - BP shouldn't be registering last_activity upon user creation - that'd be a perversion of what's intended by 'last_activity'. However, you're quite right that the OP should include something like this in the migration script.

Note: See TracTickets for help on using tickets.