Create Group link is not showing up in Twenty Fifteen

[mercime]

WP 4.1, BP 2.2 trunk.

The new Create Group link does not show up in the front end nor in the source code of the Group Directory page when Twenty Fifteen theme is activated. Not a problem with other WP Default themes. Haven't had the time to check if this affects the Create Blog link as well.

[hnla]

brief checking: Seems bp_get_group_create_button() isn't returning a value, at a guess the bp_get_button() isn't passing the $button_args.

In bp-core-classes the button class BP_Button has a variable public $block_self = true; this appears to be the problem as setting to false renders button, not sure why though this is issue for twentyfifteen at the moment.

So adding in the optional arg to the $button_args 'block_self' => false, in the groups template brings the button back but this arg option is intended for users own profile according to phpdocs, but why an issue on a theme??!!

Seems that the series of conditional checks run if 'block_self' == true are an issue; we compare bp_loggedin_user_id() to bp_get_member_user_id() to return false however the member user is is returning a value on groups dir page so we are halting the button unless we specify false on the button args for block_self

In 2014 page.php showing groups directory returns null on bp_get_member_user_id() however 2015 returns a user_id this is why we have the group create button issue but why...

[mercime]

Thank you hnla for confirming the issue and for looking into this matter.

Reviewed the Twenty Fifteen theme and found the following in the theme's ​header.php file just before wp_head()

<script>(function(){document.documentElement.className='js'})();</script>

[hnla]

Issue is tracked down to the BP members widget. When activated and showing in the sidebar on the groups dir page it has the effect of populating the member id function, this only happens though on twentyfifteen, twentyfourteen doesn't have this issue. the members id is returned empty and therefore block_self is bailed out of before it runs its checks.

[hnla]

Issue has been suggested as likely related to this existing known problem #5170

[imath]

Hi, just checked. I confirm, the problem seems to only appear when the "(BuddyPress) Members" widget is active. I think we're seeing this in the twentyfifteen theme because this theme is getting the sidebar before the content (actually the get_sidebar() is called within the header.php file of the theme).

So i guess it concerns every theme that is loading the sidebar before the content. I will check #5170 and the "(BuddyPress) Members" widget to see if i can quickly find a fix.

[imath]

Ok one quick and easy way to fix this is to reset the $members_template global after the widget.

But i think we should have a more global ticket to follow this issue, because i think some similar troubles can be found on other {component}_template globals if widgets are loaded before the main content.

[hnla]

Further reasoning:

This 'block_self' arg is designed to prevent showing a button for e.g friends on your own members loop entry and as such is set to 'true' by default which then runs a check for bp_get_member_user_id() == true' and == bp_loggedin_user_id()` if conditions are met we return false on the button creation.

With group create & blog create buttons this condition of a button appearing in ones own loop entry is not a factor the create buttons should appear for all only based on capability to create and active components.

We have rested safe in the knowledge that the initial check after block_self true/false bp_get_member_user_id() would faithfully return false on group/blog dir however that isn't really a valid check as the button doesn't render on members loops regardless, in this respect I suggest we ought to be passing the optional arg 'block_self' => false, to the button class for these create buttons regardless of whether bp_get_member_user_id() is correctly or incorrectly returning a value?

[boonebgorges]

hnla - You have a good point. 'block_self' is kinda meaningless with respect to the group create button. If passing 'block_self=false' to that button generator would fix the problem at hand, we should just do it, and worry about a proper fix for #5170 when we're not hours away from a beta release :-)

[boonebgorges]

In 9327:

Explicitly declare block_self=false for group and blog create buttons.

The block_self parameter, which defaults to true, is designed to prevent things
like 'Add Friend' buttons appearing when viewing oneself in a member loop. In
the case of group and blog create buttons, the parameter is not really
meaningful. But in certain cases of global variable population (such as when
a members loop is run on the page before the group/blog buttons are generated),
block_self=true can cause these buttons to be improperly suppressed.

See #5170 for background on the problem.

Fixes #6096.
Props hnla.

[hnla]

we should just do it, and worry about a proper fix for #5170 when we're not hours away from a beta release :-)

Think this makes sense at this stage, we know we have a larger issue to address but in respect of this group/blog create button issue it shouldn't be relying on a single check for an empty or false instance of bp_get_member_user_id() but rather acknowledging earlier on that the 'block_self' checks are not required by passing 'false' to override block_self default value.

I will just run a few checks on the previous WP themes just to ensure things look ok but can't see that they wouldn't.