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.

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:

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

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.

When parsing the main query, if s is set to empty: ?s= and $this->is_main_query() && array_key_exists( 's', $this->query ) - kill the query instead of loading the homepage. This will load the search page with no results.

Select any category in "View all categories" dropdown and click "Filter".

You'll get "No posts found", because the URL contains an empty s parameter.

If you choose a month in "All dates" dropdown instead, you'll also get an SQL error:
WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '0 AND develop_posts.post_type = 'post' AND (develop_posts.post_status = 'publish' at line 1] SELECT SQL_CALC_FOUND_ROWS develop_posts.ID FROM develop_posts WHERE 1=1 AND YEAR(develop_posts.post_date)=2014 AND MONTH(develop_posts.post_date)=06AND 0 AND develop_posts.post_type = 'post' AND (develop_posts.post_status = 'publish' OR develop_posts.post_status = 'future' OR develop_posts.post_status = 'draft' OR develop_posts.post_status = 'pending' OR develop_posts.post_status = 'private') ORDER BY develop_posts.post_date DESC LIMIT 0, 20

As I mentioned in my comment on the other ticket, I believe it's fair to assume that the resulting query has been built with query_vars (which is publicly accessible), and by passing the same array to a new WP_Query, I would expect to get the same results. Obviously Jetpack and other plugins can use the query array instead, which is also publicly accessible, but they didn't.

Reporting some infinite scroll breakage (again), sorry! Since IS builds off of query_vars and not query, the scroll request sets an empty search, which is expected given this change. The results are still correct, however the context is wrong.

IS uses a theme's content.php file to produce output, and many such files will display the_content() or the_excerpt() based on is_search(), like Twenty Twelve, so when scrolling Twenty Twelve is loading excerpts, rather than the post content because with an empty s the context is always search.

Changing IS to build the query from query and not query_vars seems to fix the issue, but reporting it anyway, just in case you guys wanna revert this ;)