[@r-a-y Keymaster 8 years, 2 months ago]

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)

[@r-a-y Keymaster 8 years, 2 months ago]

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.

[@r-a-y Keymaster 8 years, 2 months ago]

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.

[@r-a-y Keymaster 8 years, 2 months ago]

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-nouveau JS 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#L364

Are you, by chance, filtering 'bp_nouveau_register_scripts' anywhere?

[@r-a-y Keymaster 8 years, 2 months ago]

Sounds like the same problem as this report:

Can’t Post in Activity Stream

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.

[@r-a-y Keymaster 8 years, 2 months ago]

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.

[@r-a-y Keymaster 8 years, 2 months ago]

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_provider

Hope that helps somewhat. The rest is up to you.

[@r-a-y Keymaster 8 years, 2 months ago]

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.

[@r-a-y Keymaster 8 years, 2 months ago]

Sounds like you should use a forum like bbPress (bbpress.org) instead of a profile-centric option like BuddyPress.

[@r-a-y Keymaster 8 years, 2 months ago]

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_DEBUG in wp-config.php?

[@r-a-y Keymaster 8 years, 2 months ago]

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.

[@r-a-y Keymaster 8 years, 3 months ago]

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.

[@r-a-y Keymaster 8 years, 3 months ago]

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.

[@r-a-y Keymaster 8 years, 3 months ago]

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

[@r-a-y Keymaster 8 years, 3 months ago]

BuddyPress 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 user slug entirely for user profiles, while keeping the Members Directory at users.

You can remove the user portion 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' );

[@r-a-y Keymaster 8 years, 3 months ago]

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.

[@r-a-y Keymaster 8 years, 3 months ago]

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.

[@r-a-y Keymaster 8 years, 3 months ago]

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.

[@r-a-y Keymaster 8 years, 3 months ago]

The BuddyPress ones are false positives.

[@r-a-y Keymaster 8 years, 3 months ago]

Please read the 3rd point in the sticky thread:

BuddyPress 3.1.0 is now available!

If you have replies to make, make them at the linked thread mentioned in the sticky.

Closing to avoid forking the discussion.

[@r-a-y Keymaster 8 years, 3 months ago]

I’ve added an answer to the thread you linked to.

I’m closing this to avoid forking the discussion.

[@r-a-y Keymaster 8 years, 3 months ago]

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

[@r-a-y Keymaster 8 years, 3 months ago]

If you have access to your server, you can rename the wp-content/plugins/buddypress folder to something else like wp-content/plugins/buddypress-bak, then reload the Plugins page or a frontend page and BuddyPress should deactivate.

[@r-a-y Keymaster 8 years, 3 months ago]

I’ve created a ticket here – https://buddypress.trac.wordpress.org/ticket/7934

Hopefully, some other contributors can duplicate the problem.

[@r-a-y Keymaster 8 years, 3 months ago]

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.