Skip to:

Opened 2 years ago

Last modified 6 weeks ago

#6783 reopened enhancement

Groups: Add Profile Fields and Profile Field Groups

Reported by: mercime Owned by:
Milestone: Under Consideration Priority: normal
Severity: normal Version:
Component: Groups Keywords: dev-feedback
Cc: scotth0407@…, lmoffereins@…


What's good for the Members would be great for the Groups as well. This is the first stage towards bringing over some Member improvements over to the Group components. Second stage would be creating Group Types just like member types, but that's for another ticket.

Attachments (1)

example-1.jpg (115.8 KB) - added by Paul Gibbs 3 months ago.

Download all attachments as: .zip

Change History (27)

#1 @imath
2 years ago

Hi @mercime

I think @slaffik built a plugin around this need > BP Groups Extra.

And I think we should reverse the order, do the groups taxonomy first and profile fields once done :)

There's already a ticket for a Groups Taxonomy > #4017

#2 @mercime
2 years ago

do the groups taxonomy first and profile fields once done :)

@imath Thank you for your feedback :) Just checked the plugin, it has not been updated for 8 months (WP 4.1/BP 2.2.) and is not accessible. But yes, I'm following the Groups Taxonomy ticket now :)

#3 @slaFFik
2 years ago

That plugin is old, was written before BuddyPress 2.0 era.
Currently I have finished (more or less) BuddyPress Group Types plugin and BuddyPress Group Fields (WIP), both will be separate but integrated into each other and released in January/February.

#4017 is cool, but no one knows when it will be ready. That's why I'm creating own solution. And, well, for fun too.

#4 @Paul Gibbs
2 years ago

  • Keywords 2nd-opinion added
  • Milestone changed from Awaiting Review to Under Consideration

From a core perspective, I'm not sure that Groups would benefit from a profile fields system exactly like what we have in Members. A question that doesn't have an easy answer is, which group members would be permitted to edit the fields?

Even a more simpler implementation leads me to then being concerned about code duplication; refactoring xprofiles to work for both members and groups would be a very complicated task.

#5 @imath
2 years ago

which group members would be permitted to edit the fields

The same that are allowed to edit the group's description & name :)

refactoring xprofiles to work for both members and groups would be a very complicated task.

I agree, but it would be so awesome to have a generic xProfiles component working for any objects (Members, Groups, Blogs). I think we should do this :)

#6 @mercime
2 years ago

but it would be so awesome to have a generic xProfiles component working for any objects (Members, Groups, Blogs)

@imath Gazooks! What a great idea! And maybe later some BP devs can use hooks of the new generic custom fields and field groups to use for their own plugins as well. But that's for another day :)

which group members would be permitted to edit the fields?

@DJPaul For xProfiles, Site Admin > Member, so for the others
For Groups, Site Admin > Group Admin/s, and
For Blogs, Site Admin > Blog Admin/s :)

This ticket was mentioned in Slack in #buddypress by imath. View the logs.

2 years ago

#8 @Paul Gibbs
21 months ago

  • Milestone changed from Under Consideration to Awaiting Review

#9 @Paul Gibbs
21 months ago

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

Some interesting ideas here, including having xprofile flexible enough to work with other types of object, not just users.
Narrowing the scope to profile fields for Groups, I think we need some more evidence that 80% of BuddyPress sites would want to use this.

#10 @mercime
20 months ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened

Reopening this ticket as we are no longer tied to the 80% rule :)

#11 @mercime
20 months ago

  • Milestone set to Future Release

#12 @Paul Gibbs
20 months ago

  • Milestone changed from Future Release to Awaiting Review

I would say we are. It's just that the type of users we are targeting has changed, we still need to implement things for the majority of developers and site builders.

I think this needs some more consideration about if it's something we want to do. From a technical perspective, my impression is that this is kind of straightforward (add a field_type to xprofile and treat it like a post type, add a group extension), but has quite a bit impact in terms of requiring (new?) templates and implementing lots of controller logic, so probably goes deeper and is more involved that is immediately obvious.

It's also worth considering if we wanted to implement some API pieces for this, but leave the actual front-end implementation out of core and into a separate plugin.

I'm moving this ticket back to the Under Consideration milestone so people can see this and give feedback, rather than Future Release, which is somewhat of a graveyard.

#13 @Paul Gibbs
19 months ago

  • Milestone changed from Awaiting Review to Under Consideration

#14 @Paul Gibbs
8 months ago

  • Milestone Under Consideration deleted
  • Resolution set to maybelater
  • Status changed from reopened to closed

Given the understanding that Groups is conceptually a taxonomy, assigning profile fields to a Group would fit, but this would require significant engineering effort. We'll re-open the ticket in the future if anyone wants to work on it, and see it through.

#15 @imath
6 months ago

  • Milestone set to 3.0
  • Resolution maybelater deleted
  • Status changed from closed to reopened

I've been working lately on this feature as someone asked me to. I think we could use a new property for the group of fields to store what kind of objects their fields relate to. Then the Groups component could create a specific table to save the data of these fields. Of course, it would require some adaptations to the xProfile API but i'm not sure it would be a too huge work. FWIW, here's a plugin illustrating this suggestion.

If you think it's a possible road for the xProfile fields, i'd be happy to submit a patch about it.

#16 @Destac
6 months ago

  • Cc scotth0407@… added

I am just going to expand into a use case for users. I currently am on a project focused on Nashville TN and it's a news site with heavy social features to illustrate the community of Nashville. I added member types and allowed users to register such as engineers (sound), artists, and a few others.

The group types API allows me to make a couple of page types such as Record Label (as an example) or as the case I am looking at which is "Band" there can be multiple artists in a single band to which they would be admins of such a group. However, this is an example of a use case where you would expect the ability to add a description or "biography" which can be done via xprofile fields for users or a link to their own personal website or just a link to their Apple music album.

In this case, it doesn't make sense to make a member type for a "band" because multiple artists can register and be part of the same band. But the only way to promote the band and to get that sense of exposure is to use profiles which doesn't make sense. IMO this is the equivalent of someone registering a profile on facebook as their business page. It works but it's not what it's for.

So I am in favor in expanding the current xprofile fields to a group fields API as it makes sense.

#17 @Paul Gibbs
3 months ago

  • Keywords dev-feedback added; 2nd-opinion removed

I've been thinking about this idea this afternoon, and I'm pretty excited by it. I think if we can get some agreement on the DB schema changes, we can get *some* progress made on that and any API changes into 3.0, and target a subsequent release for UI/template changes (into Nouveau only, of course).

I quite like how successful the XProfile tables schema has been (compared to say, the Activity tables schema), so I don't think we need to migrate all of this into a brand new table.

I've looked at the current DB schema and attached example-1.jpg of proposed changes, which are:

1) Rename wp_bp_xprofile_data.user_id to object_id.
2) Add column wp_bp_xprofile_data.object_type. All existing records would be set to a value, e.g. "xprofile".
3) Add column wp_bp_xprofile_groups.group_type. All existing records would be set to a value, e.g. "xprofile".

1) is for clarity. 2) is to distinguish between User IDs and Group IDs. 3) is to distinguish group types.
Indexes etc would also be set appropriately, I haven't included that on the graphic.

This doesn't seem *too* complicated. Next work would be to amend the basic set/fetch methods to support a new "object type" (etc) parameter, then upgrade routines to update the schema, and then put all of that into 3.0.


@Paul Gibbs
3 months ago

#18 @Paul Gibbs
3 months ago

(Looks like I mis-connected the relationship line between meta.object_id and, but hopefully the idea comes across, rather than perfection).

This ticket was mentioned in Slack in #buddypress by djpaul. View the logs.

3 months ago

#20 @John James Jacoby
3 months ago

I can get behind these schema changes.

I suspect the functional code changes to support this will be less easy. I.E. the object_type parameter will end up at the end, and not next to object_id which would be ideal.

Perhaps we can look at refactoring this into a BuddyPress Fields API, and turning existing functions into legacy wrappers for a new bp_fields_ prefix.

#21 @David Cavins
3 months ago

I think this is a great idea, generally. I'm thinking that we need to store what kind of object each group was associated with, but Paul's doing that in the data table. (I guess that would allow you to apply the same profile fields to a user and group, but maybe it's simpler to make them distinct?)

What about:
1) Rename wp_bp_xprofile_data.user_id to object_id
2) Add wp_bp_xprofile_groups.object_type to specify what kind of thing this profile field group applies to.

Geez, I wish that groups of fields weren't called groups. I've been confused by that so many times, because I work with actual groups often, ha ha.

As to the arguments, many of the functions already accept an array of arguments. Maybe this is the time to push the stragglers in that direction, too.

#22 @Paul Gibbs
3 months ago

I suppose if we wanted to allow the same field to be in multiple field groups (regardless of type of group), we need the 2) I suggested: wp_bp_xprofile_data.object_type otherwise it's not needed...

It's getting confusing for me given the time I spent on this earlier! I might POC this.

#23 @Offereins
3 months ago

  • Cc lmoffereins@… added

So following @dcavins logic, this would mean that the object type distinction is applied at the field group level only:

  1. Field groups can be assigned to types of objects (users, user groups or else) by means of wp_bp_xprofile_groups.object_type (or .group_type in @DJPaul's diagram).
  2. Fields are always registered in a single field group, no matter what object type it applies to.
  3. Field data is always registered for a single field, no matter what object type it applies to.

This omits the requirement for an additional column in the field data table.

Side note: this would result in more complex logic for querying field data. Imagine a situation when querying for field data belonging to a single user. In the current situation field data always belongs to this singular object type, but in the new setup you would always need to know the field groups for the object type and their related fields beforehand.

#24 @Paul Gibbs
3 months ago

That's a good write-up, thanks @Offereins.

You are correct about the more complex query for individual field data belonging to a specific user, but I'm sure we'll have everything cached to minimise the input. I hope the extra complexity is all internal to BuddyPress (and, of course, anyone with custom SQL queries, but they're on their own if they've chosen to do that).

#25 @John James Jacoby
3 months ago

Related: #6350. I'd like to see that happen first, because it will be difficult or impossible to do after this ticket is done.

Not trying to put the stop on work going on here. More trying to say that I'd like to work on #6350 immediately so that the complexity of the work in this issue is basically halved (one fewer table to change, likely many fewer APIs to change.)

#26 @Paul Gibbs
6 weeks ago

  • Milestone changed from 3.0 to Under Consideration
Note: See TracTickets for help on using tickets.