BuddyPress.org

@mike80222, when composing a message, the “@” applies to the BuddyPress Nouveau template pack, i.e, the label reads “Send @Username” as opposed to the BuddyPress Legacy template pack that reads “Send To (Username or Friend’s Name)” and I’m not sure why it is not the same for both but, that is current behavior. As to the inconsistency for when suggestions appear or not appear is a puzzle, at the moment.

@stephunique, it is possible to filter the suggested usernames by utilizing the bp_core_get_suggestions filter. If you only want to apply this filtering to messages (compose) then your callback needs to be location aware (what/which page/screen is active/loaded), as well.

The create_function() was deprecated as of PHP 7.2.0 and was removed in 8.0.0 (see create_function). Since you are using PHP 8.x then, it would be best to not use this plugin until it has had all compatibility issues resolved. On another note, there seems to be some interest by individuals other than the original developers to provide some sort of future support for this plugin (see Would like to take over this plugin, or help – Support forum for BuddyPress Follow).

The information you provided suggests a caching issue with your CDN setup for the member page activities. Here are some technical suggestions to investigate and potentially fix the problem:

1. Caching Configuration on CDN:

Check your CDN provider’s (CloudFront in this case) caching settings. You likely need to configure it to not cache dynamic content like member activities. Look for options related to “Cache Control” or “Object Caching”. You might need to set a short cache expiry time or disable caching for specific paths (e.g., /members/*).
2. Caching Headers:

Ensure your server sends appropriate caching headers with the member activity data. The server should send headers like Cache-Control: no-cache, no-store, must-revalidate to prevent browsers and the CDN from caching this data.
3. Browser Caching:

Although less likely, there’s a chance the browser is caching the initial response. Try clearing the browser cache and cookies after the first load to see if the issue persists.
4. Anti-Proxy Buddypress Plugin:

While Youzify mentioned the anti-proxy Buddypress plugin, it’s difficult to say definitively if it’s causing the issue without more information. It’s possible the plugin is interfering with the caching mechanism. You can try temporarily disabling the plugin to see if the problem resolves. Be cautious as disabling plugins can have unintended consequences.
5. Debugging Tools:

Use browser developer tools (Network tab) to inspect the network requests when loading activities. Look for any caching headers being sent and received. Additionally, check the status code of the requests – a 304 (Not Modified) might indicate the CDN is serving cached data.

There is currently a ticket in progress: https://buddypress.trac.wordpress.org/ticket/8413

@pellepedersen

Looks like your issues probably stem from BP changing the way new accounts are registered, which I think was introduced in BP 14 (but not sure, look into that).

So best to go back to an earlier version.

I use BP 10.6.4 with BP Registration Options to provide admin with moderation options for newly registered accounts (ie. they need to be “approved”)

So if that’s what you were doing earlier, then I’d recommend that setup.

– You can manually delete and install an older version of BP, but I would recommend you use the WP Rollback plugin, much safer.
– so, install WP Rollback plugin
– do not delete anything
– rollback Buddypress to v. 10.6.4
– all should be ok

IMPORTANT : you should definitely do a full site backup before you do any rollback. Just in case. I’ve done it multiple times, no issues.

I created an issue here: https://github.com/buddypress/bp-activity-block-editor/issues/8

I think Core should fix it first and then BuddyPress would inherit the update. Unlikely we will invest time into it since we plan to move things into the block editor.

It sounds like your CDN might be caching the Ajax responses, leading to incorrect member activities on subsequent loads. You can try adjusting the cache settings for Ajax requests in CloudFront or configuring Buddypress to prevent caching of dynamic content. This tweak could help you “instaup” your site’s performance and ensure the correct data is always displayed.

@TheSupercargo I’m not sure if this is related to your problem and if you can test this pr.

We already have a ticket for this: https://buddypress.trac.wordpress.org/ticket/9044