Empty search takes you to homepage instead of empty search page

[jacobfogg]

1. In the admin tool, if you go to "Settings->Reading" then choose "A static page (select below)" and choose a page for your "Front page" and a different page for your "Posts page".
2. Visit your blog (​http://localhost/ in my case) and you will see your static page.
3. Navigate to your blog (​http://localhost/blog/ in my case).
4. Enter a search string (e.g. "test") and click "Search". This will take you to the search results page (​http://localhost/?s=test in my case). Notice that it is located at the base of your site.
5. Return to your blog, leave the search textbox blank and click "Search". This _should_ take you to the search results page but takes you to the _Homepage_ instead (​http://localhost/?s= in may case).

IMHO, a blank search string _should_ take you to the search page and state "No posts found. Try a different search?" as it does when you enter an invalid search. At the very least, it should take you to the blog page.

The reason it takes you to the homepage is due to how the get_search_form() function in the /wp-includes/general-template.php file creates the Action url for the search form:

$form = '<form role="search" method="get" id="searchform" action="' . get_option('home') . '" >'

I propose a change in the code that will do the following:

if(get_option('show_on_front') == 'page'){//if the blog is not the front page
	$searchAction = get_page_link(get_option('page_for_posts'));//get the link to the blog
}else{//if it is the front page
	$searchAction = get_option('home')."/";//get the link to the home
}

$form = '<form role="search" method="get" id="searchform" action="' . $searchAction . '" >

That way, at the very least, you know the search is landing where it belongs.

This, however, does not _fix_ the issue where a blank search does not land you on the search page. My guess is, wherever it is determined what page is displayed, there is a check for something like:

if($_REQUEST['s']!=''){
  //if the request var 's' is not blank, this is a search
}

If that is indeed the case, a simple change of the code to something like this should do the trick:

if(isset($_REQUEST['s'])){
  //if the request var 's' isset, this is a search
}

itching to close this as wontfix.

you're describing the expected behavior, which works fine, so this technically is an enhancement. and then, it seems extremely specialized.

Well as enhancements go, it makes a lot of sense. Hitting the Search button should take you to a Search result page, even if there is no result.

This is related to #10710.

This may seem trivial if WP is using as _just_ a blog, however you are using the site as a web page with a blog, a search performed on a blog page should NOT send you back to the home page.

please when this trivial needs patch will be solved?

Imho it is bug, search should definitely put you on search page even when you search nothing. So we would be easily able to create separate search page (in many countries it is a must-have accesibility rule when creating webs e.g. for public administration)

P.S.: if i would consider this as an enhancement, it would be to have an option to give it some sexy url, but this could be solved by something like

add_action('template_redirect', 'nice_search');
function nice_search() {
    if (is_search()) {
        $search_uri = get_bloginfo('url') .'/search/'. urlencode(get_query_var('s')) . ((get_query_var('paged')) ? '/page/'. get_query_var('paged') .'/' : '/');
        if (!empty($_GET['s']) || !empty($_GET['paged']))
            wp_redirect($search_uri);
    }
}

Other solutions are cropping up that indicate that this "should" really be updated.
What's the logic in not counting an empty search as search?

function fix_empty_search ($query){
    global $wp_query;
    if (isset($_GET['s']) && empty($_GET['s'])){
        $wp_query->is_search=true;
    }
    return $query;
}
add_action('pre_get_posts','fix_empty_search');

Please don't "bump" the version.

Replying to strop:

What's the logic in not counting an empty search as search?

The logic was that WP_Query can't distinguish between when the search parameter is empty vs. when it's not set at all.

Like every patch involving WP_Query, extreme care will have to be applied in order to not cause other unexpected behavior.

Replying to scribu:

Like every patch involving WP_Query, extreme care will have to be applied in order to not cause other unexpected behavior.

Of course, but it shouldn't stop an obvious bug from being fixed.

Sorry about the version bump.

This issue has come up in my development cycle too.

I'm opting for strop's solution but I've modified it to work for me, especially the need to put is_home to false.

function search_query_filter($query) {
	
   // If 's' request variable is set but empty
   if (isset($_GET['s']) && empty($_GET['s']) && $query->is_main_query()){
      $query->is_search = true;
      $query->is_home = false;
   }  
   return $query;

}
add_filter('pre_get_posts', 'search_query_filter');

Closed #10156 as a duplicate.

Patch does the following:

1) WP_Query::is_search is true if 's' query var exists (isset)

2) The search query becomes AND 0 if the term is empty so the SQL query will tank right away

3) Ditches the comment join generation if the search term is empty

Result: empty search terms go to the search page

Replying to wonderboymusic:

1) WP_Query::is_search is true if 's' query var exists (isset)

This doesn't work as intended. Query vars (including 's') are always set in fill_query_vars():
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-includes/query.php#L1356

With the patch applied, home page is displayed in search.php template and shows "Nothing Found".

Related: #18485

ah yes I see - I attached a new patch, is_search = not empty OR main_query and 's' query_var exists

empty-search-string.2.diff​ seems to work.

This seems like a bolted-on solution. Why should we treat just the 's' parameter differently?

That's my problem with 800 line methods and 200 line loops (elsewhere), makes it hard to do surgery. I am open to alternative solutions.

The length of the method has nothing to do with it, though it will probably grow, since refactoring for it's own sake is frowned upon, since we don't have unit tests to ensure that everything still works afterwards.

Anyway, the issue is that we ignore all empty query vars, except for 's', but I guess that's ok, since it's the only one that does a search, rather than an exact match. Well, we also have 'sentence', actually.