Should emptying the wp_users table ideally not also delete the connected user data in all the other tables, including xprofile? Or is that not how MySQL works?
No. The way the MySQL tables are set up for the *presses, is that there is no referential integrity. So, if you go into the DB’s backend and change a record or delete a record, it does not cascade the changes to sibling or child tables.
For example, assuming that you were allowed to do this by the table’s schema, if you changed the user ID in the wp_users table, it would not automatically update that ID in all other related tables to reflect the new ID number. Of course, the record ID fields in the *presses are automatically incremented, but you get the point.
Up until recently (past several years or so?), MySQL did not even offer the option of setting up tables with referential integrity. Now it does in a less-than-desirable way. It is not as simple to do in MySQL as it is in PostgreSQL, but it is straight forward enough. It requires that the tables have foreign keys and are created with the Type = InnoDB extension.
Personally, I’m a big PostgreSQL fan, but I do not want to start a PGsql vs MySQL flame war. If you use the *presses, you use MySQL. It’s as simple as that.
But, referential integrity is still not usually set up in many MySQL DBs. So, this is nothing peculiar to the *presses. Why? Because the developers make sure that the code takes care of the updates and cleanup.
This is one, of many, reasons why you really need to know what you are doing in the DB’s backend.
You would edit profile fields like this via /wp-admin/admin.php?page=buddypress/bp-xprofile.php on your installation, but it looks like you can’t add a description for the default Name theme (which you can’t edit or remove).
Nice catch. Report it as an enhancement suggestion on https://trac.buddypress.org/; use your username and password from this site to log in.
The phplist-dual-registration plugin also takes input from registration. It has this function:
function subscribe($input_data) {
if (!wpphplist_check_curl()) {
echo 'CURL library not detected on system. Need to compile php with cURL in order to use this plug-in';
return(0);
}
// $post_data = array();
foreach ($input_data as $varname => $varvalue) {
$post_data[$varname] = $varvalue;
}
// Ensure email is provided
$email = $post_data[$this->email_id];
// $tmp = $_POST['lid'];
// if ($tmp != '') {$lid = $tmp; } //user may override default list ID
if ($email == '') {
echo('You must supply an email address');
return(0);
}
// 3) Login to phplist as admin and save cookie using CURLOPT_COOKIEFILE
// NOTE: Must log in as admin in order to bypass email confirmation
$url = $this->domain . "admin/";
$ch=curl_init();
if (curl_errno($ch)) {
print '<h3 style="color:red">Init Error: ' . curl_error($ch) .' Errno: '. curl_errno($ch) . "</h3>";
return(0);
}
$post_data='action=subscribe&group_ids[]
'.$this->lid.'&email_address='.$this->email_id.'&firstname='.$this->name_id;
Is the $post_data line what I need? Something like this?:
function subscribe($input_data) {
// $post_data = array();
foreach ($input_data as $varname => $varvalue) {
$post_data[$varname] = $varvalue;
}
$email = $post_data[$this->email_id];
$name = $post_data[$this->name_id];
}
And then I could use $email and $name in my function to “do stuff” with?
Or can I use $post_data[$this->email_id] etc. directly? Is that the simple answer to my original question?
Why is the $post_data commented out?! Don’t I need it?
Do I need other pieces to make it work? For which fields would this work; only those from wp_users or xprofile as well? What about custom fields, including the real name/first name/last name mess?
yes, but get_userdata() doesn’t return values like avatar and additional profile fields from registration. I found some functions in a core but I am not sure I should go that deep to get this info.
bp_core_get_userurl()
bp_core_get_avatar()
bp_core_get_userlink()
and finaly the best one:
xprofile_get_field_data()
You could use BuddyPress’ x-profile fields to create a required, custom radio button for gender.
The hard part will be hacking the activity feed to show the pronoun differential.
You’d have to create your own function similar to Buddypress’ bp_your_or_their() function.
Then apply that function as a filter on bp_activity_content_filter.
I’m not sure what you want to do, but with this code, you can get a list of the options and the amount of users who have selected the option. Note: for selectbox and radio fields only.
$field_id = 1; // this should be the id of the
// field you want, see your wp_bp_xprofile_fields
// database table to find it
global $wpdb;
$sql = "SELECT value FROM {$wpdb->base_prefix}bp_xprofile_data WHERE field_id = {$field_id} ORDER BY id DESC";
$result = $wpdb->get_col($wpdb->prepare($sql));
foreach($result as $row){
if(strlen($row) > 0){
$values[$row]++;
}
}
$i = 0;
foreach($values as $key => $value){
$i++;
if($i != 1){
echo ", ";
}
echo $key . "(" . $value . ")";
}
Ahh okay… forget my last post entirely then! haha.
Not sure if this will work at all…
$myxprofileFields = new BP_XProfile_ProfileData::get_value_byfieldname('Hair Color');
echo $myxprofileFields();
This is where my knowledge of PHP stops here!
I’m not that great with classes and objects.
Hey Chris,
I’m assuming you’re using one of the prebuilt fields called “State”.
I didn’t look too closely at the classes or template tags, but check out /buddypress/bp-xprofile/bp-xprofile-classes.php.
There’s a function called “get_prebuilt_field_data()” that might help you out there.
You’d have to pass the CSV file to that function, but that might help…
Another way to output the “State” data would be to parse the actual CSV itself that is used for the data. The CSV can be found in buddypress/bp-xprofile/prebuilt-fields/states.csv.
Hope that helps somewhat!
This plugin attempt doesn’t break anything, but still doesn’t put first_name and last_name in wp_usermeta either:
`
<?php
/*
Plugin Name: Real Name Synchro
Plugin URI: http://
Version: v0.001
Author: peterverkooijen
Description: A plugin to store firstname and lastname from the fullname field in Buddypress registration in WPMU usermeta tables.
*/
function real_name_synchro() {
global $bp, $wpdb, $bp_user_signup_meta;
$fields = BP_XProfile_Field::get_signup_fields();
if ( $fields ) {
foreach ( $fields as $field ) {
$value = $_POST[‘field_’ . $field->id];
}
}
$field->id = ‘1’;
$fullname = $value;
$space = strpos( $fullname, ‘ ‘ );
if ( false === $space ) {
$firstname = $fullname;
$lastname = ”;
} else {
$firstname = substr( $fullname, 0, $space );
$lastname = trim( substr( $fullname, $space, strlen($fullname) ) );
}
update_usermeta( $user_id, ‘nickname’, $fullname );
update_usermeta( $user_id, ‘first_name’, $firstname );
update_usermeta( $user_id, ‘last_name’, $lastname );
$wpdb->query( $wpdb->prepare( “UPDATE {$wpdb->users} SET display_name = %s WHERE ID = %d”, $fullname, $user_id ) );
$wpdb->query( $wpdb->prepare( “UPDATE {$wpdb->users} SET user_url = %s WHERE ID = %d”, bp_core_get_user_domain( $user_id ), $user_id ) );
}
//Actions
add_action(‘user_register’, ‘real_name_synchro’);
//Filters
?>`
Can anyone suggest fixes or am I fundamentally on the wrong track?
Are you using a custom theme? Have you added any required fields via the “BuddyPress > Profile Fields Setup” in WPMU’s backend?
By default, WPMU with BuddyPress installed is setup to do exactly what you are asking–have one “Username” field and one “Name” field on the signup page.
Look at /bp-xprofile/bp-xprofile-signup.php. I’m not writing your code for you, but from the looks of things, I think you need to remove_action() the xprofile_add_signup_fields() call, and add_action your own version of this function, but obviously removing the avatar form field.
Best place for the code would probably be /plugins/bp-custom.php and make your add_action have a priority of 11.
Friendly monday morning bump!
3125432Inactive
I just went through this so I am a voice of experience.
Each additional profile field you add in the profile field setup is added to the xp_bp_xprofile_fields table. By default, there is only one field filled in on the wp_bp_xprofile_data table, which is the “full name.” Once you or someone else begins to add their additional information and hits save, the data table will expand and in a strange albeit normal way. The id of the user, say ‘2’ will be listed repeatedly, as they have multiple pieces of information stored. The id of the table counts sequentially, so you’ll begin to see that number grow exponentially.
Hope that helps.
Brian
To follow up on this, the table you pointed out only has the default field “full name” not any of the custom fields I created. What am I missing?
Well, I found a workaround, but I’m really nervous about unintended consequences. I went into the db and changed “is_required” on the “Name” field from “1” to “0”. Now I can register without the extra profile fields.
It seems that the name field gets set to the username, which is what I need.
Any thoughts about the unintended consequences of this?
Thanks.
Jeff, fantastic, this works.
Just to make sure I understand *why* it works… by just running the remove_filter() function in bp-custom as I was doing earlier, I guess it was running before the filter was added. What you are doing is delaying the remove_filter() call until all plugins are loaded.
Do I have that right?
Thanks very much.
Hi r-a-y,
Glad the filter is useful to you!
I think the answer to your question is yes, John Smith’s profile would come up in that kind of scenario. The links that are created in BP profiles are merely full-text searches on all BP profiles (this is the link behavior out of the box, and my filters do not change this). Even if the name “Smith” in John’s profile doesn’t link to http://[your-buddypress-url]/members/?s=Smith, that search URL will still be live and accessible from the regular BP search box.
I haven’t looked into the details, but it should be possible to build a plugin that limits search in different ways. You might, for instance, search all profile fields except those that have been tagged as non-searchable (last name, for example). Another strategy: you might only return a hit on (for example) “Smith” if the result appears between anchor tags; in this way, non-linked profile fields would automatically be excluded. The first kind of solution is probably the better one, and I imagine it will be quite easy once field-specific profile search comes along in BP 1.3 https://buddypress.org/about/roadmap/
@Reboot
Okay, thanks to Burt for waking me up enough in IRC to point out my errors, here’s what you need to place in your bp-custom.php file:
<?php
function remove_links(){
remove_filter( 'bp_get_the_profile_field_value', 'xprofile_filter_link_profile_data', 2 );
}
add_action( 'plugins_loaded', 'remove_links' );
?>
That should work.
I’m going to get some sleep now.
Thanks Jeff.
So to sum up, I have the following line in “plugins/bp-custom.php”
remove_filter( 'bp_get_the_profile_field_value', 'xprofile_filter_link_profile_data', 2 );
But the links still appear on my profile page. I can remove the links by commenting out line 15 in bp-xprofile-filters.php, but I’d love to get this right without the mod to a core file.
I believe that bp-custom.php should actually go in “mu-plugins”
No. bp-custom.php goes in /plugins/. See line 9 of bp-core.php.
UPDATE 2: I see that in 1.02 the filter is added to ‘bp_get_the_profile_field_value’, so I changed this in the line above, but still the links hang in there.
I also wanted to remove the linking in the profile fields, so I added the following line (given above by Fishbowl81) to bp-custom.php, which is in the “plugins” directory.
remove_filter( 'bp_the_profile_field_value', 'xprofile_filter_link_profile_data', 2);
The profile fields still have the links though. Is there something special I need to do aside from putting the line in bp-custom.php?
UPDATE: I believe that bp-custom.php should actually go in “mu-plugins”. Also, I did add the php script tags (<?php and ?>) around my code in this file. Still the links appear.
Hi mohitkro5,
It sounds like you’re trying to use WordPress shortcodes in Buddypress fields.
Where are you trying to embed your videos?
BuddyPress doesn’t allow WordPress shortcodes to work in profile fields, wire posts and group forum posts.
bbPress has a few plugins to parse videos.
I tried very hard to get this to work, and I can not get that code to work, even in the default template or even by creating a blank .php with pasting in the code listed above to upload to the mu-plugins directory.
First of all you should not be placing the code in mu_plugins. Either place it in your bp-custom.php file, create your own plugin that resides in /wp-content/plugins/, or put the code in your member theme’s functions.php file.
But, in the BP Profiles section, the users can simply change their login username to anything they want. This will obviously lead to database errors and people changing their usernames to cause conflicts.
Where do you see the option in BuddyPress to change your login username? The only option you have is to change your display name. This is an entirely different piece of datum.
Yes, when a user registers for a new account, if they choose to enter the exact same datum in the username field as the “Full Name” field, then that is their choice. But, this data is stored and used in different ways. The datum from the “Full Name” field gets placed in two different tables: it populates the display_name field in the wp_users table and it is recorded in the wp_bp_xprofile_data table corresponding to the meta field entitled “Full Name” in the wp_bp_xprofile_fields table.
When a user decides to edit their “Full Name” field via BuddyPress, the changes to that piece of datum have no affect on the login username field stored in the user_login field of the wp_user WordPress table.
So, on the same registration page, you have two questions requesting for what their username is going to be. This is quite ridiculous, and so far their is no way to shut that part off. Does anyone have any ideas?
This is not correct. These fields serve different purposes as detailed above. One field is the user_login, the other is the user’s display name.
