I’d also love to know if anybody can confirm that posts to the activity feed can only be deleted by the WordPress Super Admin and the person who posted the item but not by the Group Admin.
That seems strange considering the “Delete” links appear next to the items when the Group Admin is viewing the feed. That link shouldn’t appear if the Group Admin shouldn’t have that ability.
Thank you for your response, mrpavlikov, but unfortunately it doesn’t appear to have done the trick for me.
After closer inspection of your code, is it possible that the check_is_admin() function should use the Group ID as the second variable instead of the Activity ID? And if so, how do I reference the Group ID?
In case it makes a difference, I’m using a different theme than the bp-default theme that is contained within the plugins/buddypress directory, so I made the change that you suggested to the ajax.php file within both my child theme directory as well as within the plugins/buddypress/bp-themes/bp-default directory. I also made the change to buddypress/bp-activity.php, but it doesn’t seem to have done the trick.
Thanks again for your assistance, and to anybody else who might have some insight on the issue.
Actually, I tried switching to the default BP theme to see if it was a theme-specific issue, but the issue didn’t go away, which leads me to believe it is a Buddypress issue.
I just attempted to use Steve’s delete fix to resolve a similar issue, but it didn’t seem to do the trick for me.
I’m using WP 3.1.1 and BP 1.2.8
My issue is that the super-admin for my multisite installation can delete posts from a Group’s activity feed, but a Group Admin cannot.
If a Group Admin attempts to delete an activity post, it appears to be removed from the activity feed, but if I leave the main Group page and return to it, the activity post returns.
Does anybody have any suggestions?
(I’m going to start a separate post, but this seemed like a logical place to make reference to the issue.)
Thank you for your response, Chouf1. Creating a button to link to the page from where they can send a private message is exactly what I was trying to do.
Do you have any idea whether there’s a way to implement this so that they don’t have to manually enter the user name once they arrive at that screen?
It seems like it might be doable with a second version of the bp_send_message_button() function that has been revised to accept the username as a parameter. I can tinker with the idea, but I thought I’d put it out there in case somebody knows whether or not there are any reason why this idea wouldn’t work.
I’ve run into this same issue, but none of the suggestions in this thread helped me to resolve it.
Has anybody else encountered this and confirmed that their file structure is correct and the meta_value for the record with meta_key = uri in table wp_bb_meta is the correct URL?
Any other ideas? Is this bb_get_id_from_slug() function actually defined somewhere?
This makes is seem as if it is possible to show different tabs to different groups within a single BuddyPress installation, but I want to confirm whether this can be applied to all different types of tabs or if it is functionality that is specific to the blog that can be tied to a specific BP group.
Is it possible this could be causing my newly added users to get a blank white screen when they click the link within the auto-generated email once I’ve created the new user?
In testing, I find that if I’m still logged in to the admin back-end when I click the login link within an auto-generated new user email, I get the dreaded blank white screen. However, if I log out of the back-end before clicking the exact same link within the email, then the login screen comes up just fine.
Has anybody else seen this behavior? If so, have you tried replacing all instances of is_site_admin with is_super_admin and did that change this behavior?
