BuddyPress.org

Extended Profile – Basically the profile fields you setup for your audience

An example would be here at buddypress.org, if you wanted to search for people who put “puppies” in their interests field. Rather than searching for puppies and possibly getting someone with the name “I Love Puppies” it will isolate your search down to the field you’re searching in.

Clear as mud? Haha

DJPaul,

Yes it was wrapped, and no line breaks/whitespace.

Thanks,

Phil

I am putting it into bp-custom.php per the thread referenced. The error is that it can’t pass the headers because it already did.

Thanks,

Phil

Hi again,

Well, now I have a fresh install of both WPMU(2.8.5.2) and BP(1.1.2) on my localhost. I do not have any other plugins apart from BP installed and still the same problem.

I have added some ‘required’ custom fields to the ‘Base’ Profile Group. Even though the user fills them during the registration, they still appear blank on the ‘Edit Profile’ page (in BP members) and he has to fill them again (editing and saving works).

I have the same install on my server, but there I upgraded from earlier versions and apparently, this problem does not occur there. Not sure what’s going on??!

Please HEELLP!!

-Sib.

@Chouf1, the code is not for uppercasing; it’s making sure firstname and lastname are stored consistently in the different places where WP/WPMU/BP stores names.

Why is it too much to ask for consistently, reliably stored firstname + lastname in the WordPress world? Uppercasing should be part that imho. It’s utterly ridiculous to have to do that in CSS. Is that even official CSS? Do all browsers support it?

In most software for grownups firstname and lastname fields are at the top of the members/users table, part of the core of the application, the heart of member registration and management. In the WP/WPMU/BP world it’s a messy afterthought, stored halfheartedly in three or four different locations, in different ways, without any synchronization between them. Aaarrrggghhh.

Before a WordPress user account is activated, it is stored in the wp_signups table; there’s a meta field storing various things. Have you checked if its that one?

That’s one of the two places where the lowercase version of the name is stored. My code above updates names with uppercase in the usermeta fields.

My question is which code stores them in xprofile or wp_signups. Where should I apply my nameize() function to get clean names in xprofile?

Cleaning them up before they’re stored in wp_signups would do the trick as well, because I think the xprofile data is taken from there. I don’t think the wp_signup data is used for anything else later, so it has a lower priority to me.

Edit: Of course I’m not trying to uppercase all chars of the name, just the first ones, as used to be custom in western culture. FYI, here’s the nameize function I use:

function nameize($str,$a_char = array("'","-"," ")){

//$str contains the complete raw name string

//$a_char is an array containing the characters we use as separators for capitalization. If you don't pass anything, there are three in there as default.

$string = strtolower($str);

foreach ($a_char as $temp){

$pos = strpos($string,$temp);

if ($pos){

//we are in the loop because we found one of the special characters in the array, so lets split it up into chunks and capitalize each one.

$mend = '';

$a_split = explode($temp,$string);

foreach ($a_split as $temp2){

//capitalize each portion of the string which was separated at a special character

$mend .= ucfirst($temp2).$temp;

}

$string = substr($mend,0,-1);

}

}

return ucfirst($string);

}

Edit2: The CSS solution only works on the first name. The last name still starts with lowercase. Any easy CSS trick for that? I don’t think so.

Apparently the same CSS trick is used in this forum, which would explain why my “username” – cough, spit – is displayed as ‘Peterverkooijen’ instead of ‘peterverkooijen’ as I had entered it. Why is that kind of mess considered acceptable?

Thanks for your reply Jeff. I understand that the register.php directly contains all the elements now.

However, we liked the registration page of the default ‘bphome’ theme (BP 1.0.3) better (earlier) and accordingly we customized our site theme(premium edu-clean home theme for WPMU) to have a register page like that.

To achieve this, I created a custom page template register.php with code similar to that of bphome’s and plonked it in my theme folder. There if you see, the page template is divided into right-column, center-column, left-column (it hosts the registration section)

The code for this register.php is something like:

<?php get_header(); ?>



<!-- div content starts -->

<div id="content" class="widecolumn">

....

....



<div id="left-column">

<div class="register bp_core_widget_welcome">

<h2 class="widgettitle"><?php _e( 'Register for an Account', 'buddypress' ) ?></h2>

<?php bp_core_signup_do_signup() ?>

</div>

</div>



</div><!-- div content ends -->

<?php get_footer(); ?>

It’s the bp_core_signup_do_signup() that is responsible for including the content of the registration page in the left-column.

Here is how my current registration page looks like:

http://www.cmswebusa.com/testsib/reg_pg.png

The registration section on the left is included in that section due to the bp_core_signup_do_signup() call. We still haven’t converted to the new single theme way, but we have already upgraded our BP to 1.1.2 and since then our custom fields just don’t get saved. Not sure what to do here?! I was wondering this could be happening coz of the deprecated function call. Also, how do I still make the registration section appear in the left-column of my page? Is there a function to include the register template or something?

Thanks,

Sib

@DJPaul

Earlier when we were using WPMU 2.8.4a with BP 1.1, our registration form worked fine and all the custom fields got saved just fine. Only after the upgrades, are we experiencing this issue. Did not touch the WPMU install, just upgraded BP, that’s it!

However, we do have a custom registration page which is different than wp-signup.php. On this page we are calling bp_core_signup_do_signup() which is deprecated in BP1.1.2. Could that possibly be creating the issue? Is there any alternative to this call in the newer version?

We really need to fix this asap, users are already grumbling. Any troubleshooting advice is greatly appreciated.

Thanks,

Sib