Skip to:
Content
Pages
Categories
Search
Top
Bottom

Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)

  • cl0ne
    Participant

    @cl0ne

    @warrencat,

    I have been hoping for a solution to this since 2017. I had to find excuses to force users to hit the save button. The issues that I’m not even importing some large user database in which this limitation becomes more problematic. I’m talking about brand new installation with new users. There is no reason that a new user should have to do this before visibility settings can be applied. It makes absolutely no sense. It’s ironic since Admins’ settings are subservient to a user’s interaction.

    And I thought this was a sensitive enough issue that it would have been resolved by now. I’m surprised that more people have not made noise. Apparently it has existed since at least 2013 (https://buddypress.org/support/topic/buddypress-x-profile-visibility-doesnt-work/)!

    Then another user brought this up prompting the creation of a ticket in the trac system which can be found here:https://buddypress.trac.wordpress.org/ticket/8093

    This ticket does provide a patch that fixes the issue for the profile details. However, in my case, a user’s last name is supposed to be private but since the last name shows up in more places than in the profile details (i.e. title tag), you are still left with a half-baked solution. But the moment you save, it works flawlessly.

    The issue is set to be fixed in version 7. Let’s pray.


    cl0ne
    Participant

    @cl0ne

    Unfortunately, I was not.

    The membership plugin I was using eventually did an update that allow for syncing to occur automatically after registration.

    Hope you find a solution!


    cl0ne
    Participant

    @cl0ne

    Hi Everyone,

    This has not been resolved as of the current version I have which is 5.0. Looking at the changelog for all versions of Buddypress since version 5, I still see no reference to the 8093 ticket, indicating that it has not been addressed.

    Any update on this issue would be great.


    cl0ne
    Participant

    @cl0ne

    Bump!


    cl0ne
    Participant

    @cl0ne

    Hi shanebp!

    Thank you for prompt reply and the resource. I tried the code as it is to see if it will disable the “friends” component for Subscribers. Unfortunately, nothing happened. In fact, the first time I tried it, I got the white screen of death. This was I believe due to the fact that I have chanced “friends” to “matches” using the language files. I popped in “matches” instead and this time I was live, but no change as far as component being disabled is concerned.

    Instead of a component, what would I need to change in the code to remove the entire activity component from say, Subscribers. I’m actually going to be applying this so a custom role.

    
    function buddydev_conditionally_disable_components( $enabled, $component ) {
     
        if ( ! is_user_logged_in() )  {
            return $enabled; // we do not disable component for the logged in user
        }
     
        $user = wp_get_current_user();
     
        $roles = $user->roles ;
        // $role check for 'subscriber', 'contributor',  'author', 'editor', 'administrator'
     
        if ( 'friends' == $component && in_array( 'subscriber', $roles ) ) {
            //disable friends for subscribers
            $enabled = false;
        }
     
        return $enabled;
    }
    add_filter( 'bp_is_active', 'buddydev_conditionally_disable_components', 10, 2 );
    

    Thanks for all your help!

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