WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 4 months 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:
PR Number:

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 &hellip;', '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 &hellip;', '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)

hook_search_form_content.diff (1.5 KB) - added by charlestonsw 4 years ago.
Proposed patch as desribed in ticket.

Download all attachments as: .zip

Change History (3)

@charlestonsw
4 years ago

Proposed patch as desribed in ticket.

#1 @dd32
4 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 @charlestonsw
4 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"?

Note: See TracTickets for help on using tickets.