[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 hnla):

 The support question does appear to be the crux of things and as always
 that or backpat, whatever term we wish to append to this notion of
 maintaining working installations is the one where we shy away from hard
 decisions?

 I get all the problems addressed above, but not sure what the solution is
 that keeps everyone 100% happy or if that is actually feasible.

 > We currently support bp-legacy.

 We do, but why! And for how long do we? Are we simply going to
 indefinitely support versions? what is our cut of point for support, lets
 actually determine when we unburden ourselves of this?

 On this question of versions, support and customised sites/ overloaded
 templates as I've mentioned before I think, to some extent we ought to
 view these circumstances of customised templates as carrying with them an
 implicit acceptance to maintain those custom templates in the face of
 whatever changes or updates BP pushes through; that leaves the real issue
 as one where an install today using unmodded legacy files upon updating BP
 finds the element rendering has gone and changed and they weep - this
 point is taken.

 > Styling or UI/UX is really a secondary phase

 I only really labour this point to try and ensure that the notion of
 content separation is understood and that what this proposal is really
 about is not a fun one about style, layout and cool things ( lord knows
 I'd give my eye teeth to get back to doing interesting CSS in general in
 working life) but about the scaffolding we use to hang those styles on, if
 we didn't actually tackle any particular styling we would be having to
 track through the default styles updating any rulesets necessary to ensure
 that in fact the transition didn't upset things. Labouring things even
 further:

 > Anyone who installs BP 2.5 or 2.6 using bp-refactored and customizes
 those templates will be unable to upgrade to bp-totally-new.

 1. The proposal was always really about a set of templates that didn't
 change - bp-totally-new would suggest styles, presentation, as the
 templates have achieved 'perfection' :)
 2. If BP adds new components, creates new screens or new template tags
 etc, then this is not a new issue this issue has always existed; anyone
 who customizes or overloads templates faces this issue of having to
 maintain and update ( I know I've had to often enough) so nothings really
 changed?

 >I know that it'd make your task easier to have carte blanche in
 refactoring, with zero concern for backward

 I think there comes a point logically where always having to keep one eye
 on backpat is simply too frustrating, whether that be core mid tier or
 frontend, we have concerns in both areas in BP. I think what I'm trying to
 say with this is if one wants to do the right thing, to do a job properly
 then there comes a point where one needs to work without one hand tied
 behind ones back. certainly in nearly every patch I've submitted over
 these years there's a frustrating burden in having to examine a change
 from so many perspectives, often when a change is straightforward and
 justifies no more than  a ms of ones time. :)

 Which desiderata can be achieved without upsetting backpat?

 > - Moving markup generation from functions into templates (a job that is
 going to be extremely unpleasant, by the way) probably *can* be done
 without breaking backward compatibility.

 I have looked at many elements of this, and with some have already stepped
 through the exercise with Status and the template pack and other off
 project exercises and yes this set of tasks is one that doesn't have
 backpat concerns, it's moving the location and possibly adding classes or
 ability to pass args back but not one of changing the resultant rendered
 markup.

 ''a job that is going to be extremely unpleasant, by the way''
 :) Oh indeed, it's not a pleasant task whatsoever and while some are
 relatively straightforward others will not be so and require core re-
 factoring to free them up to move.

 > - Changing selectors and the structure of markup mostly *cannot* be done
 without breaking compatibility.

 And that would be an issue, there is little point to the exercise overall
 if we're not able to address issues of this type, although preserving
 classes/IDs could be possible, being forced to retain markup though if
 found not to be optimal essentially probably nullifies the exercise.

 >IMHO, the guiding principle should be: If it can be done in bp-legacy, it
 should be done in bp-legacy. If it cannot be done in bp-legacy, it should
 be done as part of a full rebuild that includes a redesign.

 I'm not convinced that  ''if it can be done in bp-legacy'' is the right
 way of thinking, a lot probably can be and we just end up performing a
 half baked exercise? A full re-build is probably the only way of tackling
 this, but and it's an important but, design does not dictate function, we
 know the saying ''form follows function'' we must have the function
 correct  before the form is considered, the messages component in template
 pack was an example of how an attempt was made to create form when the
 function wasn't correct or ready to be 'formed'

 I'll freeform one other sketchy idea, partly in thinking about how the
 template pack was going to be implemented - maybe we create a new repo on
 bp github in that we work up template files with a view to a downloadable
 set of files intended to be dropped into a theme to overload the standard
 BP templates, but that still has attendant support issues and doesn't
 tackle the question of markup in core.

 Perhaps we only look at core markup to begin with as an isolated exercise,
 look to identify that, move it out to new positions in the template
 directories, that exercise, albeit it arduous and less than fun, has
 benefits to core and to developers building with BP.

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