Forum Replies Created
-
Do you both have the Activity component disabled?
If so, this is a bug. We’ve tentatively fixed this for the next release.
However, you can temporarily apply the changes by by adjusting these files:
https://buddypress.trac.wordpress.org/changeset/12185(Red means code removal, green means code addition)
What happens when you enqueue it? Does it work then? The next step is to figure out why the
buddypress-nouveauJS 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.
I just saw another thread about this.
It looks like the bp-nouveau JS files are not being outputted in the footer.
You can check to see if the
buddypress-nouveauJS file is being properly registered and enqueued:
https://buddypress.trac.wordpress.org/browser/tags/3.1.0/src/bp-templates/bp-nouveau/buddypress-functions.php#L296
https://buddypress.trac.wordpress.org/browser/tags/3.1.0/src/bp-templates/bp-nouveau/buddypress-functions.php#L364Are you, by chance, filtering
'bp_nouveau_register_scripts'anywhere?Sounds like the same problem as this report:
Unfortunately, we have been unable to determine the cause. Maybe you can help?
If you are able to reproduce this problem on a fresh install of WordPress and BuddyPress, then please let us know so we can look into the problem.
It looks like you are using a plugin like BP Activity Plus due the fact that our activity post forms look different.
Try disabling that.
Maybe just “don’t use oembed except for Youtube” type of hacking?
BuddyPress just uses whatever oEmbed providers that WordPress uses.
You can disable oEmbed providers in WordPress with code:
https://codex.wordpress.org/Function_Reference/wp_oembed_remove_providerHope that helps somewhat. The rest is up to you.
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.Sounds like you should use a forum like bbPress (bbpress.org) instead of a profile-centric option like BuddyPress.
What does it say in the browser console’s Javascript tab?
What does it say in the browser console’s Network tab for the AJAX request?Are any PHP errors logged if you enable
WP_DEBUGinwp-config.php?I’m not sure. Perhaps there is something being lost in translation in your description.
Can you take screenshots or a GIF to demonstrate your problem? Perhaps it’s browser-related? Could also potentially be a plugin conflict.
Here’s a quick GIF I took:

Pressing on “Public Message” takes me to the Site-wide Activity page with the user’s mention name. I click inside the textarea and write something. Hover over the “Post Update” button and it’s the hand cursor. I click on “Post Update” and wait for it to post. It successfully posts (you can’t see the post because I didn’t increase the height of the GIF.
This is in Chrome.
For me, it displays the hand icon and I’m able to submit the form after pressing on it. I’m testing with a WordPress default theme.
Try switching your theme temporarily to see if you can duplicate your problem.
Sounds like you’re using a plugin because when you hit the “Public Message” button, it should take you to the Site-wide Activity page with the @-username pre-populated. The submit button is also named “Post Update” and not “Send”.
Could also be something that your theme implemented. If so, try changing your theme to a WordPress default theme to see if the behavior is how I described.
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_signupstable when a user is deleted. Here’s a somewhat, related ticket:
https://core.trac.wordpress.org/ticket/43232BuddyPress cannot handle a different members slug for single profile pages.
It might be possible via custom code, but is probably hard to implement. The easiest thing to do is remove the
userslug entirely for user profiles, while keeping the Members Directory atusers.You can remove the
userportion of the member profile URL with the following code snippet in your theme’s functions.php or via a custom plugin:add_filter( 'bp_core_enable_root_profiles', '__return_true' );BuddyPress does not do anything to the login page.
You are using a 3rd-party plugin to manipulate the login page. Please use the support forum for that plugin for help.
Thanks for the thorough report, @jakdaniel5.
I’ve filed a ticket here – https://buddypress.trac.wordpress.org/ticket/7938
We’ll try to verify the issue internally. Once we can duplicate the problem, we’ll look to fix this up.
The BP ones are not dangerous.
Your authenticity plugin just looks for anything using
base64_encode(), which can be used for legitimate purposes. You’d have to audit the other plugins to determine if they are doing anything of mal intent.The BuddyPress ones are false positives.
Please read the 3rd point in the sticky thread:
If you have replies to make, make them at the linked thread mentioned in the sticky.
Closing to avoid forking the discussion.
I’ve added an answer to the thread you linked to.
I’m closing this to avoid forking the discussion.
Got the answer for you.
In v3.0.0, we conditionally load code depending on the page you are on.
Since you are manipulating the default nav item, the screen code needs to be available before the call to
bp_core_new_nav_default()is made.You can use the following code snippet in conjunction with the code snippet you are currently using until v3.2.0 is released to address this issue:
add_action( 'bp_late_include', function() { // Include Email screen code on Settings component and for default nav action (which is empty). if ( is_user_logged_in() && bp_is_settings_component() && ! bp_current_action() ) { require_once buddypress()->settings->path . 'bp-settings/screens/notifications.php'; } }, 11 );I’ve created a ticket here – https://buddypress.trac.wordpress.org/ticket/7935
If you have access to your server, you can rename the
wp-content/plugins/buddypressfolder to something else likewp-content/plugins/buddypress-bak, then reload the Plugins page or a frontend page and BuddyPress should deactivate.I’ve created a ticket here – https://buddypress.trac.wordpress.org/ticket/7934
Hopefully, some other contributors can duplicate the problem.
Sorry, I cannot duplicate this on a fresh install of WordPress 4.9.7 and BuddyPress 3.1.0, using Twenty Seventeen and launching the Customizer.
Any steps to duplicate from a fresh install? What page are you attempting to launch the customizer from?
If you want to help debug the uncompressed javascript, add the following to wp-config.php:
define( 'SCRIPT_DEBUG', true );And note down the JS console message.