Standardization of the different parts of the sign-up form

[WCUADD]

The sign up form is composed of several sections :

• #basic-details-section
• #profile-details-section
• #blog-details-section

Only the xprofile fields in #profile-details-section are clearly identified with a div and a parametrised class as follows (line 69 in members/register.php in the trunk version (not 2.0.1)

<div<?php bp_field_css_class( 'editfield' ); ?>>

Note that this is very important to give the possibility to add for example a "mandatory" class to the required xprofile fields, as follows for example :

function add_mandatory_xprofile_field_class( $css_classes ) {
global $profile_template;
if ( bp_get_the_profile_field_is_required() ) $css_classes[] = ‘mandatory’;
return $css_classes;
}
add_filter( ‘bp_field_css_classes’, ‘add_mandatory_xprofile_field_class’ );

To render in a similar manner the different parts of the form, the other fields in the other sections should be caracterised equally each one with :

1. a div
2. and please! with a parametrised class in order to let to the developper the possibility to add his own classes. For example to add a "mandatory" class as shown above but not only, there could be other CSS rendering needs.

[boonebgorges]

I'm wary of making broad functional changes to the markup in register.php - adding additional HTML elements will have an effect on people who are using the template but overriding core CSS. That said, I think we'd be happy to see a patch that shows exactly what you have in mind.

and please! with a parametrised class in order to let to the developper the possibility to add his own classes. For example to add a "mandatory" class as shown above but not only, there could be other CSS rendering needs.

We can't simply add the bp_field_css_class() function to the other sections, because they are not technically profile fields (and don't require the xprofile component). But yes, separate functions could be written for this purpose.

[DJPaul]

I think the larger structure changes are something to keep in mind for whenever we eventually build new templates for BuddyPRess; agree with Boone, other than that. :)

[DJPaul]

Closing most tickets related to BP-Default and BP-Legacy, since the upcoming BP-Nouveau template pack (planned for 3.0) will make these redundant.

[DJPaul]

Closing most tickets related to BP-Default and BP-Legacy, since the upcoming BP-Nouveau template pack (planned for 3.0) will make these redundant.