[buddypress-trac] [BuddyPress Trac] #6844: Extract & relocate core markup functions: Theme compat include functionality & search forms file
noreply at wordpress.org
Wed Jan 27 13:30:52 UTC 2016
#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
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
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
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6844#comment:2>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac