[buddypress-trac] [BuddyPress Trac] #6556: BP Core Frontend Templates Refactoring

[buddypress-trac]

#6556: BP Core Frontend Templates Refactoring
-----------------------------------------+------------------------------
 Reporter:  hnla                         |       Owner:
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Appearance - Template Parts  |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  dev-feedback                 |
-----------------------------------------+------------------------------

Comment (by boonebgorges):

 hnla, thanks for starting this conversation. Your specific bullet points -
 moving markup out of core functions, breaking templates into template
 parts, etc - all seem worthwhile to pursue.

 > This approach to templates could afford us the opportunity to follow a
 similar paradigm to the WP default themes whereby we could roll out new
 templates and corresponding styles on a yearly or irregular basis but be
 able to do so safe that it then becomes a user choice to use them and
 those new templates are free of any concerns in preserving legacy
 behaviours.

 I'm skeptical that this is viable. First, WP's team of contributors is
 larger than ours by orders of magnitude. Not only that, but the yearly WP
 themes - at least in their initial design and implementation - are pretty
 much commissioned by Matt. I don't feel confident that we can muster the
 wherewithal to keep up this pace on the BP team.

 Moreover - and this, to me, is the crux of the template problem - frequent
 breaks with backward compatibility (in the form of new default templates)
 result in multiplied maintenance tasks for the core team. Think about bp-
 default and bp-legacy: every time we add a new feature to bp-legacy, we
 get complains about how it doesn't work in bp-default, and for a good year
 and a half we actually added the new feature to bp-default. How would we
 manage this with three or four or five default template packs? We'd have
 to have an EOL policy for our own sanity, but users would be frustrated by
 such a policy, as they don't want the onus of having to change their
 templates every year or two.

 For these reasons, I support the idea of writing new templates, but I want
 to make sure that when we do it, we make it count. The basic layout of
 most of our templates has been the same since bp-default was introduced in
 BP 1.1 or 1.2. That was five years ago. What have we learned about our
 component UIs since then that could benefit from a sweeping change? (Think
 about the multi-pane Messages interface that was discussed in the
 turtleshell project.) What changes have taken place on the web that might
 affect the way we think about templates? (Do we, say, build in native
 support for header images, like Facebook and Twitter have recently done?)
 Etc.

 > with this process I'm more interested in separation of presentation from
 content in other words addressing the templates with a view to a robust
 and stable set of files that can then be styled; initially with a thinned
 down core stylesheet although equally if people are willing with more
 detailed styles for BP elements.

 I realize that this is your response, but my point is that once you force
 people to a new template pack, it doesn't matter whether your changes are
 related to UI, or to underlying tech, or both, or neither: the damage is
 done. So let's only do the damage once, if possible, and solve as many of
 the extant problems as we reasonably can.

 I should note that I'm not necessarily calling for a bottom-up redesign of
 BP UI. If that's too tall an order - which the sputtering nature of the
 Template Pack project suggests - then let's by all means do something more
 modest. At the same time, let's do it with a recognition that a major
 break in back compat is something we want to do only very rarely.

 Sort of a side note: Some of what hnla suggests here - like more focused
 template parts - will mean that, in the future, we can more easily
 improve/modify/refactor the templates *without* compatibility breaks.

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