[buddypress-trac] [BuddyPress Trac] #6556: BP Core Frontend Templates Refactoring

buddypress-trac noreply at wordpress.org
Mon Jan 25 13:59:50 UTC 2016


#6556: BP Core Frontend Templates Refactoring
-----------------------------------------+---------------------------------
 Reporter:  hnla                         |       Owner:
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Under
Component:  Appearance - Template Parts  |  Consideration
 Severity:  normal                       |     Version:
 Keywords:  dev-feedback                 |  Resolution:
-----------------------------------------+---------------------------------

Comment (by hnla):

 >Core files frontend code: Identifying & extracting - where possible - all
 markup from core to template files, ...

 Revisiting this ticket to look at instigating the point above as a
 preliminary series of tasks, that are standalone in their own right. but
 also required in advance of any possible re-building of new template files
 ( once moved it allows the freedom to do what one wants with the markup as
 it now lives in the template section of core and is easily overloadable.)

 I have begun re-factoring a local install to test this process for
 extracting and re-positioning core markup functions.

 Our primary benefits here are:

 * We remove and lighten the core file with less code to maintain,. In the
 new file  we can re-factor the functions to a degree to be leaner, re-
 using the basic makup rather than repeating it.

 * Access to and customizing of these functions/markup is now a lot easier,
 while still retaining the apply_filter method.

 Somewhat sadly in the initial pass it appears necessary to have to
 preserve the template tag names/functions as they are all unique to each
 component plus each has an apply_filters call so to effect a change like
 this we must be careful not to break templates or filtered functions

 Naming of files/folders is obviously something needing discussion.

 Current proposed & tested approach:

 * In buddypress-functions.php I have created a new `locate_includes()`
 function passing to it a file name which is then checked for file_exists -
 this is a cut down version of existing `locate_assets()` this will allow
 us to check where we find the file and return a path to it.

 * In bp-legacy/buddypress/ I have created a new folder `_incl` in which I
 propose locating any template tag like functions.

 * As a first run I have added a new file `bp-dir-search.php` this file
 extracts all core html search functions from the various
 bp-*-templates.php core files. In this file I rework the search functions
 splitting out the actual markup to it's own function then running the
 existing function names to preserve backpat in possible overloaded
 templates along with their apply_filters and passing the unique params
 query string, markup tokens etc to the base markup function
 `bp_get_dir_search_markup()`


 The initial test is on the dir search forms for which I'll create a
 ticket( against 2.6) if we want to progress this, then I'll create further
 tickets for the other functions such as dir filters, bulk-action filters;
 although I would like to list thse in some ticket so we can see at a
 glance what exists to be tackled and whether it has a ticket to cover it,
 i.e is underway

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


More information about the buddypress-trac mailing list