[@gorbett Participant 8 years, 5 months ago]

SOLUTION (finally)

Thanks @henrywright and @coffeywebdev for pointing me in the right direction. Here is what I ended up with.
1. Enable child theme and copy the BP register.php file to the child theme.
2. In the child theme’s style.css, I entered to remove the xprofile fields from the register.php page:
.editfield {
display: none;
}
3. In the child theme’s functions.php file I have this (again, reassign the xprofile fields ‘field_3’ and ‘field_4’ because of their position in the DOM:

add_action( ‘bp_signup_pre_validate’, ‘assign_username’ );

function assign_username(){
if ( isset( $_POST[‘first_name’] ) ) {
$_POST[‘field_3’] = $_POST[‘first_name’];
$_POST[‘field_4’] = $_POST[‘last_name’];
$_POST[‘signup_username’] = create_username();
foreach ($_POST as $key => $value) {
echo $key . “: “;
echo $value;
echo “<br>”;
}
exit();
}
}

function create_username() {
$i = 0;
$username = $_POST[‘field_3’] . $_POST[‘field_4’];
while (username_exists( $username )) {
$username = $username . ++$a;
}
return $username;
}

I am simply creating a username from first name and last name and then start to append a number when inevitably someone with the same name registers. I need to add more validation on the username to ensure that it is <= 50 characters, but this finally worked for me.

Thanks again to the community for pointing me in the right direction!

[@gorbett Participant 8 years, 5 months ago]

Issue now is with the extra BP fields coming later in the DOM than my fields on my register.php. Even though I have the css set to display: none for the actual xprofile fields, my fields are not carrying through the $_POST values because display: none does not remove the fields from the DOM.

I guess I can try adding hidden fields after the xprofile fields and set them to the values being entered in my fields, but that seems kinda clumsy.

I added test code to check the $_POST values at where I can see the fields coming over as empty strings: https://pantest.centralus.cloudapp.azure.com/register/

[@gorbett Participant 8 years, 5 months ago]

Figured it out. Turns out that the button html element of the form was causing it. Fixed it by simply changing the button to <input type=”submit”>.

Thanks again!

[@gorbett Participant 8 years, 5 months ago]

thanks for all the help. I ended up doing something like this in my functions.php child theme:

function assign_username() {
    if ( isset( $_POST ) ) {
        $_POST['signup_username'] = create_username();
    }
}
add_action( 'bp_signup_pre_validate', 'assign_username' );

function create_username() {
    $i = 0;
    $username = $_POST['field_3'] . $_POST['field_4'];
     while ( username_exists( $username ) ) {
         $username = $username . ++$i;
     }
    return $username;
}

However, now I have some weird behavior that is asking me if I want to leave the page when submitting the form (typical window.onbeforeunload event when entering information: http://stackoverflow.com/questions/1119289/how-to-show-the-are-you-sure-you-want-to-navigate-away-from-this-page-when-ch) although I have no idea what is triggering it on my custom register.php (https://pantest.centralus.cloudapp.azure.com/register/).

So I think my code above solves my $_POST issue, but now I have another one. Going to run through some tests to debug it now.

Thanks again for the prompt help. Was hoping people still check out these forums.

[@gorbett Participant 8 years, 8 months ago]

Thanks for the reply, Dan. Seems like the data entry should follow the same convention as set for viewing, but obviously still up for debate.
Looks like until that debate is settled, I can accomplish something using the ‘bp_get_the_profile_field_datebox’ filter.

Thanks again!