[buddypress-trac] [BuddyPress] #4639: Add template hierarchy support

buddypress-trac noreply at wordpress.org
Tue May 21 18:29:58 UTC 2013

#4639: Add template hierarchy support
 Reporter:  DJPaul       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  1.8
Component:  Theme        |     Version:  1.7
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |

Comment (by hnla):

 Replying to [comment:47 r-a-y]:
 > `refresh.01.patch` is a slightly, different take on what I talked about
 [https://buddypress.trac.wordpress.org/ticket/4639#comment:35 here].

 This seems to test fine for me r-a-y, feels like it covers all

 I'm asuming that the need to be able to manage the template parts is
 simply covered by the two conditions 'component' & 'actions' in that
 having caught either of those two conditions (in respect of user screens)
 we can simply call our own copy of a template part as that process is now
 outside the core apps influence or concern so e.g having set index-action-
 public.php if  wanted to then do something with the header for that action
 I could simply do:

 bp_get_template_part( 'members/single/profile/public/member-header'  )

 It works and perhaps is acceptable, it's certainly fine to work with by
 the feel of it I would be able to manage that increase in template/folder
 complexity - whether it's the best approach open to debate.

 However I think we are still left with a problem of drilling down to the
 inner parts:
 as it in turn calls our three main item body parts 'edit', 'change
 avatar', 'profile-loop'

 So if I wanted to get to 'profile-loop' how would I? I guess could re-
 direct to pick a new copy of single/profile.php in single/profile/ then in
 turn edit the:

 bp_get_template_part( members/single/profile/profile-loop) to point to a
 new copy in a new folder in /profile/ but now it's starting to feel messy
 and confusing, although not unworkable.

 Part of this whole issue was to get to these template parts but perhaps I
 overlook some obvious means to this end or for that matter maybe I'm just
 missing a glaring point in all this :)

 As for the prefix 'index' not sure what else it could be named it doesn't
 feel ideal but perhaps  not really something to worry too much over and  -
 although never thought it great - does follow the WP convention for
 'home.php' & 'index.php'

 All in all if we ended up simply rolling with your last patch r-a-y I for
 one would feel it a vast improvement on present capabilities and other
 issues manageable by the developer in question at the time.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4639#comment:49>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list