Good point. Looks like a good trac ticket to post 
In the example you posted above, however, this can already be accomplished if you have a page.php which includes a sidebar by default. When you edit the Group Directory page and choose the Full Width template, the directory page is rendered in full page. The single group pages take on the HTML structure of the theme’s default page.php which has a sidebar.
If however, you want all the BP templates to have full-width layouts for example, and have a default page.php with a sidebar, then that will be problematic …. unless you copy over the BP templates in your theme and add “, “ and “ which could include conditional statements and a different HTML structure surrounding the BP components. Of course this is theoretical since I haven’t tested it yet
EDIT – I see you’ve posted it in trac already https://buddypress.trac.wordpress.org/ticket/3741#comment:55
In BP 1.7, BuddyPress looks for the following files in your theme’s folder to determine which page BP uses for the skeleton:
`’plugin-buddypress.php’
‘buddypress.php’
‘community.php’
‘generic.php’
‘page.php’
‘single.php’
‘index.php’`
If you need to do a conditional based on a specific BP page component, there’s a filter in `bp_get_query_template()` to override it. Note: I haven’t tested this yet.
You could also use BP page conditionals with template parts within one of the templates listed above. That’s probably the easiest way without having to use filters.
References:
bp_get_theme_compat_templates():
`https://buddypress.trac.wordpress.org/browser/trunk/bp-core/bp-core-template-loader.php#L292`
bp_get_query_template():
`https://buddypress.trac.wordpress.org/browser/trunk/bp-core/bp-core-template-loader.php#L140`
@r-a-y thank you. No more bp-template-pack questions anymore come BP 1.7, only plugin-buddypress.php ones
BP 1.7 is going to be exciting, all these new shiny features in templates and forums and all that jazz! …. Errr, what am I saying? We need to create all those new codex pages covering the new features as well, gazooks, lol.
@mercime – Gigantic ‘Yes’ to no more BP Template Pack questions! You have answered so many of those questions and helped out so many users with these issues.
Yup, we need new codex pages to detail all the cool BP 1.7 stuff in the works.
If you need some help drafting some pages, let me know.
But r-a-y that would mean we end up using one file that has to do all the work? Means a lot of querying and conditional testing in one file doesn’t it? If I want a specific look for a user account screen action I would have to test for the action load a template_part which I would have to fashion from the existing member/single/ file but then also start having to consider the same main framework file is handling all views for BP or am I over thinking this?
or am I over thinking this?
Hugo, my answer was towards Roger’s question about having different areas on the external page template based on his requirements. It’s not meant to be a page router for everything as BP already does that.
Example: Like Roger, I want to have a sidebar on member profile pages only.
I don’t want to let BuddyPress use the `page.php` template as a default, so I’ll create a template file called `plugin-buddypress.php`.
BuddyPress will use `plugin-buddypress.php` instead of `page.php` for the skeleton. Like `page.php`, this new template file will need to include “ somewhere in the template as that is what BP looks for to inject our content.
Now, I only want to enable a sidebar for member profiles only.
So somewhere in `plugin-buddypress.php`, I’ll do something like this:
`<?php
// are we on a user profile page? if so load up our special members sidebar
if ( bp_is_user() ) :
get_template_part( ‘my-special-members-sidebar’ );
?>`
This will enable me to show a different sidebar on a user profile page only.
Yep so my original hypothesis stands, and actually Roger and I were discussing much the same requirement, which prompted the question he posed, feel as there are issues lying dormant here but have to play around far more than I’ve had the opportunity to thus far.
Cheers for the feedback guys.
The problem with plugin-buddypress.php will come on sites where we have a number of different layouts / irregular layouts depending on which component the site is displaying. It works OK for a small number of conditional includes, but would become cumbersome with many conditionals (as @hnla alludes to), and effectively become another layer of [edit] page routing [/edit] (as @r-a-y rightly points out we want to avoid).
I’ll take a look at the bp_get_query_template filter – but, guess that would just be pushing the same additional logic to a different area of code.
What’s the ideal solution?
Ideal is , I think, beyond the scope of what BP is able to achieve at the moment and I guess would be encapsulated in the approach and methodology that bbPress has now. I suppose in an ideal world I had hopped that I would or could do page-members.php but things aren’t that straightforward when dealing with accounts/profile screens. On a recent project there was a requirement for a new front.php for single groups, in that scenario I didn’t want or need a sidebar simple enough to remove from my new template, but now that becomes a tad harder? so i would need to start finding means of testing what components/actions were in effect, which I can see getting very messy.
`bp_get_query_template()` filtering sounds like a bad approach really, overly complex for what is a relatively trivial requirement when talking about customizing templates for frontend coding.
BuddyPress all of the theme compatibility code that’s in bbPress. We’ve not left any of that out. I’m not sure what you mean.
hmm ok this isn’t perhaps a fair example, but illustrates the ease with which I can do what I need in bbPress:
We have a template part ‘content-archive-forum’ do nothing and this template part injects into page.php. I can overload the template part dragging it into the theme modify and still have it inject into page,php – however now I have a different requirement page,php is no longer suitable but I can create a new template in theme root archive-forum.php and use that to call the appropriate template_part ‘content-archive-forum’ /forums/ now finds that template rather than page.php.
As I say though not perhaps best example.
@djpaul, @hnla, @r-a-y, @mercime et al,
I’ll move the conversation back over on to the trac ticket, as I think that’s the best place for this discussion to stop it becoming lost.
As @hnla points out bbPress whilst supporting template parts auto injected into page.php, also allows you to provide full templates for specific content where you want to override the automatic mechanism (TBC). As with the WordPress template hierarchy it’s based on the type and name of the content being displayed. So, for example — you could create a template archive-myforumxyz.php.
I suspect a similar hierarchy based system for BuddyPress would be best route — with template hierarchy names that recognise display of single groups, single profiles, directories, etc., and override the auto injection into page.php if defined.
Will elaborate my thoughts on the trac.
bbPress gets that “for free” because it uses custom post types and therefore WordPress’ template hierarchy. Let me see what I can do for BuddyPress.
| bbPress gets that “for free” because it uses custom post types
Yep that’s why I cited that as a somewhat unfair example, beginning to wonder whether it wouldn’t have been better to bite the bullet and take BP all the way rather than a two stage process for templating, but even a hackish workaround as Roger suggests might be better than nothing? for the moment, until BP can realise CPT’s in all their Glory.
@djpaul – great… let me know how that pans out
I took a look at bbPress last night to see what it was doing differently.
Note: this is becoming more into a dev discussion than anything so bear with me!
bbPress does things differently in `bbp_template_include_theme_supports()` compared to BP in `bp_template_include_theme_supports()`.
bbPress:
`https://bbpress.trac.wordpress.org/browser/tags/2.1.2/bbp-includes/bbp-template-loader.php#L13`
BuddyPress (trunk):
`https://buddypress.trac.wordpress.org/browser/trunk/bp-core/bp-core-template-loader.php#L236`
We could probably mirror the same changes as bbPress by adding the page conditionals in `bp_template_include_theme_supports()` like bbPress does.
What do you think, @djpaul @johnjamesjacoby ?
Update: Just read through the dev chat and it looks like Paul is already working on something!
