Views mini pager is not working

Thanks, looks great. Committed.

Also, tested quickly on D7, but there the Mini pager works as expected. However, it seems it also uses a count query there, so that might not be saying much. We'd probably need a different, even more simplified pager to test with.

By chance, though, I now tried this out on D8, too, and for my setup it actually seems like the patch here broke the Mini pager. After applying the patch my search view with 93 results (10 per page) ends at the 9^th page, while it works correctly when I revert the patch.
Do you have any explanation for that? With what setup did you test?
Unless we find out how to fix this, I'll have to revert the patch. (Also, I guess this makes test coverage an even better idea for this issue.)

Just tested again, it obviously does have the result count in Drupal 7:

Also, as you see, there are ten rows per page (and 402 result items). But I really don't want to debug that in D7 right now. If no-one complains, I'll ignore it. (Also, I'm pretty sure d.o itself is using this, so I'm sure drumm would already have cried out if we had a bug in there.)

For D8 I also see 10 results per page, both with and without the patch.

That said, I'm on solr and on an older version, I'm not sure how that affects it?

I can't really say. But if you can't reproduce the problem with the DB backend, then maybe the Solr backend does something wrong there?
(Also, "older version" of what? If you're not using latest dev of both Core and Search API, that may be the problem, too.)

Huh, I don't think the concept of mini pager changed, that afaik also doesn't do a count query in 7.x, that's the point of it.

The concept definitely has changed between D7 and D8. In D7 there was also a count query for Mini Pagers.
That was one reason that modules like the module came up, for performance improvements on complex views, where the count-query could really create a recognizable loading time impact.

I can confirm this bug on Drupal 8.2.6. I was trying to use the mini pager in a search api view and could see that the mini pager is always disappearing after a page reload. After clearing the cache the pager is again visible till you are reloading the page. In views I have changed the view cache settings from tag based to none and the pager is now working on every reload. Search api cache have also been tested without any effects (and the last patch get skipped).

Hope I'm not hijacking a different issue - but I think the issue is with an incorrect cache result key - which would only be evident with AJAX enabled (I imagine this is pretty common with the mini pager and would explain what only some people have this issue).

Comparing the result key data to core, it seems in SearchApiCachePluginTrait no pager information is included in the key data.

Without AJAX enabled this doesn't cause any issues as the URL cache context provides the args, but with AJAX enabled you get:

1. Page load
Cache context manager returns the correct URL of the actual path of the page e.g [url]=http://yourdomain/path-to-view which will return the first set/page of results.

2. Click next
Cache context manager returns [url]=http://yourdomain/views/ajax?_wrapper_format=drupal_ajax which won't match the previous cache key, and thus return the second set/page of results.

3. Click next again
Cache context manager returns [url]=http://yourdomain/views/ajax?_wrapper_format=drupal_ajax which does match the previous cache key in step 2, and returns the second set/page of results instead of the third - this seems to also cause the pager to disappear, but other plugins such as views infinite cache continue to infinitely load the same second set of results over and over again.

Attached is a patch that includes the same pager data that view's CachePluginBase uses in generateResultsKey

Ah, thanks a lot for the explanation! That makes sense. Seems with all the back and forth with where to set paging, etc., we forgot to adapt that part.
Just some code style clean-up which we should have done sooner – in general, your patch already looks great to me.

Would be great if a few others could test it, too, and see if it resolves the problem for them!

Hello!

Yes this patch works, and indeed the problem was with generating the result key, I can verify that after almost creating a duplicate issue with my own patch :D

+1 for the wrappers around the properties for type recognition.

EDIT: it works for both mini and full pagers, too btw as the problem is not related to type of pager.

Good to hear, thanks a lot for reporting back!
Committed.
Thanks again, everyone!

I'm still facing the issue.

Drupal 8.4.0, search_api 8.x-1.5, using database backend (probably nobody is using that but the cause may be there).
The mini pager doesn't show at all, full pager is perfectly fine.

Not a production site or a project dev but a testing site for VBO. Also, I'm aware that the mini pager is strange and also had issues when trying to get total results count for a view with that pager.

When I debug the pager object, I get values:

public current_page -> integer 0
public total_items -> integer 6

where total_items is my page size and there are 18 items total in reality.

I also this problem with

Search api 8.x-1.18
Drupal 9.1.0
DB server