[mistercyril]

Any developers interested?

[mistercyril]

@naijaping, thanks for your input but unfortunately it doesn’t work with BuddyPress…
So the problem still stands.

[mistercyril]

More and more people are using BuddyPress as a private community for co-workers etc… So when a co-worker leaves the organization and comes back a few months later, it would be nice to be able to re-instate their account without loosing everything they contributed to the platform.

I think I understand there is a new action, taking place right before the user is actually disabled, that clears all of the user data. I’m guessing the “unset” strategy might help here but i’m really at a loss when it comes to the actual syntax.

Please help me 🙂

[mistercyril]

Up

[mistercyril]

I found a post written by Boone ( http://bpdevel.wordpress.com/author/boonebgorges/ ) where he says something about replacing all references to “$current_user” with “$bp->displayed_user” in order to allow super admins to have access to user settings.

I am using BuddyPress v.1.2.8 and found this code in bp-core-settings.php…

/***** NOTIFICATION SETTINGS ******/

function bp_core_screen_notification_settings() {
global $current_user, $bp_settings_updated;

$bp_settings_updated = false;

if ( $_POST ) {
check_admin_referer('bp_settings_notifications');

if ( $_POST ) {
foreach ( (array)$_POST as $key => $value ) {
update_user_meta( (int)$current_user->id, $key, $value );
}
}

$bp_settings_updated = true;
}

add_action( 'bp_template_title', 'bp_core_screen_notification_settings_title' );
add_action( 'bp_template_content', 'bp_core_screen_notification_settings_content' );

bp_core_load_template( apply_filters( 'bp_core_template_plugin', 'members/single/plugins' ) );
}

function bp_core_screen_notification_settings_title() {
_e( 'Notification Settings', 'buddypress' );
}

function bp_core_screen_notification_settings_content() {
global $bp, $current_user, $bp_settings_updated; ?>

<form action="loggedin_user->domain . BP_SETTINGS_SLUG . '/notifications' ?>" method="post" id="settings-form">

<input type="submit" name="submit" value="" id="submit" class="auto" />

<?php
}


Can someone help me out with implementing this?
Thanks,
C.

[mistercyril]

Oh super!
Thank you very much!

[mistercyril]

Hello guys,

I’m interested in doing the same thing. Have you figured out a way of doing this without writing an SQL query?

I would be ok with hard coding the field I need to sort by.

My current query looks like this (default buddypress) but how can I have it look for a specific field value?
`$queryString = “type=alphabetical&action=alphabetical&per_page=150”;`

In WordPress I would use this `orderby=field_name` but thats not doing anything here…

Any help would be greatly appreciated,

Thanks,
C.

[mistercyril]

Up

[mistercyril]

Oh wow, this is GREAT News!
Thank you Boone for addressing this issue, it was really frustrating.

I tried implementing the patch, but there are 2 files I can’t find (bp-members/bp-members-functions.php) & (bp-members/bp-members-template.php). I don’t even have these directories in my version of BuddyPress.

I am using Buddypress 1.2.8

Am I missing something?

[mistercyril]

Has everyone suddenly deserted BuddyPress for another platform i’m not aware of? The documentation is very very very “light” here, and if no one pitches in anymore this plugin is going to die off…

I figured something out so here’s the code in case someone wants to achieve the same thing:

` // Check to see if you are currently displaying a member profile page.
// Replace xProfile_field with the profile field name.
// Display value of profile field

`

Thanks,
C.

[mistercyril]

anyone? really?

[mistercyril]

@sdpkelkar

Hello, did you ever find the solution for this?

Thanks,
C.

[mistercyril]

Ok, nevermind. That was a very silly question

@r-a-y its true that pagination is all messed up. What is the better way of doing this?

I would guess this has to be done higher in the loop. I’m using this to get members displayed alphabetically and it works ok. Could this be used to select users based on custom profile field values as well?

`<?php
if ( bp_ajax_querystring( ‘members’ ) ==””)
{
$queryString = “type=alphabetical&action=alphabetical&per_page=150”;
}
else {
$queryString = bp_ajax_querystring( ‘members’ );
}
?>

`

[mistercyril]

Up

[mistercyril]

Hello shanebp,
This worked out great!
Thank you very much for the info.
Best,
C.

[mistercyril]

Hello,
I have a silly question for you. Where does this code go?
Does it go in a new members-loop.php file or a custom template?
Thanks for the pointers,
C.

[mistercyril]

Hello Dave,
Did you end up finding a solution for this?
C.

[mistercyril]

Hello Boone,

So step 1 WORKS!
Hooray This was pretty simple, i’m sorry I couldn’t find it on my own.

As far as step 2 is concerned
You are right, previous users who had the mistery man icon don’t have an avatar anymore.
I took a look at the ‘bp_core_fetch_avatar’ section but i’m not quite sure how to write the filter you mentioned.
Could I abuse of your help and ask for an example? Would really be great.

Thank you,
C.

[mistercyril]

Hello Boone,

Thank you for your reply. I really appreciate getting an actual answer as I may be pretty comfortable working with WordPress but BuddyPress code has me a bit lost at the moment. I will Try this and post back.

About my quote, i’m sorry if it seemed “confrontational” but I guess its just my frustration talking. I’ve been asking about this and searching for months but could never find a rational solution.

Thanks again,
I’ll try it out now.

[mistercyril]

Hello Landman,
Thanks for your input, but unfortunately I think you may have misread my post. I’ve seen this plugin around for a while, but it doesn’t address my problem at all.

I am concerned with making 25 HTTP requests to a service I don’t need. I would like my users to upload their own mugshot or have the default “MysteryMan” hosted directly on my server. Simple as that.

Sending purposely misleading information (random email address) to Gravatar and waiting for it to respond so that you can load a local file is just not best practice in my book. That’s why i’m asking for a way to cut Gravatar out of the loop completely.

If you have some insight on that, please do share. I’ve been searching for a while now but i’m starting to think i’m the only one concerned with performance.

Thanks,
C.

[mistercyril]

@cheovent : I’m lobbying for the same thing.
If you find a solution or get a response that doesn’t involve (hacking core files) please post it. I’ll make sure to do the same.
Thx.

[mistercyril]

I don’t understand why there can’t be a simple option in the dashboard to disable Gravatars all together.

With the possibilities offered by BuddyPress, chances are there will be an increasing number of semi-corporate web sites or portals that will make it on line with a LOT of content. They are all going to want top scores in Page-Speed & Y-slow and getting an (F) on URL Redirects, because they might want to use the “recently active members” widget (for example), is not going to please anyone.

I understand wanting to promote an in house project, but even Microsoft had to give up forcing Internet Explorer on people… Couldn’t there be a simple “choice” which might default to Gravatar but still let users decide what they want to do with their website?

This is really inefficient and frustrating. Please consider this problem as a priority because it really is

[mistercyril]

I understand the point behind standard Gravatar integration in WP & BP but what if your target audience is by no means tech-savy and has very low probability of having a Gravatar account (I myself don’t even have one…)?

Doesn’t that make multiplying http requests to display the default mistery man completely pointless? And with the integrated “avatar upload” function in Buddy press, i’m guessing anyone even remotely willing to upload an avatar will do it on site…

So can’t there be a straightforward way to just get “mistery man” directly from inside the buddy press install? As I understand it, Marcus’ plugin just avoids displaying the Gravatar but still sends out requests to gravatar.com which is not great for page speed.

I’m pretty sure a few people are concerned with this Gravatar dependency and would rather have the choice of wether or not to use the Gravatar service to display avatars.

[mistercyril]

Is no one having trouble with BuddyPress and SEO???

[mistercyril]

I agree, my test users have been telling me that they have so many passwords to memorize that they like to be able to find them in the registration emails…

I know its not safe, but theres nothing to protect if users never log back in…

Best,
C.