[buddypress-trac] [BuddyPress Trac] #6556: BP Core Frontend Templates Refactoring
noreply at wordpress.org
Wed Jul 15 09:21:47 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 | 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
- 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
- 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
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
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/>
More information about the buddypress-trac