After reading that manage_options much gives that role access to the entire Settings feature of WordPress I realized that isn’t good. Needless to say, I have used Adminimize to hide the “Settings” tab from the Manager user role for the time being but certain savvy people could still access it if they knew the URL to those settings pages.
Finally figured it out!!! First I tried using a modified version of the “Editor” role as you suggested with ALL capabilities added which allowed me to edit member profiles no problem. THEN I unchecked each and every capability one by one until I found the one that triggered the problem.
As it turns out the “manage_options” capability was the missing link. I checked off manage_options under my custom “Manager” role and waddya know, we’re back in action.
I wonder what changed in BP 1.7.1 that requires the manage_options capability?
Regardless, it works like a champ. Thanks a million for helping me troubleshoot this @shanebpdev – Hope your day is awesome!
Thanks for the info @shanebpdev that is very useful. After using the “Members” role editor I was indeed able to verify that the Manager role already had the “edit_users” capability. Sadly any user with the Manager role still gets taken to the “You do not have sufficient privileges” page. Perhaps it is a bug.
I checked out the bp-members-functions.php file and found the line you spoke of and it is matching:
if ( bp_current_user_can( 'bp_moderate' ) || current_user_can( 'edit_users' ) )
Now “bp_moderate” does not show up as an actual WP role. The regular “moderate” role does however, and the Manager user has access to that capability.
Just for the heck of it I changed the line to current_user_can(‘Manager’) which without any arguments does check for the name of the role. After doing so I noticed that when a manager goes to edit a member’s profile, they are automatically redirected to the member’s activity feed instead of the edit profile page.
Something funky is going on for sure. I really appreciate you helping me out with this.
I have checked the user “capabilities” of the custom role I have created and it has all the capabilities it needs to modify WP users. They can reset passwords and modify WP related profile information but NOT BuddyPress extended profiles. Apparently though BP doesn’t use WP roles for anything besides checking for super admin privileges. Can anybody think of a way to modify BP to allow non-super admins to edit extended profile information of other users besides themselves?
I’d love to learn how to do this as well. I’m currently using bp_ajax_querystring( ‘members’ ) ==””) { $queryString = “type=alphabetical&action=alphabetical&page=1”; } to sort alphabetically.
But I would love to be able to use the “Last Name” xprofile field that I created instead. There’s gotta be a way to append it to that queryString somehow.
Hey there @Ionut – Unfortunately the From Name from any of my gravity forms still uses the WP Site Name. The moment I disable BuddyPress, the moment Gravity Forms starts working just fine.
Their mailer notification function is definitely overriding the “from” variable at some point in time.
Hi Toby, thanks for the reply. I actually do have a thread started with Gravity Forms. They suggested to disable all my plugins, so I did, and noticed that the problem occurred when BP was enabled. The From Name is controlled through Gravity Forms, but BuddyPress is overriding the GF settings and adding the site title as the From Name. It’s basically treating my contact form notifications as if they were BuddyPress notifications.
The moment I disable BuddyPress, I can successfully fill out forms on my website that come from the true “From” that I have specified in my Gravity Form settings.
