BuddyPress.org

Well if you have access to a database, you can easily change the values. The coding would look something like this, I wrote it but didn’t test it. You’d need BP global enabled to fetch the User ID, and you’d also have to set the field ID to change as you needed it to, or just make a loop that iterates through all the available fields. But this will get you on the right path, I think.

<?php
if(isset($_POST['update']))
{
$dbhost = 'DB_HOST'; //Host of BuddyPress Database
$dbuser = 'DB_USER'; //Username of BuddyPress Database
$dbpass = 'DB_PASS'; //Password of BuddyPress Database
$dbname = 'DB_NAME'; //Name of BuddyPress Database
$field_id = '2'; //ID of the field you are updating
$user_id = $bp->loggedin_user->userdata->ID; //Must have $bp global enabled, can probably grab the user ID in a different fashion if needed
$conn = mysql_connect($dbhost, $dbuser, $dbpass);
if(! $conn )
{
  die('Could not connect: ' . mysql_error());
}

$input = $_POST['input'];

//This query will update the field set with the ID set above, you could have easily change it via coding, I just made it static for ease
$sql = "UPDATE wp_bp_xprofile_data ".
       "SET value = $input ".
       "WHERE field_id = $field_id AND user_id = $user_id" ;

mysql_select_db($dbname);
$retval = mysql_query( $sql, $conn );
if(! $retval )
{
  die('Could not update data: ' . mysql_error());
}
echo "Updated data successfully\n";
mysql_close($conn);
}
else
{
?>
<form method="post" action="<?php $_PHP_SELF ?>">
<table width="400" border="0" cellspacing="1" cellpadding="2">
<tr>
<td width="100">Field data:</td>
<td><input name="input" type="text" id="input" value="<?php xprofile_get_field_data($field_id); ?>"></td>
</tr>
<tr>
<tr>
<td width="100"> </td>
<td> </td>
</tr>
<tr>
<td width="100"> </td>
<td>
<input name="update" type="submit" id="update" value="Update">
</td>
</tr>
</table>
</form>
<?php
}
?>

@zpenacho
The easiest and update proof way is:
https://codex.buddypress.org/developer/customizing/customizing-labels-messages-and-urls/

ah hmm yes, so I was a little wrong 🙂 should have known this, just goes to show… did some work a while back mapping custom tables across to user tables then matching to bp profiles, probably missed these functions at the time.

It syncs your MS sites or so I thought, but I may well be wrong.

@fotant
This is not really a BuddyPress issue! Why not pose this question on the plugins support forum? If memory serves me correct this is a Woo Themes plugin!

@caming
Using a shared server is not a good idea! Typically most shared servers will remove your site if it uses 20% of its resources because its to hard on the CPU! As far as plugins go, a well written plugin doesn’t really bog down a site anymore than BuddyPress itself would!

Why would you fiddle around with the templates code when a more simple update proof solution is available?
Please review: https://codex.buddypress.org/developer/customizing/customizing-labels-messages-and-urls/

@elangley: just had a look at the status of this issue: https://bbpress.trac.wordpress.org/ticket/2425
It seems it has been closed there, as it was submitted on the bbPress, rather than Buddypess Trac.

I submitted this very issue now to the Buddypress Trac: https://buddypress.trac.wordpress.org/ticket/5187 (rather than ask you to do this, I just copied your original submission)

Hi Paul,
In the Buddypress Codex there is information last updated 2 years ago by Sarah Gooding that recommends the two above points that I mentioned for caching. Is this information out of date?
Also the codex points to a support thread:

https://buddypress.org/support/topic/configuring-w3-total-cache-with-buddypress/

This support thread is also a couple of years old and ends with no solution or resolution to BP caching and a lot of frustrated people.

Is it safe to say that the caching plugins do not provide a good solution for Buddypress? And that a server side caching solution is the best option?

I am self hosted on a VPN so for me this is not good news.

It’s blog posts to stream isn’t it, tracks your sites posts.

I can now confirm that there are problems between the integration of bbPress 2.4 and buddypress 1.81.
It turns out that there’s a bug in bbPress 2.4 that does not allow the admin to make a Forum ‘private’ or ‘hidden’. At the moment, the only workaround is to use the bulk edit facility to apply the ‘private’ setting to a forum (but, not, sadly the ‘hidden’ attribute as of yet).
In other words, if you go into the forum setting for the individual forum on the back-end and change the attribute there, it won’t stick. The forum comes back again as ‘Public’.
I used the build editor to change my forum to ‘Private’ and that stopped the replies to topic posts from being broadcast to everyone in the buddypress sitewide activity page. Now, I’m waiting for the ability to make the forums ‘hidden’ for extra security. In the meantime, I’ve been using s2member to lock down the content of the bbPress Group forum. This ONLY works for Group forums, because their topics have a forum-specific URI structure (so URI-restrictions can be used; e.g. ‘/group/<name of group>/forum/’)… whereas non-Group forums just have the ‘/topic/’ URI which is sitewide and cannot be restricted by a particular forum name. This is lamentable, as bbPress is very hard to lock-down otherwise.
It’s taken me many hours to track down all of these niggly problems, which is frustrating, since bbPress and buddypress are meant to be integrated now. So, it seems as if the integration is mucky.
Given all the user confusion regarding forum attributes in bbPress and forum security in buddypress, I would really love to see the development teams come up with a simple, unified interface for managing memberships and access restrictions. Otherwise, we’ll all end up chasing settings in different places, without really understanding their interplay.

This is definitely part of the problem that I’m having. It turns out that there’s a bug in bbPress 2.4 that does not allow the admin to make a Forum ‘private’ or ‘hidden’. At the moment, the only workaround is to use the bulk edit facility to apply the ‘private’ setting to a forum (but, not, sadly the ‘hidden’ attribute as of yet).
In other words, if you go into the forum setting for the individual forum on the back-end and change the attribute there, it won’t stick. The forum comes back again as ‘Public’.
I used the build editor to change my forum to ‘Private’ and that stopped the replies to topic posts from being broadcast to everyone in the buddypress sitewide activity page. Now, I’m waiting for the ability to make the forums ‘hidden’ for extra security. In the meantime, I’ve been using s2member to lock down the content of the bbPress Group forum. This ONLY works for Group forums, because their topics have a forum-specific URI structure (so URI-restrictions can be used; e.g. ‘/group/<name of group>/forum/’)… whereas non-Group forums just have the ‘/topic/’ URI which is sitewide and cannot be restricted by a particular forum name. This is lamentable, as bbPress is very hard to lock-down otherwise.
It’s taken me many hours to track down all of these niggly problems, which is frustrating, since bbPress and buddypress are meant to be integrated now. So, it seems as if the integration is mucky.
Given all the user confusion regarding forum attributes in bbPress and forum security in buddypress, I would really love to see the development teams come up with a simple, unified interface for managing memberships and access restrictions. Otherwise, we’ll all end up chasing settings in different places, without really understanding their interplay.

I tried running the Tools > Forums but it only solved the problem of new topic posts, but not replies to those posts. Here’s my rundown of the situation:
I think the problem has to do with buddypress – bbPress integration.
The bbPress Group Forums appear to be set to ‘Open’ by default, even if they are hidden within buddypress. In fact, I cannot alter this. I tried changing my secret forum to ‘hidden’ within bbPress (2.4) and it won’t save the change – it always comes back as ‘open’.
Therefore, it’s up to buddypress to manage the privacy of the forum. It seems to be doing this with new topic posts (I can confirm that hide_sitewide in the activity stream table is “1” for new posts). The problem is that if someone replies to that post, the hide_sitewide for that reply is set to “0”, even though it’s inside of a ‘hidden’ group forum. To me, this is a serious security breach, as it exposes the forum name, the original topic name, and the contents of the reply in EVERYONE’s Activity stream, whether they are logged in or not, a member of the hidden forum or not.

Actually, this problem is not resolved and appears to be pretty bad. Here’s my rundown:

I think the problem has to do with buddypress – bbPress integration.
The bbPress Group Forums appear to be set to ‘Open’ by default, even if they are hidden within buddypress. In fact, I cannot alter this. I tried changing my secret forum to ‘hidden’ within bbPress (2.4) and it won’t save the change – it always comes back as ‘open’.
Therefore, it’s up to buddypress to manage the privacy of the forum. It seems to be doing this with new topic posts (I can confirm that hide_sitewide in the activity stream table is “1” for new posts). The problem is that if someone replies to that post, the hide_sitewide for that reply is set to “0”, even though it’s inside of a ‘hidden’ group forum. To me, this is a serious security breach, as it exposes the forum name, the original topic name, and the contents of the reply in EVERYONE’s Activity stream, whether they are logged in or not, a member of the hidden forum or not.

I think the problem has to do with buddypress – bbPress integration.
The bbPress Group Forums appear to be set to ‘Open’ by default, even if they are hidden within buddypress. In fact, I cannot alter this. I tried changing my secret forum to ‘hidden’ within bbPress (2.4) and it won’t save the change – it always comes back as ‘open’.
Therefore, it’s up to buddypress to manage the privacy of the forum. It seems to be doing this with new topic posts (I can confirm that hide_sitewide in the activity stream table is “1” for new posts). The problem is that if someone replies to that post, the hide_sitewide for that reply is set to “0”, even though it’s inside of a ‘hidden’ group forum. To me, this is a serious security breach, as it exposes the forum name, the original topic name, and the contents of the reply in EVERYONE’s Activity stream, whether they are logged in or not, a member of the hidden forum or not.

@bp-help
I don’t think you have to explain someone why you do or don’t do things. As Buddypress is Open Source and as long as people do things for free, I’ll appreciate their work. I don’t think that the guy who developed a paid version of the plugin you do for free has to starve or die because of your work – maybe he has to think about some more advanced functions – so, I would be glad to get a free version of your plugin!

Greetings,
noizeburger

hi @ananwebman,

accordingly to what brajesh wrote here 2 weeks ago, his plugin works with bp 1.8 ! So, it doesn’t work should be defined much better, or should be discussed directly with the author.

Despite what you write

this is required to approve accounts and discourage users posting incorrect images

the answer is yes and no.

A signup is approved as soon as the subscriber send back the validdation key received by email.
Now his account exist and is active, ok ?

But if you allow any upload during the subscription process, it’s as like you allow a unknow user to upload a unknow document on your server. What about this uploaded picture if you decide to ban or delete that user ?

This is against any security policy, don’t you think so ?

It’s best practice to not allow anything to a user before his account is approved by the site admin and evtl. some security plugins.