BP Theme Compat: Administration screens & control

[imath]

#6290 gave birth to two new needs:

• loading template parts within BuddyPress Administration screens
• "restraining" the template dir locations to the bp-legacy one to keep a core control over some template parts.

This control can be limited in the time: we're introducing a new feature requiring new template parts and we want to clearly inform we need to have time to iterate on more than one version on them.
It can be permanent: in the BuddyPress Administration screens to inform we only want to use the bp-legacy template parts.

In 01.patch, you'll find the strategy i'm suggesting to achieve this.

[DJPaul]

I guess this is okay, but, is there a reason why we couldn't just require 'bp-legacy/buddypress/some/file.php ?

[imath]

Sorry, i'm not sure to understand, could you explain a little more ?
use require to replace the whole patch ?
use require in each Backbone templates in #6290 ?
use require instead of making sure the templates won't be overridable from the theme ?

[DJPaul]

Instead of:

bp_get_restrained_template_part( 'file.php' )

Something like:

require buddypress/bp-templates/bp-legacy/file.php.

[imath]

Thanks a lot DJPaul.

I'd say we can do it of course. But then, we'd need to do it in all the backbone templates if we want to make sure to get the templates from bp-legacy.

Using 'bp_get_restrained_template_part()' allow us to keep on using the regular bp_get_template_part() in the child template parts. So i guess, i found it easier when we are more secure about a template part to remove '_restrained' at the top template than to edit each templates.

Then if we don't have 'bp_get_restrained_template_part()' and the part i'm changing in bp_locate_template():
using require into the top template from the administration screens wouldn't work if the child templates are using bp_get_template_part().

Finally i find it less elegant :)

But if we plan to never let these templates being overridable i'd say you're absolutely right, else i'd say i'd like to have @jjj's opinion :)

[johnjamesjacoby]

A few (of my) core philosophies (I'm hoping we mostly agree on):

• Err on the side of almost-never restricting access to anything
• Try not to commit code we may want to deprecate later
• Relatively strict separation of wp-admin and WP_USE_THEMES output

Why I think this:

• Even though a RESTful API is around the corner, wp-admin is WordPress's only real UI, and we can rely on it existing for years to come
• BuddyPress originally was a wp-admin only interface, and I love the idea of BuddyPress incrementally revisiting this with a decisions-over-options approach
• WordPress plugins and themes come in infinite configurations and permutations, and the goal of bp-legacy (and any other packs) is to stay as flexible as possible in that environment, and if tuning pieces of it to work in wp-admin compromises that, I do not think it is the correct approach

My conclusion would be:

• I'm okay with mostly duplicate code for handling the nuances of wp-admin and WP_USE_THEMES
• I'm opposed to putting any restrictions on template parts in bp-legacy
• I'm opposed to special-casing bp-legacy (or any template pack) in the theme-compat API

This translates to:

• Code for wp-admin should live within the component it's for – I.E. bp-activity/admin/whatever/
• Code for WP_USE_THEMES should live within bp-templates/whatever-pack/

[imath]

Ok. Understood. Thanks.

[johnjamesjacoby]

imath – I meant to add that I appreciate your architecting solutions to these problems, and experimenting with ways to keep the codebase lean. Sorry that you invested time into this approach that maybe was wasted, but I still think the exercise was valuable and helped to identify what problems we are trying to solve and why, to eventually define how.

So, nice work on all of this so far.