[buddypress-trac] [BuddyPress Trac] #6556: BP Core Frontend Templates Refactoring
noreply at wordpress.org
Sat Jul 18 10:44:08 UTC 2015
#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
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
> 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
>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
''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/>
More information about the buddypress-trac