Skip to:

Opened 14 years ago

Closed 14 years ago

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

BP_XProfile_Group::get() is restrictive

Reported by: r-a-y's profile r-a-y Owned by:
Milestone: 1.5 Priority: normal
Severity: Version:
Component: Extended Profile Keywords:


I'm working on a plugin which makes use of the "parent_id" parameter in the $bp->profile->table_name_fields table.

However, BP_XProfile_Group::get() doesn't return the "parent_id" if "fetch_fields" is set to true.

BP_XProfile_Group::get() also limits fields whose "parent_id" is 0, which defeats the purpose of my plugin.

There are a few ways to open this up.

Option 1: Change line 117 in bp-xprofile-classes.php to:

$fields = $wpdb->get_results( $wpdb->prepare( "SELECT id, name, description, type, group_id, parent_id, is_required FROM {$bp->profile->table_name_fields} WHERE group_id IN ( {$group_ids} ) ORDER BY field_order" ) );

Option 2: Filter $fields SQL query, see attached patch.


Would like to see this in BP 1.2.6, but understand if this should be moved to BP 1.3.

Attachments (1)

2640.001.patch (856 bytes) - added by r-a-y 14 years ago.
Patch is applicable to the BP 1.2 branch

Download all attachments as: .zip

Change History (6)

14 years ago

Patch is applicable to the BP 1.2 branch

#1 @paulhastings0
14 years ago

  • Summary changed from BP_XProfile_Group::get() is restrictive to [patch] BP_XProfile_Group::get() is restrictive

#2 @johnjamesjacoby
14 years ago

  • Milestone changed from 1.2.6 to 1.3

Bumping to 1.3.

We usually try /really/ hard not to place filters directly on the SQL query itself. Rather we try to abstract the intention out into a function or appropriate API.

If you can come up with a specific solution to what you want to do, let's see a patch for that instead?

#3 @r-a-y
14 years ago

I figured the filter wouldn't make it. No harm in trying!

I don't think there's any harm in hardcoding the proposed change (option #1). It basically removes the restrictive "AND parent_id = 0" and adds the "parent_id" column to the SELECT statement.

The "parent_id" column currently isn't being used AFAIK in the BP 1.2 branch or in BP 1.3 trunk, so that was my rationale.

If you want, I can create a new patch mirroring the other BP component fetch routines for the xprofile component. It's more work for plugins to override it, but c'est la vie!

#4 @DJPaul
14 years ago

  • Keywords has-patch removed
  • Summary changed from [patch] BP_XProfile_Group::get() is restrictive to BP_XProfile_Group::get() is restrictive

Fields such as select boxes, or radio field groups, have each option as an individual item in the database and link to their containing element by the parent_id option. The user profile associates with these containers, not the option records, and so the SQL is hardcoded to parent_id = 0 so that the option records aren't retrieved.

What exactly were you using the parent_id column for?

#5 @r-a-y
14 years ago

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

That cleared up something for me. Should have tested with select and radio fields!

Was working on a duplicating xprofile field plugin. I used "parent_id" as a check to see if a field was duplicated and then I iterated the parent_id for the duplicated field.

Got to redo the logic now to prevent any collisions!

Note: See TracTickets for help on using tickets.