Description sould be part of the $field_type->edit_field_html() ? / scope of this function

[WCUADD]

The $field_type->edit_field() function in bp-xprofile-classes.php deals with the rendering of each xprofile field according to its type :

• name of the field in a <label>
• text "required" if the field is required
• mention of the occurred errors if it is the case (see ticket #5595 and #5738)
• call to the edit_field_options_html() to print the form inputs

The description of the field which gives instructions to the user is out of the scope of the edit_field() function. But in a lot of cases, the description must be placed before the <input> in order to be taken into account by the user before beginning to fill in the field.

The fact that the description is out of the scope of the edit_field() function prevents to place the description as one wants.

This idea should be extended to the visibility dealing process, which is currently taken into account into the templates (members/register.php and members/single/profile/edit.php), whereas it could be more benefic to be at least factorised in a single function with its appropriate filters and called inside the edit_field() ?

The global idea is to give more flexibility to order or modify the different elements which compose the xprofile field without having to modify the templates or even the core files (bp-xprofile-classes.php).

It is only a suggestion.

[boonebgorges]

I like this idea - I agree that it makes more sense for this markup to be within the scope of the BP_XProfile_Field_Type class, if not the edit_field_html() method itself. But this is going to be a very difficult thing to implement, because the description and visibility markup is currently called directly from the templates. So we'd have to remove it from the templates. But then anyone who is overriding the core templates will see the fields twice.

For this reason, I think the suggestion, while a good one, will have to wait until we do a rewrite of the xprofile editing templates, and do a full break of backward compatibility with bp-legacy. See #4952 for ongoing discussion.

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/