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

 @boone thanks, yes I actually agree with your comments in the main and we
 needed this counter to my musings to balance things.

 In respect of the notion of running in a sense a WP style template
 approach:

 >I'm skeptical that this is viable

 I agree entirely on those points.

 >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.

 Yes and that would be an entirely retrogressive step helping no one and is
 something we must avoid.

 As for forcing users into new templates we would always have this issue
 with anything newly introduced or changed of breaking what might be
 established, it's that which is why, really, I mentioned the approach of
 defaulting new installs to new templates but checking existing
 installs/upgrades and switching them back to the original legacy files, it
 does mean keeping two sets of templates but not sure there's  better way
 of moving things forward?

 The initial proposal should not be considered modest though, in fact the
 reverse is true it's a very deep sweep through templates, the focus on
 separation of content from presentation is intended to highlight the
 essential principles of CSS/HTML where the document modal for a given
 rendering of data has not many choices in it's structure and constructs
 but just one ideal description of the content, styles are then meant to be
 able to re-define that visually in whatever fashion they see fit.

 Thus what we attempt to do is setup up a series of templates that deal
 with  the content in the best manner possible, we extract core markup and
 re-locate to new template parts, we attend to the perfect round of
 classes/IDs ensuring we have correct classes for generic elements then
 ones for specific elements (currently our navs miss that ideal ).

 Having achieved that to a large degree that never needs to be re-visited (
 added to maybe with new components  or templates but not having
 necessarily to go back to messages because something isn't quite right.

 Styling or  UI/UX is really a secondary phase, one I would love to see
 tackled but one that is not mutually inclusive to the first process. In
 the first instance I would envisage a sweep through the existing
 stylesheet adjusting / updating rulesets for classes and IDs further
 thinning out our styles to carry a little less specificity( a problem on
 occasion with the companion styles) We are then setup to either leave a
 modest amount of styling or to look to tackle things to a greater degree
 and seeing just what we can do to spice up the UX of aspects like the
 messaging component.

 So I think we should forget the notion of:

 >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

 It was a passing thought only but with too many issues within it.

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