[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