[buddypress-trac] [BuddyPress Trac] #6388: Groups single item home : improve the way we deal with custom front and activity component

[buddypress-trac]

#6388: Groups single item home : improve the way we deal with custom front and
activity component
-----------------------------------------+------------------
 Reporter:  imath                        |       Owner:
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  2.4
Component:  Component - Groups           |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch needs-docs commit  |
-----------------------------------------+------------------

Comment (by imath):

 Thanks a lot to both of you for your great feedbacks, i think i'm now sure
 about what's best to do :)

 As seen on slack, there was some misunderstanding about what the patch is
 doing. So let's compare what's happening today to what will happen once
 the 6388.06.patch will be committed (i've edited mentions & heartbeat
 functions so that they use `bp_is_group_activity()`).

 Today:
 a. `bp_is_group_activity()` has no utility because it's always false. The
 reason for that is due to the fact that the only place where the group's
 activity template is loaded is the group's home.
 b. when there's a `front.php` template in `/buddypress/groups/single/` the
 activity template is simply no more showing.  If the activity component is
 deactivated, there are 2 members templates loaded (home + members).

 Once the patch will be committed:
 1. `bp_is_group_activity()` will return true each time the activity
 template will be displayed (in group's home or in the activity page if
 there's a custom front). So this function now does what it should, and
 plugins wishing to do things in group's activity should use this check
 systematically.
 2. `bp_is_group_members()` will return true each time the members template
 will be displayed (in group's home or in the members page),
 3. `bp_is_group_custom_front()` will return true if the current displayed
 group is using a custom front.
 4. `bp_is_group_home()` will return true if we're on group's home, but
 this will not necessarily mean it's the activity template that is loaded.
 It can be a custom front. And if the activity component is not active it
 can be the members template.
 5. backcompat with themes who might not have updated their templates once
 2.4.0 is released will be ok.

 Finally, my last hesitation was about plugins using `bp_is_group_home()`
 to check if the activity template is displayed. As we've seen in a. It's
 already a mistake to do that. But we didn't have the right conditional tag
 so far to help them be sure the group's activity page was displayed. Once
 this ticket will be fixed, they'll have it, it's `bp_is_group_activity()`.

 I thought about deprecating bp_is_group_home(), but if we do that every
 standalone BuddyPress theme or end user having a config where the group's
 home template is overridden will be annoyed. So as a plugin developer, i
 know my "colleagues" will do their best to adapt and edit their plugins if
 needed, like i'll have to do myself!

 The good news are :
 - Groups will potentially have great custom front pages, these front pages
 will be able to be different (according to the displayed group id/slug or
 status) thanks to the template hierarchy introduced.
 - We will be able to have an activity page if the group has a custom front
 !!

 I'll commit asap and post on bpdevel about it :)

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6388#comment:23>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac