BuddyPress.org

Hi Manoj,

Thanks for that mate. It solved the issue.

Dan

Hi r-a-y,

Nope none at all pal. Haven’t modified a single bit of code, except to edit the wp-config file when installing MU.

That was it.

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?

I feel really guilty and stupid.. im not trained.. but.. SVN sounds even more scary (LOL)

I see this in the TRUNK version:

211 if ( ” != locate_template( array( ‘registration/register.php’ ), false ) || ” != locate_template( array( ‘register.php’ ), false ) )

212 die;

211 if ( locate_template( array( ‘registration/register.php’ ), false ) || locate_template( array( ‘register.php’ ), false ) )

212 wp_redirect( bp_root_domain() . BP_REGISTER_SLUG );

This is my version:

if ( false === strpos( $_SERVER[‘SCRIPT_NAME’], ‘wp-signup.php’) )

return false;

if ( ” != locate_template( array( ‘registration/register.php’ ), false ) || ” != locate_template( array( ‘register.php’ ), false ) )

die;

Can I just cut and paste whats on the trunk to replace what I have?

Aargh .. and Duhhh Stoopid me – forgot to enable it for you – deep apologies – I’ve reset it to allow user and blog creation / registration – I’ll knock it out again when you’re done.

Goes to find suitable knobbly wall to bang head upon.

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

Yup, that is the problem it seems – the old 2-theme structure.

I am using the premium ‘edu-clean’ home theme coupled with the BP default ‘bpmember’ theme which is no longer in existence after I have upgraded my BP to 1.1.2. I needed to customize my ‘register’ page. Instead of using WPMU wp-signup.php, I wanted my signup page similar to bphome’s.

To accomplish this, I simply created a page template(register.php) similar to bphome’s. Added a new page with the register slug, associated it with this template and made the user redirect from wp-signup.php to /register.

My problem is, on my register template I have used <?php bp_core_signup_do_signup() ?> to display the registration form in the left-column widget. Now, from what I understand, this function is deprecated in 1.1.2. Perhaps, this is the reason my profile fields aren’t getting saved? I still am not sure, but in any case, I would like to replace this function with its equivalent function in 1.1.2.

I want to retain this layout (i.e using edu-clean as the WPMU theme and bpmember as the BP theme) as of now. I still haven’t gotten the hang of the new single-theme architecture, but I’m working on it. Until I get that right, is there any way we can save our site users the trouble of having to save their profile fields twice?

Please advice!

-Sib