Pager disappears when Global: PHP used in Views 3.8

Thanks!

I was about to jump over the bridge :)

#1 Patch works well for me.

thank you, thank you, thank you.
I finally tracked the issue down to this module. Your pager saved me a good deal of time.

#1 Works for me.
Thanks!

Corrected patch so it works with drush.make files. Patches should be made from within the module folder.

Can confirm #1 is working.
Thank you so much for this!

Confirm that #1 works for me.

Thank you.

Many thanks to @dgroene for that patch #1 - works like a charm!

Can't thank you enough! #1 sorted me too.

This seems to work for the "paged output" options but does not seem to work for the "Display a specified number of items" option.

This needs to be fixed in 7.x-1.x also

Hello, I have a problem.
apply the patch, the pager does appear, but now, the content of the view don't appears, my view is a search api.

mi views is version = "7.x-3.7+27-dev"

mi views_php is version = "7.x-2.x-dev"

#6 fixed it for me. Thank you!

Confirmed. #6 worked for me as well.

#6 works great, thanks dgroene

This fix works with 7.x-1.x-dev aswell, but in one of the views I got a php error about $query not being an object, fixed it like this:

    if(is_object($query))
        $query->range(0,666666);

#1 and #6 work for me. Thank you very much.
I've had some issue to apply patch via Netbeans, so I've manually applied and it works like a charm.

#6 worked for me. Thank you very much.

#6 worked for me

Thanks. #6 worked. =)

#6 worked for me. Thank you very much.

I think this can safely be set to RTBC. I've been using this patch for a month now without any problems and would like to make sure that it's included in any new releases.

Patch in #6 did not work in my case. Disabling views_php makes the pager come back, but re-enabling it makes it disappear again. Applying this patch did nothing.

After further review, I was correct, this patch does nothing in my case. The correct patch for this issue can be found here:

https://www.drupal.org/node/2123315#comment-8193007
https://www.drupal.org/files/issues/2123315-Views-PHP-Search-API-Paging_...

After applying the Search API patch, it fixes the pager disappearing act. Perhaps someone who uses the & fix can try the Search API patch and see if it works. If it does, then it's probably best to have 1 patch that rules them all rather than one that is hit-n-miss. It should also be noted that this issue's patch will not show more than 666666 results for obvious reasons which was an issue on my end as I had over 12 million results (its a log view)

#6 works here. Hack-city, however.

#6 works form me too.

@crystaldawn in #27: I am not using the Search API module. Either one of the two patches worked for me. But not both together: then I get all results plus superfluous pager links at the bottom of the view.

I am not sure which is the best one. The patch as #6 in this issue sets an arbitrary limit of 666666 to the query results, which did not work in your case. Curious: do not you run out-of-memory when querying for 12 million results? And which version of the Search API module are you using? There is a recent patch in that module that is related:
https://www.drupal.org/node/2146435#comment-8889247

If you apply that one and the fix in this issues #6, does it work? See the earlier analysis by timkang in https://www.drupal.org/node/2146435#comment-8271297 and his comment on the patch that worked for you at https://www.drupal.org/node/2123315#comment-8273499

#6 works fine.

@crystaldawn: you changed the status away from 'Reviewed & tested by the community'. Could you at least check if #6 is working when you bring your Search API module up-to-date with this patch: https://www.drupal.org/node/2146435#comment-8889247

#1/#6 worked for me with views_php 7.x-1.0-alpha1 as well.

I applied the patch from #1 back in the beginning of June and that worked fine to get my pagers back (thanks!) however since then my pages have been inconsistent as to which subset of data they load.

For example, this is my current authenticated user experience:

• If I click on 'Next', I'm taken to '/?page=1' and instead of getting the next X number of results, I get the first X number of results again.
• Clicking on 'Next' again leaves me at the '/?page=1' URL and then loads the correct next X number of results.
• Clicking on 'Next' again takes me to '/?page=2', but I'm back to the first X results.
• Clicking on 'Next' again takes me BACK to '/?page=1' instead of the expected '/?page=3', but also loads the correct second set of X results.
• Clicking on 'Next' again finally takes me to '/?page=3' with the correct third set of X results

Those results are from one authenticated user's experience. I just tested two others that worked seemingly flawlessly. The biggest issue is that it's inconsistent and the only thing I know for sure is that this started when I applied the patch from #1 to get the pagers back.

Anyone else experience anything like this?

#6 worked for me with views_php 7.x-1.0-alpha1
#1 not tested

Thanks!

I applied the patch in #6 to the current dev version and it worked for me.

Not only did it repair the pager on my broken views, it also solved another bug, when I couldn't limit the result to a certain number and use an offset on a view with a views_php field. Unlimited entries with an offeset would work, but not say a limit of 10 and an offset of 3. This patch solves this issue as well.

#6 worked for me also.

But that appears to be a just a hack...when will a non-hack/real fix solution be done?

Can confirm #6 worked for me.

#6 worked for me. Thanks!

#6 worked for me with views_php 7.x-1.0-alpha1
Thank you!

#1Patch works well for me.
Thank you!

#1Patch works well for me.
Thank you!

#6 worked. Thanks

#6 worked for me.

#1Patch worked for me. Thanks!!

#6 worked for me.

I didn't try #6, but a cursory glance at it did strike me as hacky. As @Jan-E commented in #30, https://www.drupal.org/node/2123315 has a similar issue and patch so I rerolled that one at https://www.drupal.org/node/2123315#comment-9085183 and now my pager shows up.

#6 worked for me
thanks !

This looks like more of a bug in views. This patch is required in order to keep views_php working with it.

Marking this as RTBC as the module maintainer needs to either add this or find a new way of working with views.

Marking this as critical as IMO the module does not work if it's damaging views' pager.

The patch in #6 really appears to be somehow hacky, especially with that 'deviled' hardcoded "666666" :)
As mentioned by @PapaGrande in #48, the patch here: https://www.drupal.org/node/2123315#comment-9085183 worked very well in my situation.

I have multiple views that use Global:PHP, one of which displays lots of values for which the pager was broken. Another of these displays uses a limit to only show the first two results. When I used the patch in #6, it fixed the pager problem on the first page, but removed the limit from the second (showing all results). So, it worked in specific scenarios, but broke other parts of my site.

As previously mentioned by both @yugi and @PapaGrande, the patch from https://www.drupal.org/node/2123315#comment-9085183 worked for my situation without breaking things.

However, I'm also having difficulty with sorting. Since the update to the new views, my PHP sorting doesn't work across pages. It only seems to work on the contents of each page. For example, things that should be on the first page show up on the second or third, but everything on the first page is ordered correctly. I generally think this is a related issue, but can't figure out why.

My previous statement was a little misleading. I was trying to combine the two patches and the combination was what was causing problems. The patch here works on it's own for my circumstance (and fixes my problem with sorting!). The other patch also works on it's own (without fixing sorting), but when combined it breaks some views. I have a combined fix that I posted to the other thread.

Thanks for the fix!

hopefully not muddying the waters too much with this; and maybe it should be a separate issue... but i think what you have for code in the PHP field also impacts whether the pager appears or not.

I have a php field which calls a coded function. this is fine. if, in that function i call something like views_get_view_results(), even though my PHP field displays the correct value; the page does not show.

i have tested this with all the patches listed here as well as the patch from #2123315: Pager does not appear if fields use Views PHP (7.x-1.x) and also with version combinations of views_php and views going back numerous versions of both and this is an issue with all of the (amazed i have not stumbled upon this until now).

my guess is that call a view within the php field is the issue; but might explain some of the inconsistency people are seeing here.

.. but.. i found that changing the pager id for my pager fixed my issue with the old versions of the 2 modules that i had in place OR with the latest rel of each and the patch here: https://www.drupal.org/node/2123315#comment-9085183

#6 worked for me. Thank you so much Mr.pmchristensen .

#6 solved the issue it works like charm.

The patch here is hacky, the real fix is over at #2123315: Pager does not appear if fields use Views PHP (7.x-1.x).

thanks buddy.

#1 worked for me. Thank you.

#1 Worked for me. Thank you.

Number of users here referenced https://www.drupal.org/node/2123315, however I had this issue on a website that didn't use Search API at all. So #6 worked for me just fine.

The patch #6, worked for me.

Patch on #6 works for me too. Please, commit this patch ASAP, it saved my life!

@MustangGB I don't use search API and this patch solved the bug. This issue has a patch, the other hasn't. Why this can't be commited while there isn't a working patch on the other one?

Thanks!

@rcodina There is a patch over there and it has nothing to do with Search API, that is just what the guy was doing when he found the issue, 2123315 #26 is the patch that solved the pager issue for me and I'd be interested to know if it works for you also: #2123315-26: Pager does not appear if fields use Views PHP (7.x-1.x)

At first glance, the patch in #6 appeared to work. However:
- It will not work when there are more than 666666 results.
- In my view, I have a "Global: PHP" field, which, after applying the patch, gets called for every result, including those that are not displayed on the current page. Considering I have thousands of results, this behavior is not acceptable performance-wise.

The patch in #2123315-26: Pager does not appear if fields use Views PHP (7.x-1.x) seems to work better.

EDIT: the patch in #2123315-26: Pager does not appear if fields use Views PHP (7.x-1.x) does not actually work properly. See my comment in #2123315-42: Pager does not appear if fields use Views PHP (7.x-1.x)

#1 worked for me too. Thanks @dgroene!

Any chance of a proper fix to this bug? It was first flagged up 5 months ago and we still only have a patch. I am not using Search API but all my pagers have disappeared since the upgrade to views-7.x-3.8.

#6 works form me too. Thanks a lot!!!!!

In my previous comment, I was complaining about the fact that with the patch in #26, "Global: PHP" fields get called for every result, even those that are not displayed on the current page. It seems it was the normal behavior with views 3.7, so I shouldn't really complain about it.

please commit this fix

#6 works form me too.

Yep #6 just saved me. Thanks a bunch

#6 works form me. Thanks a bunch

#6 works here. Thanks.

I think what @MustangGB says in #66 is correct i.e. patch at #6 is workaround instead of that the fix at https://www.drupal.org/comment/9085183#comment-9085183 fixes both issues.

Thanks! Patch #6 also worked for me.

#6 works form me, thank's!

#6 works fine for me,thanks a lot.

#6 works fine for me,thanks a lot.

#1 and #6 is not the right way to fix that.

https://www.drupal.org/comment/9085183#comment-9085183 - the second condition (!isset) is wrong! Don't use it!

https://www.drupal.org/node/2123315#comment-9460235 is correct one and solves all current and future issues with pager in this case.

Confirm that patch from #6 solves the problem for me at now. Patch from #2123315 is more complex, I will test and review it.

#6 works well for me. Patch from #2123315 doesn't work for subsequent pages (if you click on page 2, it returns no records at all and the pager disappears). This is supported by @Murz https://www.drupal.org/node/2123315#comment-9503897

Can you try patch posted here

Vikramy, I can confirm that as per your comment #85 ( https://www.drupal.org/node/2123315#comment-9549759 ) that removing content of the function "post_execute" solves this issue for me using views_php 7.x-1.0-alpha1

#6 works for me. Tested also with Views Infinite Scroll.

If you want to avoid the patch in order to get your code out of Views PHP (so it can be tracked, versioned, easier to debug, et al), you can use Views' pre-render hook. That worked for me since I wanted pagination but also am part of a complex enough ecosystem of developers that anything I can version control, must be. Hope this helps someone!
Marc

I have faced same issue after upgraded views from version 3.7 to version 3.10.
#6 work for me.

I have faced same issue after upgraded views from version 3.7 to version 3.10.
#6 work for me.

Thanks

(deprecated)

(deprecated)

(deprecated)

(deprecated)

Please refer to https://www.drupal.org/node/2123315#comment-9650151
The concept of patches in this post (started from #1, til the end) is not correct, the above link shows the correct one.

@peterlolty Always provide a patch, not just a zip file.

Patch on #6 works for many people so I show it again.

@peterlolty Could you explain in this issue why do you consider this is a duplicate?

@rcodina
patch#6 is just a workaround because it overrides the query, and force the query function always retrieve up to 666666 records for each query.
Let me explain why,

The 'views_php' using 'wrapper' to wrap the 'views' pager function, it contains two part of code when wrapping the pager function.
1. wrap the pre_query() and post_query() to let the 'PHP filter' code execute.
2. emulate pager function in post_query().

Unfortunately, the pager function in views_php is not necessary started from views_7.x-3.8.
In simple words, the pager function in views_php is duplicated with views_7.x-3.8 (or later) and leads the following problem:
1. breaks the pager function (because both pager function in views and views_php will run one followed by one.)
2. other modules deal with the query and/or results cannot works with views_php properly. (because the query results has been trim off by the views_php pager function.)

Thus, that's why I marked this topic is duplicated and hide the patch#6

In addition, patch#6 breaks the views_navigation.

@peterlolty Ok, thanks for this explanation.

Hi I do not understand why you closed this thread, and why a file is a solution instead of a patch, is any patch committed that fixes this issue? because it seems that anything has been committed yet so I open again this thread

The problems came from the same reason stated in the other post. Thus, this is duplicated.

patch#6 is just a workaround because it overrides the query, and force the query function always retrieve up to 666666 records for each query.
Let me explain why,

The 'views_php' using 'wrapper' to wrap the 'views' pager function, it contains two part of code when wrapping the pager function.
1. wrap the pre_query() and post_query() to let the 'PHP filter' code execute.
2. emulate pager function in post_query().

Unfortunately, the pager function in views_php is not necessary started from views_7.x-3.8.
In simple words, the pager function in views_php is duplicated with views_7.x-3.8 (or later) and leads the following problem:
1. breaks the pager function (because both pager function in views and views_php will run one followed by one.)
2. other modules deal with the query and/or results cannot works with views_php properly. (because the query results has been trim off by the views_php pager function.)

Thus, that's why I marked this topic is duplicated and hide the patch#6

#102

I did spend several hours to solve this issues (in both posts), and I knew it is hard to understand. I suggest you going to #2123315: Paging vs. Value Field when Integrating with Search API and download patch #69.

#104 is correct. I noted the same issue in #27 about a year ago. The patch in #6 should never be accepted as "the fix" since its extremely hackish and restrictive. The patches in issue #2123315 make far more sense as they do not suffer from limitations.

#1 works for me.

#1 Works for me.
Thanks!

Just if it would help someone, since I have been working this, the last few day.

#6, or #1 were not acceptable for our site, since the "limit 666666" generates in our case, slow queries (>3 sec) with large results sets, (in some cases > 100 k), and the reason I started looking into this was to trace slow queries, that were bogging our SQL server down. It should though also be noted, that if you use those patches, you can comment out the line

$this->wrapped->execute_count_query($count_query);

from execute_count_query(), since the lines

    $this->wrapped->total_items = count($this->wrapped->view->result);
    $this->wrapped->update_page_info();

gets the same results. The patch https://www.drupal.org/files/issues/views_php-paging-2123315-86.patch worked better, query wise, but then you need also the count query, that are also slow for any slow query.

Since we do not use standard pagers on our site, only the pagers from the modules "infinit scroll" and "load more", to get the minimum of heavy queries, my version of view_php_plugin_pager.inc, now runs like this:

<?php

/**
 * A (fake) pager plugin that wraps around the actual pager.
 *
 * @ingroup views_pager_plugins
 */
class views_php_plugin_pager extends views_php_plugin_wrapper  {

  /**
   * Perform any needed actions just prior to the query executing.
   */
  public function pre_execute(&$query) { 
    $this->wrapped->pre_execute($query);

    foreach (array(/*'argument',*/ 'field', 'filter', 'sort', /*'relationship'*/) as $type) {
      foreach ($this->wrapped->view->$type as $id => $handler) {
        if (is_callable(array($handler, 'php_pre_execute'))) {
          $handler->php_pre_execute();
        }
      }
    }
	$this->wrapped->view->query->set_limit(0);
    $this->wrapped->view->query->set_offset(0);

  }

  /**
   * Perform any needed actions just after the query executing.
   */
  public function post_execute(&$result) {
    foreach (array(/*'argument',*/ 'field', 'filter', 'sort', /*'relationship'*/) as $type) {
      foreach ($this->wrapped->view->$type as $id => $handler) {
        if (is_callable(array($handler, 'php_post_execute'))) {
          $handler->php_post_execute();
        }
      }
    }

    if(count($this->wrapped->view->result)< $this->wrapped->get_items_per_page()) {
      $this->wrapped->total_items=count($this->wrapped->view->result);
      $this->update_page_info();
      $is_last = 1;   
    }
    $this->wrapped->post_execute($result);
    
    //total_items less than items_per_page sets current_page=0, but we set current page to -1 to prevent the evaluation in 
    // function views_load_more_views_ajax_data_alter() to be true and prevent that function to alter the ajax $command array. 
    if(isset($is_last)){
      view::set_current_page(-1);
    }

  }


  /**
   * Execute the count query, which will be done just prior to the query
   * itself being executed.
   */
  function execute_count_query(&$count_query) {
    //Hack: stopping  (the slow) count queries since we are not using full pager and do not need to know the correct count. 
    //$this->wrapped->execute_count_query($count_query);

    //Instead we set the pager to fixed large number, and reset the pager to -1 in post_execute if the last page
    $this->total_items = 30000;
    $this->update_page_info();
    return $this->total_items;
  }
}

I.e. telling the pager that it has a large number of pages, but effectively removing the pager, when the query result items are less than "items per page".

Hi all,

Check out https://www.drupal.org/node/2484407

The patches here all made my server hit 100% CPU immediately. The issue I posted here seems to have resolved this issue.

Has anyone tried the patch I posted at https://www.drupal.org/node/2484407 with 7,x-1.x? I'm on 7.x-2.x and the patches in this thread did not work for me on 7.x-2.x. It has been suggested that I repost my patch here but I'm hesitant to post anything that I've not tested on this branch.

Applying the patch referenced in #48 fixed my problem, and addressed the performance/hackyness issues of the patches in #1 and #6.

I'm with mummybot: applying the patch referenced in #48 also fixed my problem.

Also confirm that #48 resolved missing pager issue (#48 points to patch in #26 of related issue)

Thanks #1 worked for me.

Why would you use the bodge hackaround in #1 as the first thing you found instead of using a real fix as is being worked on over in #2123315: Pager does not appear if fields use Views PHP (7.x-1.x)?

#1 Worked for me.
Thanks!

MustangGB

Thanks for sharing the link. You're right! The solutions here can work probably in small projects.

I used #69 in #2123315: Pager does not appear if fields use Views PHP and it is working great!

Thanks.. saved my time...

Arbitrarily limiting the results to the first 666,666 starts to become a massive performance issue, especially if you're dealing with pagination on a Drupal Commerce BackOffice Orders view with over 5,000 orders. Fatal PHP memory errors start to happen.

https://www.drupal.org/node/1937364#comment-8223543 fixed it for me!

#1 worked for me too

It worked for me
Thank you very much

#1 work for me . thanks