BuddyPress.org

You can “hide” this from the obvious displays by

#buddypress span.activity { display: none; }

Just put it at the end of whatever CSS. My preference is just before any mobile specific sections that may be towards the bottom.

but really that just hides it and still leaks it everywhere. Until it’s really fixed it may be better to let members know it is so public.
I am also looking how to programmatically secure this as well and let users choose what is displayed.

CSS is applied so that in general, the most specific gets priority and the last line gets the last word too, so if you have control of the flow put the things you want to override at the end or the last stylesheet applied.

https://buddypress.trac.wordpress.org/ticket/5671

@albert101

Try putting the function in bp-custom.php

A simple way to correct this problem is to cd to wp-content/plugins/buddypress
Backup the budypress directory
And Run :
wp-content/plugins/buddypress# find . -iname “*.php” | xargs -i sed -i ‘s/&\$/\$/g’ {}

I just want to get the list of buddypress shortcodes.

Doesn’t exist. You can create a shortcode or use this plugin:

https://wordpress.org/plugins/bowe-codes/

add following line in your wp-config.php file:

define('SCRIPT_DEBUG', true);
and activate the already existing define('WP_DEBUG', false); to define('WP_DEBUG', true);
and feedback here.

BuddyPress 2.1 milestone estimation

BuddyPress 2.0.2 is compatible with WordPress 4.0 See this site: it’s working ! 😉

500 Internal Server Error is a generic error message, given when no more specific message is suitable. There are a number of causes for a 500 Internal Server Error to display in a web browser. (cite)

Which theme do you use ?
https://wordpress.org/support/topic/500-server-error-after-upgrade-to-wordpress-40

And also WordPress uses a rich-text editor. BuddyPress does not for the activity post form.

also – try deactivating the BuddyPress Real Names plugin and see if that solves the pagination issue.

@ryanjhale – I’ve posted a fix here:
https://buddypress.trac.wordpress.org/ticket/5869

This probably won’t make v2.1 since we’re close to releasing this version. I’ve tentatively put the fix for v2.2.

Thanks for reporting!

Being philosophical ? Yes at least, for sure ! 😉
Whatever is well conceived is clearly said… and the words to say it flow with ease. Nicolas Boileau

But it’s not really the case on this topic 😉 I’m french and you a buddypress n00b (your expression).

First, I suggested you to create a page.
You answered that you built a CPT and changed the slug by following a tutorial. This is working for page and not for CPT ?!!!

Forget my snippets for the moment, and try to explain what you did exactly (a code example would be great).

And also, once the cpt will work, what do you expect after that ?

See in bp-groups/bp-loader.php how the menu is built
Ad if not already done, read here: https://codex.buddypress.org/plugindev/extend-groups-admin-ui/

@ryanjhale – Sounds like a bug.

Can you post a ticket on our ticketing system?
https://trac.buddypress.org/newticket

Use the same login credentials as you do here.

Thanks!

Deactivate all plugins but buddypress and activate 2014 and retest your install.
See if the notices disappear and if the site loads correctly.
If not, deactivate buddypress and retest.

If ok, activate custom community and retest only with wp.
If the errors are back, you have the culprit.
If it is ok, activate BP. Retest.

If ok, you reactivate one by one your plugins. Except BP Toolbar, outdated and still in beta since april 2013. This plugin was intended for BP 1.5 to 1.7. And BuddyPress is use now the wp Toolbar.

If nothing of this is working correctly, you have to ask on the theme support.

@ryanjhale,

wp roles and bp capacities are two diffrent things.
bp_moderate has a specific usage applied to the site admin only. If you read what is written in bp-core-caps.php, you’ll see this comment at line 200

 * Temporary implementation of 'bp_moderate' cap.
 *
 * In BuddyPress 1.6, the 'bp_moderate' cap was introduced. In order to
 * enforce that bp_current_user_can( 'bp_moderate' ) always returns true for
 * Administrators, we must manually add the 'bp_moderate' cap to the list of
 * user caps for Admins.
 *
 * Note that this level of enforcement is only necessary in the case of
 * non-Multisite. This is because WordPress automatically assigns every
 * capability - and thus 'bp_moderate' - to Super Admins on a Multisite
 * installation. See {@link WP_User::has_cap()}.
 *
 * This implementation of 'bp_moderate' is temporary, until BuddyPress properly
 * matches caps to roles and stores them in the database. Plugin authors: Do
 * not use this function.

BuddyPress groups moderators are not authorized to enter the admin dashboard or the group admin on frontend. Group moderators can only delete, move and spam group activities or topics. If the group has a forum, they wil have the same capacities.

If you want a user to be able to access the admin dashboard, you can give him an editor role (which is a wp role).

If you want to allow him access to the group admin on the front-end, you promote him to group admin. This setting doesn’t allow that user to enter the site admin. He’s only a group admin (with a wp role of subscriber, by default) and not a site admin (admin or super-admin (MS) ).

@tomlandon_author,

who’s online refreshes after 5 mn.
Read more here:
https://buddypress.trac.wordpress.org/ticket/3590

and feel free to open an enhancement ticket on the Trac.
You can login with the same credentials as on this forum.