Opened 11 years ago
Last modified 7 years ago
#32528 new feature request
Create a new search_form_content hook in get_search_form()
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 4.3 |
| Component: | General | Keywords: | |
| Focuses: | ui, administration | Cc: |
Description
The only viable method for creating a custom search form in a plugin or theme is to replace the entire default search form.
This runs the risk of introducing possible security issues should a patch be issued in the default search form. More importantly it means more potential deviation from "the WordPress standard".
Instead of requiring developers to recreate a new feature that mimics the HTML that get_search_form() provides, consider adding a new filter that allows developers to easily add HTML elements to the search form.
The current general-template.php get_search_form() snippet:
if ( 'html5' == $format ) {
$form = '<form role="search" method="get" class="search-form" action="' . esc_url( home_url( '/' ) ) . '">
<label>
<span class="screen-reader-text">' . _x( 'Search for:', 'label' ) . '</span>
<input type="search" class="search-field" placeholder="' . esc_attr_x( 'Search …', 'placeholder' ) . '" value="' . get_search_query() . '" name="s" title="' . esc_attr_x( 'Search for:', 'label' ) . '" />
</label>
<input type="submit" class="search-submit" value="'. esc_attr_x( 'Search', 'submit button' ) .'" />
</form>';
} else {
$form = '<form role="search" method="get" id="searchform" class="searchform" action="' . esc_url( home_url( '/' ) ) . '">
<div>
<label class="screen-reader-text" for="s">' . _x( 'Search for:', 'label' ) . '</label>
<input type="text" value="' . get_search_query() . '" name="s" id="s" />
<input type="submit" id="searchsubmit" value="'. esc_attr_x( 'Search', 'submit button' ) .'" />
</div>
</form>';
}
Allow developers to easily insert additional input elements between the search input and submit elements:
if ( 'html5' == $format ) {
$form = '<form role="search" method="get" class="search-form" action="' . esc_url( home_url( '/' ) ) . '">
<label>
<span class="screen-reader-text">' . _x( 'Search for:', 'label' ) . '</span>
<input type="search" class="search-field" placeholder="' . esc_attr_x( 'Search …', 'placeholder' ) . '" value="' . get_search_query() . '" name="s" title="' . esc_attr_x( 'Search for:', 'label' ) . '" />
</label>'.
apply_filters( 'search_form_content', '' ) .
'<input type="submit" class="search-submit" value="'. esc_attr_x( 'Search', 'submit button' ) .'" />
</form>';
} else {
$form = '<form role="search" method="get" id="searchform" class="searchform" action="' . esc_url( home_url( '/' ) ) . '">
<div>
<label class="screen-reader-text" for="s">' . _x( 'Search for:', 'label' ) . '</label>
<input type="text" value="' . get_search_query() . '" name="s" id="s" />' .
apply_filters( 'search_form_content', '' ) .
'<input type="submit" id="searchsubmit" value="'. esc_attr_x( 'Search', 'submit button' ) .'" />
</div>
</form>';
}
There are a number of ways to implement this, including the possibility of passing in the initial label + input fields HTML as a parameter to the filter.
The general idea is to keep the form HTML and submit HTML intact to ensure maximum functionality/compatibility with the core search feature.
As long as the hook processor does not impart too much overhead, this may be a viable feature to keep more control over the search form and simplify/eliminate many custom searchform.php files that only need to add an extra input element such as "select a category" to further refine the search mechanism.
Attachments (1)
Change History (3)
#1
@
11 years ago
I'm not sure this filter is a good idea myself.
Themes can specify an alternate searchform.php template for the search form already, which the proposed filter will skip.
Additionally, there's a get_search_form filter which runs on the entire HTML chunk from both the Theme and the html/html5 form chunks.
Introducing a filter to make it easier to insert search form fields, which doesn't get used in a chunk of cases doesn't seem useful to me, although I can see that inserting extra fields via the get_search_form filter is painful..
#2
@
11 years ago
Yes, I know about searchform.php which is great for templates. Not so great for plugins, especially widget-centric plugins.
There are hundreds of widget plugins, and I bet themes using searchform.php as well, that are replicating MOST of the content generated by get_search_form only to add a new input field on the form.
That creates a LOT of duplicate code and it opens the door to a lot of things breaking if a future release decides to augment the default search form, adding a new super-secure nonce as a security mechanism for example.
Since the overhead of filter and hook processing is fairly minimal , adding the hook and eliminating loading of hundreds of lines of duplicate code into memory may offset the execution cost.
Meta inquiry: How did you get the formatting around "searchform.php" and "get_search_form"?
Proposed patch as desribed in ticket.