Going back to "Page 1" displays "Page 0" in pager

I'm also getting the "Page 0" issue, but without even being able to paginate back and forth from any given views display. It just returns page 0 and reloads the page when you click "next".

What's odd is it doesn't happen on all views display at once. Only a few of them, "randomly" (not likely, but that's the impression it gives).

Only way to fix the issue is to a) clear all caches and b) clear the reverse proxy cache for the page.

Same error in Drupal version 7.28, Views (views) 7.x-3.8, Views Litepager (views_litepager) 7.x-3.0. Works ok until I press the back button of lite pager. Where the page number turns 0 and it's no longer working.

I have same problem with same setup as Amestar. Site is running for quite some time, but I noticed it just recetly. I use Litepager in /frontpage view, using Views Content Cache.

Had this issue as well and just fixed it. We had 5 lite pagers on one panel and had views content cache enabled as well. Pagers were displaying Page 0 on the first page and after navigating forward you could not return to the first page. Sometimes the the pager would die completely and stop reloading altogether.

I think the issue has something to do with multiple pagers on one page and the views content cache. Here's what fixed it for me:

Go to your view and check the settings for the litepager. Change the Pager ID setting to a higher number for each litepager in use on the page. View 1 pager ID =5, View 2 Pager ID= 10, View 3 Pager ID =15, etc.

Turn OFF any time or content cache setting that are currently applied to that lite paged view.

That fixed it for us.

This is entirely a caching issue. Nothing to do with multiple pagers. Its really a fundamental architectural feature of litepager. Because of how caching operates in views, it stores into cache the $view->results. This is cached BEFORE the pager query() and post_execute() gets run. See views_plugin_query_default->execute().

Since there are 0 results (according to cache), then this really makes returning a pager impossible.

Summary: this module and views caching are mutually exclusive. Can we get that added to the project page so as to help others out?

Thank you @heddn! I can confirm that disabling Views caching fixed this issue for me.

I had this same problem. Fixed it by disabling query caching in my view.

But I'm still curious. I recently upgraded to Views 7.x-3.8, which came out in May. Views Litepager worked fine with query caching enabled before the latest version of Views (7.x-3.8), so I'm guessing a change in the Views module is responsible for this issue? Does anybody know where the problem stems from in the Views code (or the change that causes problems with Views Litepager code)? I'm looking, but the complexity of that module is a bit beyond me.

re #10: See #8, specifically views_plugin_query_default->execute().

I'm not entirely convinced this is a documentation issue. Litepager should be able to work smoothly on cached views. I see this as a code issue, am I right?

Its not an issue for this pager to resole. It would need to be fixed upstream in views first.

Is there a relevant Views bug report we could give attention to?

I agree. heddn's explanation is on point. Appropriate to move this to Views issue queue?

As an experiment, I tried to execute a views_invalidate_cache() if the $pager_array returned an invalid response. Inside the render function of this module, It always sends 1 => 0 when the pager is broken. Even when my condition was met, the views_invalidate_cache() always failed. I thought I might be able to manually flush out the broken view cache, but this strategy didn't work at all.

I spent a few hours step-debugging this and found the code at fault. There is some strange code inside views.inc, which fails when the page is clicked. It's an if/else statement with no code to execute if the condition is TRUE:

(Starting at line 1219 of views.inc)

    if ($cache && $cache->cache_get('output')) {
    }
    else {
      if ($cache) {
        $cache->cache_start();
      }

The code fails sometime during the cache_get('output')

Edit: add line number.

In lite pager put offset =1
otherwise clear all cache.

I have attached a patch that I made at work to fix this problem. The patch forces views_litepager to calculate the $pager_total and $pager_page_array in the pre_render() method instead of the post_execute() method since the latter method is not called on views having query cache enabled. Also, since the "Page 0" problem results from $pager_page_array[$pager_id] having a value of -1, a check for this was added that calls the set_current_page() method in order to restore $pager_page_array to what it should be set to. This patch was made for views_litepager-7.x-3.0, but I believe it works with the dev version as well.

Patch looks good but also we need to set the current page if we have hit the last page.

Tested and verified the patch in #20.

I also tested the patch in #20. Seems to be working fine. I am using Views cache, time based, and it wasn't working before the patch and it is now, so thanks for that.

#19/#20 fixes the issue for me: running a couple of view blocks with litepagers in the same page, Ajax and views content cache enabled on both. Thx @berndlosert & @ShaxA!

Used #20. Works like a charm. Thanks!

Used #20, too!

@Maintainer: Would you be so nice to create a new release containing #20?

Otherwise I'd offer my help as co-maintainer to create one.

I think you might find this is a long-standing issue in core:

#2547833: Pager.inc -- add tests, clean it up, convert to a service, use it!