Search q parameter is not being passed

[dragan]

On a new install (copy of an absolutely fine-working PW) the search is not working. And it's really strange: same server, same PHP versions etc.

The q parameter is not recognized by PHP. I tried to echo $_GET["q"] as well, but the var is empty.

The search URL is just domain.tld/search/ - instead of domain.tld/search/?q=hello

If I manually add the param in the URL: /search/?q=something, the search results are shown as expected. Error log doesn't show anything.

I also checked any .htaccess files, whether something else hijacks the q param for mod_rewrite - nothing.

Any ideas where to look further?

[teppo]

So when you submit your search form, you end up at domain.tld/search/ without q GET param? Are you absolutely certain that the form works properly? What about creating another, dummy form with only necessary attributes and fields -- ie. target "/search/", method "GET" and an input with name "q"?

If you're a Chrome user, you could also check Network panel in developer tools to see what's happening with your request. Turn "Preserve Log upon Navigation" on with round button at the bottom of dev tools to see if any odd redirects are happening. (Firebug probably has something similar.)

[dragan]

Thanks.

I think I found a solution, although I'm baffled why this should interfere with a simple GET form request...

I renamed the home page (id 1). It used to be "home-sweet-home", and I renamed it to the default "home". I tried it again, and now it all works as it should.

Well, not quite. I changed the selector to use LIKE queries, in order to also find partial terms, e.g. a word that appears in the site, is "Zwetschgenbaum" (plum tree in german). If I searched for "Zwetschge" (plum), I didn't get any results. I changed ~= to %= et voilà. The site is quite small (maybe 3 dozen pages), so any speed disadvantage is probably only in the milliseconds range (if at all).

[ryan]

I have no idea why $_GET['q'] would be missing from the request when you specified it, but the only thing I can think of is if your request possibly resulted in a 301 first that went by unnoticed? This could happen if you specified the URL without a trailing slash in your <form action> attribute. 

I changed ~= to %= et voilà. The site is quite small (maybe 3 dozen pages), so any speed disadvantage is probably only in the milliseconds range (if at all).

In modern versions of MySQL it seems there isn't much difference even when you get into thousands of records. I suspect the real difference starts showing up in the hundreds of thousands to millions of DB records to search. 

[dragan]

I can now replicate this behaviour: When you rename the "name" field of the home page (the URL alias), the GET parameter never arrives. That's probably what you meant with 

your request possibly resulted in a 301 first that went by unnoticed

Is this a bug or feature?

Anyway, I'll better leave the homepage (id 1) as is in the future, i.e. blank (/).

[Soma]

If the action of the form is without trailing slash and PW redirects to the url with a trailing slash, you'll get no GET. This is a feature

[dragan]

It was with trailing slash (apart from CSS copied from sample install). Perhaps a little note in the docs wouldn't hurt, that's why I added my last comment. Just in case someone else stumbles upon similar gotchas

tl;dr: Rename your id 1 page, and GET params won't get passed along anymore.