Another guy in trouble with search pagination

[heldercervantes]

Hi guys.

I've seen a few posts regarding problems with search and pagination and can't figure out what's going on.

I started out with the new blog template's search. There's an IF at the beginning that checks if the query is blank, and I made my changes in there.

if($q) {
        
	$q = $sanitizer->selectorValue($q);
        
        $qs = explode(" ", $q);
        $fields = explode("|", "ref|title|version|type|notes");

        foreach($fields as $f){
            $group = array();
            foreach($qs as $q) {
                $group[] = "$f%=$q";
            }
            $selector .= ", (".implode(", ", $group).")";
        }
        
	$selector .= ", limit=4";

	// Find pages that match the selector
        $ads = $pages->get('/ads/');
	$matches = $ads->find($selector);
        
        $pagination = $matches->renderPager();
        
        $output = "";

	// did we find any matches? ...
        if($matches->count) {

		// we found matches
                $output.='    <ul>';
            
                foreach($matches as $ad) {
                    $output.='<li>';
                    $output.='  <a href="'.$ad->url.'">';
                    $output.='</li>';
                }

		$output.='   </ul>';
		$output.='</div>';
                $output.= $pagination;

	} else {
		// we didn't find any
		$output = "<h2>Sorry, no results were found.</h2>";
	}

} else {
	// no search terms provided
	$output = "<h2>Please enter a search term in the search box (upper right corner)</h2>";
}

echo $output;

So testing this out, the number of pages ir rendered correctly, but when I click a page, this code always goes into "no search terms provided". The post variable is obviously not being carried over, but looking the examples don't seem to do anything about that.

What did I miss?

[diogo]

Did you turn on pagination on this template?

[heldercervantes]

Yup. Was on to begin with. Tried turning it on and off to the same result. Pagination list renders correctly, same error when I click it.

[tpr]

Have you tried getting the matches in one go? eg:

$matches = $pages->find("template=page-ads" . $selector);

[heldercervantes]

Same result. $q is goes empty when I click a page number, and the IF statement turns false.

[LostKobrakai]

Have you tried getting the matches in one go? eg:

$matches = $pages->find("template=page-ads" . $selector);

Actually Page::find does just add "has_parent=$id, " to the selector and then call Pages::find, so no need to do this manually.

@heldercervantes

What's the $q you check for in the if statement? Do you retain that query to the next paginated pages?

[horst]

hmm, did you overwrite $q in your

 foreach($qs as $q) {

?

[heldercervantes]

@Lostkobrakai, $q is the post variable for the string. I'm catching it earlier in the header and the only action I'm performing there is an echo:

$q = $sanitizer->text($input->post->q);

@horst, for a second there I thought "THAT'S IT!", but nope. Changed the code but no effect. Now it reads:

foreach($qs as $qf) {
    $group[] = "$f%=$qf";
}

I've also tried discarding the selector altogether and just do a --- $matches = $pages->find("template=ad, limit=2"); ---, same behavior. More pages numbers generated, but can't change page.

Changing the method from post to get... same thing.

[heldercervantes]

I'm just thinking: Could this be a 2.5.29 problem? I upgraded last night for some features 2.5.3 doesn't have.

[teppo]

@heldercervantes: actually, it looks like you're missing one part, which would be $input->whitelist('q', $q). Check out the code (and comments) here for an explanation.

Whitelisted GET params are automatically included in the pagination.

[tpr]

I would try declaring $selector at the top ($selector = ""), plus playing with the "getVars" parameter of the renderPager (for $q).

[LostKobrakai]

I think your problem is that you mix up search and pagination. The pagination always needs to be called on the exact same pagearray. In your case this means that you need to have the exact same pages retrieved by your selector for each paginated page. Therefore you need to have some way of storing either $q or the generated selector for the next paginated pages to make the pagination work. That's what the whitelist teppo mentioned does for you.

[heldercervantes]

FOUND IT!

Teppo had part of the solution. I wasn't whitelisting the variable. But the other part of the problem was that I was usign the post method instead of get. Now it works but I'm not liking the dirty url very much (the search form passes other vars, that most of the time the user doesn't fill).

Is this "get only"?

Thanks for your help guys. Just now I was bragging about all the help I get from this community.

[LostKobrakai]

If you need this to work without get variables you need to build a own way to store the $q vars between pageloads. The simplest way, that does not involve javascript stuff to happen, is storing the variable in the session of the user. From there you can retrieve it as needed before doing your pages search.

Edit: Now I know again, why I never used whitelist for that job

[heldercervantes]

If you need this to work without get variables you need to build a own way to store the $q vars between pageloads. The simplest way, that does not involve javascript stuff to happen, is storing the variable in the session of the user. From there you can retrieve it as needed before doing your pages search.

Being the total noob that I am, I'll add this to my "nice to have" list and consider the improvement later. Right now I'm just glad I got it working

[LostKobrakai]

Not not as hard as one would think. Storing simple strings is really easy, see here: https://processwire.com/api/variables/session/.

[teppo]

Now it works but I'm not liking the dirty url very much (the search form passes other vars, that most of the time the user doesn't fill).

Depends on your use case, but I personally prefer GET variables in cases like search features. This way users can link to search results, share or bookmark them, and so on. What the URLs look like tends to be less important to me, though I do get your point too.

Generally speaking GET requests are preferable for "query" type requests, while POST requests have the edge when it comes to requests that trigger changes, shouldn't be cached or stored as-is, etc. This article by Jukka Korpela contains a pretty good summary about the differences, why they matter, and what are the preferred use cases for each method.

Anyway, glad you got it working!