[buddypress-trac] [BuddyPress Trac] #6844: Extract & relocate core markup functions: Theme compat include functionality & search forms file

[buddypress-trac]

#6844: Extract & relocate core markup functions:  Theme compat include
functionality & search forms file
-----------------------------------------+------------------------------
 Reporter:  hnla                         |       Owner:
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Appearance - Template Parts  |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch dev-feedback       |
-----------------------------------------+------------------------------

Comment (by hnla):

 @boonebgorges Thanks for looking over this and the feedback. Mainly I do
 agree with all your points, and really just felt somewhat compelled to
 work things the way I did :(

 `has_filter()` good point hadn't occurred to me to make use of this sort
 of check in some manner.

 >we've lost just about all the flexibility that we mean to gain by
 generating the markup in theme files rather than in core

 This is true, however we still achieve one aim of removing the onus on
 core to maintain these functions/snippets of markup even if the
 implementation in the new file is sub optimal.

 >...you have to override an entire file full of functions (like bp-dir-
 search.php) in order to make a single change...

 Again yes you do, although I don't see that as a massive issue, so one
 moves a file, in a sense the same could be said of copying a whole
 template file to make a simple class token change, but really the point
 here is to keep the functionality/markup under the control of the template
 level folders

 In the ideal world and as I have done before the new file or search
 functions were actually reduced to one simple function (part of the point
 of these changes is that much of this core markup is actually replicated
 code) there is in reality a search function with a few very simple
 variable changes this I've handled by running a switch statement checking
 for current component and changing up my variables thus one form and  one
 template tag call e.g `bp_directory_search_form()`

 `bp_get_template_part()` Vs. file includes was something I did wrestle
 with and intended initially on using bp_get_temp... for it's stack logic
 then I worried that I was having to retain the original functions and
 wasn't in truth fetching templates but simply needing to call functions so
 settled on approach in that new file as a compromise.

 >Let's move all these search forms etc into proper template parts.

 Ok, or at least to my mind and following your approach outlined  not
 part(s) but part i.e still a single file freed of maintaining the original
 functions I now reduce this to one running some logic to determine what
 query to run, tokens etc, this would require we locate this 'part'
 somewhere e.g 'incl' or whatever thought better.

 The next suggestion I have mixed feelings about, it's a solution and one
 that works and we could run with it:
 {{{
 <?php if ( has_filter( 'bp_directory_members_search_form' ) ) : ?>
     <?php bp_directory_members_search_form(); ?>
 <?php else : ?>

     Put our new and improved markup here

 <?php endif; ?>
 }}}

 My reservations here are:
 * It defeats the object of removing code from core that shouldn't and
 needn't be there.
 * In the eventuality (albeit it slim) we need to change an aspect of this
 code we have to do so twice over.
 * It feels like we're just stuck with legacy code and uglyfying the
 template code looking for that legacy function if it's filtered.


 If we retained the original functions could we not move them into
 deprecated positions?

 In respect of the file location what is perceived as best approach, I
 still regard these functional aspects as something I would ordinarily
 maintain in an included file so functions were available, if we go the
 bp_get_temp... route where do we think we should locate these files given
 we will be dealing with, filter selects, bulk message actions, do we see
 these sorts of parts as living in say a top level dir such as 'incl' or
 'template-parts' ?

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