Jump to content

Search q parameter is not being passed


dragan
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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. 

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

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 (/).

Link to comment
Share on other sites

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 :D

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...