If the issues persist, you need to do some basic debugging.
Start by using a WP theme like 2017 and use the BP > Options > Template Pack > BuddyPress Legacy templates. If that clears up the issues, then you need to get a solution from BuddyBoss.
If the issues persist, deactivate any other plugins.
If the issues persist, there is a serious and unknown problem.
Otherwise, activate the other plugins one at a time until you see an issue.
I wasn’t sure if the override system worked on this kind of thing, could I move that file (and any others that need modification) under my child theme like
I fixed this by creating a new file named buddypress.php to place in my theme (child theme) on the same level as the page.php, single.php, style.css etc.
Buddypress then uses that buddypress.php page for all of it’s content.
The buddypress.php file is simply a copy of page.php with the call for sidebar commented out. <?php /* get_sidebar(); */ ?>
I then needed to adjust main content div to be 100%, or in my case simple remove the ID tag that called the css to limit the width of the “left content” to 73%.
On the front end, go to a group and select ‘Manage’.
You should end up on an url like: .../groups/your-group/admin/edit-details/
And be able to edit the description.
On the back-end, wp-admin > Groups > roll over a group name and select ‘Edit’.
What happens when you enqueue it? Does it work then? The next step is to figure out why the buddypress-nouveau JS is not being enqueued on the Site-wide Activity page.
The bug needs to be reproduceable on a fresh install of WordPress and BuddyPress.
If you are able to replicate this bug there, then please list the steps it takes to duplicate the problem.
It’s possible that you are using a plugin or custom code to change certain things. If that is the case, you need to disable all BuddyPress-related plugins and code snippets and then trying to reactivate each one to pinpoint what is causing the problem.
Hi folks, new BuddyPress user here. (Using BP 3.1.0, WP 4.9.8, site in development)
I’m looking to use BP for the following specific functionality:
1) Allow our members to post updates on their own profile (privately) for their own reference (diary style), which they will be able to review themselves later, over time.
2) It would be great if the admin user(s) could post comments on their diary entries too.
First hurdle: I would like to know how to “hide” certain elements of BuddyPress. When I go to the Activity page for a test user, besides the activity entry box and feed, I see links to toggle between “All Users” and “Mentions”. Then there’s an RSS link, a “Search Activity” box (might keep that, sure), and a dropdown for ‘Everything’ and some other options.
My first question: How do I go about hiding / disabling the functionality I don’t want our members to see/use? Should I edit plugins/buddypress/bp-activity/bp-activity-template.php ? Is this a good idea? :-O
Second question: Changing references of “Activity” to, say, “Diary” — is this best done with a translate plugin (e.g. LocoTranslate)?
3rd question: How would I enable admins the ability to add comments within a member’s activity stream (e.g. respond to specific entries)? Does anyone have any ideas on that? Is there another plugin somewhere that enables such functionality, perhaps?
I’m getting the same issue, but for me, it seems like there is a conflict with bbpress. when I disable it, it is working just fine. so far no solution for it š
my console gives me this error message:
underscore.min.js?ver=1.8.3:5 Uncaught SyntaxError: Unexpected token ;
at new Function (<anonymous>)
at Function.m.template (underscore.min.js?ver=1.8.3:5)
at n.template (wp-util.min.js?ver=4.9.7:1)
at n.render (wp-backbone.min.js?ver=4.9.7:1)
at n.render (buddypress-group-invites.min.js?ver=3.1.0:1)
at wp.Backbone.Subviews.<anonymous> (wp-backbone.min.js?ver=4.9.7:1)
at underscore.min.js?ver=1.8.3:5
at Function.m.each.m.forEach (underscore.min.js?ver=1.8.3:5)
at wp.Backbone.Subviews._attach (wp-backbone.min.js?ver=4.9.7:1)
at wp.Backbone.Subviews.set (wp-backbone.min.js?ver=4.9.7:1)
Thank you! That helps me understand that it’s not the standard BuddyPress behavior. I don’t have BP Activity Plus, but I do have RTMedia and after disabling it, the issue is gone. Now I just have to help the RTMedia dev team understand that the issue is on their side.
Check areas where your developer has either written a plugin or modified your BuddyPress templates in your theme (should be under /wp-content/YOUR-THEME/buddypress/ maybe.
Thanks,but i have new problems Can you help. I contact the Rehub Theme developer, he says there is some prlugins in back wich are have influnce but i checked and deactivate all plugins it still buggy, now i have this error in wp dashboard:
Warning: sprintf(): Too few arguments in /var/www/web24642847/html/smartgadgetdeals/smartgadgetdeals/wp-content/plugins/buddypress/bp-core/admin/bp-core-admin-functions.php on line 327
Warning: Cannot modify header information – headers already sent by (output started at /var/www/web24642847/html/smartgadgetdeals/smartgadgetdeals/wp-content/plugins/buddypress/bp-core/admin/bp-core-admin-functions.php:327) in /var/www/web24642847/html/smartgadgetdeals/smartgadgetdeals/wp-admin/includes/misc.php on line 1124
Apologies. I should have been more precise in documenting my steps. The actual steps are:
1) On the usersā profile, click the āPublic Messageā button.
2) I am taken to the activity feed and a message box is displayed and their handle is pre-populated.
3) The entry form is focused and I can type.
4) I type “Hello, person”.
5) When I am done typing. I hover over the āPost Updateā button, but it displays a pointer, not the hand icon because the button is not activated to send.
6) If I click anywhere on the page to remove focus from the message field, the “Post Update” button remains inactive.
7) When I click back in the message field, the button is now activated and I can send.
I checked with my theme developer and they indicated that this is standard BuddyPress activity and has not been modified by their theme.
Is this how BuddyPress is expected to behave for public messages?
BuddyPress doesn’t handle user deletion. We use the WordPress user API to remove the account.
WordPress is in charge of removing data and they currently do not remove data from the wp_signups table when a user is deleted. Here’s a somewhat, related ticket: https://core.trac.wordpress.org/ticket/43232