[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                       |   Keywords:  dev-feedback
-----------------------------------------+-----------------------------
 This ticket proposes an initiative to begin the process of refactoring the
 core template files to a new level of standards that clears up some of our
 legacy issues with markup, core markup, classes and general structure.

 It would encompass four main areas.

 - Template files markup and classes(tokens):  Each file stripped back and
 re-built focusing on a leaner structure, improved tokenism and
 accessibility  improvements.

 - Core files frontend  code: Identifying & extracting - where possible -
 all markup from core to template files, also in addition, to sweep through
 all template tags identifying those that ought to be able to pass
 arguments with a view to enabling bp_parse_args for them and any obviously
 sutable paramaters.

 - Creating template parts: In tandem to the core markup issue might be
 extracting certain markup elements such as filters and or search to thier
 own get_template parts  allowing us to manage these elements easily from
 the frontend templates.

 - Stripping back assets: Essentially taking the opportunity to deep clean
 the JS files, removing all but essential JS ?Cookie functionality and
 perhaps re-factoring JS into separate files by usage type.

 '''Frontend Template files (legacy to new)'''

 As this needs to be a unfettered refactoring the new templates would
 effectively cause the apple cart to overturn where existing themes had
 overloaded templates thus I propose a mechanism whereby we effectively
 default new installs to using the new templates, existing installs and
 possibly overloaded templates would be automagically checked and if found
 would be switched to using the Legacy templates. We have pretty much all
 the parts needed already I think to be able to setup a checking process so
 don't think this aspect would prove as hard as it may sound, further a
 selection option would be provided that allowed users/devs to select what
 templates used - here we would have some logic puzzles to deal with,
 existing site installs would be switched back to Legacy templates, however
 they may choose to update and switch to the new in which case then we need
 to capture that decision as a check before we do any switching of existing
 installs.

 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.

 '''Core Markup'''

 I envisage a master ticket that attempts to identify and list these core
 frontend markup objects as found; one might be generically 'Dir Search
 Forms' another might be 'Messages/Notifications Bulk Select Markup' we'll
 locate it in the core files and once tacit agreement is arrived at to
 proceed on one of these  it will be branched off to it's action ticket to
 flesh out the details and agree a method for re-working to frontend
 template parts where applicable.

 I think there has been a generally acknowledged acceptance that core holds
 too much frontend template markup, bloating core files, making it harder
 to do simple re-factoring without having to break off, create a function,
 return as a filter etc.

 In some cases we actually have duplicate markup effectively; bulk
 message/notifications selects is a case in point where markup exists in
 core bp-*-template.php for respective components but where in reality the
 markup is the same, the only difference being the select control 'name',
 so it seems to make sense we could extract this to one include file and
 use current_action to provide correct control 'name'.

 Core will benefit slightly from lighter files, less code to wade through,
 developers will gain easier access to markup to modify if they wish.

 I don't say some of these won't require a little more work than simply
 copying out, some will have possibly a series of functions/filters that
 might need re-thinking.

 I think this task will greatly help future template implementations and
 provide what we'll all probably agree as better separation of core
 functionality from template functionality and ease some of the
 frustrations in working on frontend templates.

 It's possible the task may span more than one release cycle (there's a
 little more work than it might at first appear), but once we have a clear
 master list of tasks agreed on we then have the opportunity to group them
 into sets for a release if it does look like spanning release cycles.

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