Opened 9 years ago
Last modified 5 years ago
#32528 new feature request
Create a new search_form_content hook in get_search_form()
Reported by: | charlestonsw | 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
@
9 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
@
9 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.