1:N Extended Profile Field Type

[Jeff Sayre]

Currently, most social network platforms do not provide the ability of their users to model 1:N type of data in their profiles. True 1:N relationships are simply listed within a single field. For instance, members of a musicians network list each of their albums (or songs) within a large text field. In effect, they create a simple list in a single record. Another example is a resume-type listing of jobs held simply pasted into a single text field.

Whereas multiple href tags are placed everyday in blog posts in the form of a list, it is a lot harder to extract (parse) that data--each individual link--for other purposes.

Another example would be a member listing their external blogs or websites in their profile field. As it stands now in BuddyPress, an Admin can add a Multi-Line Text Box to allow for such data entry, but it does not allow for the inclusion of href tags. It also stores this data in a single field. This is not a desirable solution.

In this particular instance, placing a member's outbound homepage links, each in their own individual record, makes it a lot more useful. In other words, a 1:N relationship between a member and his or her chosen online homesites. They could add as many as they liked and each would appear in a nicely formatted table, one row for each link, each record. This would provide a more flexible and easy to manipulate subset of profile data for plugin developers to utilize.

This general concept of offering site admins the ability to place multi-record fields (model 1:N type data) within profiles and allow for href tags would help make BP an even more sophisticated platform.

[Jeff Sayre]

I should have mentioned that this field type could be listed as Table in the Extended Profile screen of BuddyPress Admin.

Now, creating a true 1:N relationship would require altering the data schema. This may not be desirable. So, one way around this is to offer a field type of Table that is actually a multi-line text field that outputs the data as a prepackaged table. The Admin screen would allow the admin to choose a few of the table's formatting parameters.

[Jeff Sayre]

Two additional points:

First, a retraction. I was incorrect when I said that a Multi-Line Text Box "does not allow for the inclusion of href tags." Of course, they do. I failed to put in the http protocol command.

Second, the more I think about the direction this should head, I believe that modeling 1:N data may be overkill. Instead, the creation of a special-purpose multi-line text box is most likely the way to go. Call it a Table field and offer the Admin the ability to make a variety of formatting options available to the user. When a user edits their profile data, they can decide how the table should be formatted--based on the choices enabled by the Admin.

When the user is finished editing the profile fields and hits the Save button, it would process any table formatting options and then display the table as requested. A simple example would be to add a background color to every other line. A function could easily determine where each "row" break occurs in the multi-line text box and alternate background color in the outputted table.

[(none)]

Milestone Future Enhancements deleted

[johnjamesjacoby]

There are hooks in place to create custom xprofile fields, so this is certainly possible with the right logic in place to parse the field at set/get time.

[johnjamesjacoby]

Moving closed ticket out of Future Release.