Skip to:

Forum Replies Created

Viewing 25 replies - 1 through 25 (of 90 total)
  • Correct. My answer only disables rich text for specific fields; the other answer disables rich text for all fields. Pick your poison. 🙂

    I suspect that BP is trying to use the new cover-header-specific member and group header template files. You can disable them until you have a chance to retheme for cover headers by visiting wp-admin > Settings > BuddyPress > Settings and unchecking the check boxes for group and user cover images:
    Allow registered members to upload cover images
    Allow customizable cover images for groups

    Hi Johnywhy-

    You can disable the rich text editor on a per-field basis using the filter bp_xprofile_is_richtext_enabled_for_field which was added when the wp_editor was added.

    You might do

    add_filter( 'bp_xprofile_is_richtext_enabled_for_field', 'my_disable_rt_function', 10, 2 );
    function my_disable_rt_function( $enabled, $field_id ) {
      // 14 is the id of the field I want to be plain text.
      if ( 14 == $field_id ) {
        $enabled = false;
      return $enabled;

    This plugin automatically activates new user accounts:

    I sure hope that you’re weeding out spammers on the way in, or this site isn’t open to the world.

    It sounds like you need to update your permalink structure:

    You could add a page-load listener and look for the action using bp_is_current_action(). To learn more about what action or action_variables are set as you browse your site, I recommend adding r-a-y’s BP Footer Debug plugin:

    Page loads are often caught on the action bp_actions.

    You’d have to do some more work to make sure that your filters can’t collide with group names.

    Your best best is to create a new language file, then you can customize nearly all of the strings:

    Hi Zoe-

    My memory is that users need to have usermeta with the key last_activity and a value like 2015-06-16 13:29:04 to reliably appear in the members directory. You can “repair” this value once the users are imported by visiting (from wp-admin) Tools > BuddyPress then select Repair user "last activity" data. In fact, it probably wouldn’t hurt to run all of those repair tools one at a time since you’ve got a bunch of untracked users.

    Hi @pilha-

    That’s totally weird behavior. It seems like the table in your database has lost its mind. 🙂

    Can you check the structure of the table wp_bp_groups? What I want to know is:

    • Is id set as the primary key?
    • Is id set to auto-increment?

    Since you’ve already emptied records from the database, I suspect you’re familiar with some software for MySQL management like phpMyAdmin. Can you check the questions above?

    Hi Pihla-

    I can’t reproduce the problem you’re having. Can you add a tracer to your theme’s functions file or to bp-custom.php then try to create a group?

    I added this to my theme’s functions.php and the file that it created (groups_group_after_save_args.txt) ended up at the root of my site. It looked like this:

    newly created group args: BP_Groups_Group Object
        [id] => 8
        [creator_id] => 4
        [name] => Number 5
        [slug] => number-5
        [description] => Will this be recorded?
        [status] => public
        [enable_forum] => 0
        [date_created] => 2015-06-15 14:59:00
        [admins] => 
        [mods] => 
        [total_member_count] => 
        [is_member] => 
        [is_invited] => 
        [is_pending] => 
        [last_activity] => 
        [user_has_access] => 
        [args] => Array
                [populate_extras] => 

    Please let me know if you can do this test and what the results are.

    Is Settings > General > “Membership” section “Anyone can register” checked?

    I can verify this behavior and will take a look.

    Thanks for the report.

    I think I’ve solved this by removing the do_shortcode filter on that admin page. (It’s the front-end settings screen created by the group extension.)

    function dont_process_shortcodes_filter() {
          if ( bp_is_current_component( 'groups' ) && bp_is_current_action( 'admin' ) && bp_is_action_variable( $extension_slug, 0 ) ) {   	) {
            	remove_filter( 'the_content', 'do_shortcode', 11);

    I was using the wrong priority on remove_filter, which always gets me. 🙂

    Thanks for your help!

    I still haven’t solved this. It looks like it’s not just me though. It’s also true that if you insert short codes in bbPress topic content then edit that content, the short codes are interpreted in the editor input box.

    Does anyone have any ideas how I could make some headway on this problem? Thanks!

    I solved this by adding the following filter. It removes “group-button” from the button wrapper (only on request membership buttons) so that buddypress.js will ignore the click.

    add_filter( 'bp_get_group_join_button','request_membership_redirect' );
    	 * Change group "Request membership" button behavior-- always redirect to request membership pane, no AJAX requests.
    	public function request_membership_redirect( $button ) {
    		// To prevent buddypress.js from acting on the request membership button click, we'll need to remove the class .group-button from the button wrapper. See buddypress.js line 1252.
    		if ( $button[ 'id' ] == 'request_membership' )
    			$button[ 'wrapper_class' ] = str_replace( 'group-button', '', $button[ 'wrapper_class' ] );
    		return $button;
    Profile photo of David Cavins
    David Cavins


    Does the logout redirect work if BuddyPress is deactivated (i.e. if you’re just running a typical WordPress site)?

    Profile photo of David Cavins
    David Cavins


    The label of the button is internationalized. See bp-friends-template.php : bp_get_add_friend_button()

    I’d double-check this guide:

    I personally had trouble with getting the naming convention on the .po and .mo files right.

    Profile photo of David Cavins
    David Cavins


    Sure. You’ll need a to make a loop in which you get the ids of the group members and then create a query to fetch those posts.

    For getting group member ids, look at:
    groups_get_group_members( $args = array( $group_id => # ) )

    For the query by author ids:

    Profile photo of David Cavins
    David Cavins


    Hi Leonson-

    This sounds like a .htaccess or server configuration problem. What kind of server are you running the site on? Can you post the rewrite rules from your htaccess file (assuming it’s a linux server)?



    Thanks so much for the push. I was going about this the wrong way, and had totally forgotten about the template hierarchy:

    Thanks for your quick reply,


    It sounds like you’re heading in the direction of a private community. Keep in mind that if it’s private, then search engines can’t index your content. Which may be good or bad, depending on your goals.

    You’ll find a lot of info by searching this support forum or the web for “buddyPress private community”

    For instance:

    You’ll need to logout to visit the register page. (If you’re already logged in, then you don’t need to register.)

    I usually fire up a second browser to see what the non-logged-in user sees. In this case, it’s the only way to visit the register page.

    I think it really depends on the plugin. Some plugins make the creation step routine filterable (like BuddyPress docs) and some do not, unfortunately. Of course, uou could add a filter to plugins that don’t have them, and submit the changes back to the plugin author.

    In the case where it is filterable, like BP docs, you can hook in like this:

    add_filter('bp_docs_default_group_settings', 'bp_docs_default_settings_for_child_groups', 10, 1);
    function bp_docs_default_settings_for_child_groups($settings) {
      // If this new group is a child group of another group, we'll set up BP docs to match the parent group's setup. This step copies the parent group's attributes over to the child group.
      // We may have to get the parent ID from the cookie 'bp_new_group_parent_id'
        $parent_id_cookie = $_COOKIE["bp_new_group_parent_id"] ;
        $parent_settings = groups_get_groupmeta( $parent_id_cookie, 'bp-docs');
        if ( !empty($parent_settings) ) {
          $settings = array(
              'group-enable'  => isset( $parent_settings['group-enable'] ) ? $parent_settings['group-enable'] : 0,
              'can-create'  => isset( $parent_settings['can-create'] ) ? $parent_settings['can-create'] : 'admin',
      return $settings;

    But as to a general case, I’ve not found the answer. Most plugins want to have their settings set on group creation, too, so you’ll need to handle that task as well.

    The easiest way I’ve found to hide the “last active 3 hours ago” info box is to comment out those bits in the templates in your theme. For instance, in members > members-loop.php, about line 57, you’ll see
    <div class="item-meta"><span class="activity"><?php bp_member_last_active(); ?></span></div>

    Comment that whole line out, and the last active message is hidden.

    Re the first question, Members shouldn’t appear in the list until they’ve activated their accounts, I believe. So you may have a bunch of unactivated members pending. The Pending Activations plugin should show you a list of those. I can find a few members that don’t appear in the members directory because they have created no activity at all, so maybe you’re seeing that problem as well.

Viewing 25 replies - 1 through 25 (of 90 total)
Skip to toolbar