Pager does not appear if fields use Views PHP (7.x-1.x)

Hi lalweil

Thank you for your continued efforts working on this issue.

When trying to apply the patch i receive the following error:
patch: **** malformed patch at line 18:

I did however just apply the patch manually to give it a go.

For me, it did make the pager appear again, however when i click on the link to page 2 it returns no results found. i experimented with decreasing the number of items per page on the view settings and this resulted in every page other than page 1 of the results from the pager still returning no results

Patch applied properly and has restored a working pager on my views when a view_php field is enabled

Thank you for the great work!

My pagers worked with Views PHP before updating to Search API 7.x-1.9. After updating, the pager block disappeared. I applied the patch in #52123315-Views-PHP-Search-API-Paging.patch, and it solved the pager problem for me. Thank-you!

Woo! This one threw me for a loop. I investigated possible issues with practically every other module involved before realizing it was the presence of the php field causing the pager to disappear. I can confirm the patch in #5 fixed the issue for me. Thanks!

On my case it's working also, But other normal views with Display a specified number of items on PAGER setting, it's show all results :(

I believe this issue was caused solely by Search API, and should be resolved with the recently committed patch for #2146435: Fix Views paging with custom pager add-ons. My comment there (#11) tries to explain a bit on how I believe Search API and Views PHP are supposed to fit together.

On lalweil's patch:
I believe Views PHP is working as designed. views_php_plugin_pager::post_execute() cannot simply leave $this->wrapped->total_items as-is, since custom PHP views filters can filter out and reduce the number of total results. $this->wrapped->view->result can't be left as-is; since the query limit and offset are removed in views_php_plugin_pager::pre_execute(), it contains all of the results, and not just those on a specific page (johntang's issue above in #9). My comment linked above explains why.

Yes, It should be fixed caused by Search API module, I have tested #10 patch. No have changes from PHP Field module.

I'm not sure this is working correctly. Since applying the patch, when I create a custom Views PHP field, the $row data is now null. This wasn't occurring before the patch and nothing has changed in my view to make this no longer work.

@welly

Did you reverted views_php_plugin_pager.inc before try this patch?

Good question, @johntang. I suspect I didn't but I will try again. I'll re-download the module and add the patch again.

Hello there,

I'd like to put my two cents here and say that patch in #5 worked for me AND I'm not using Search API.

I have many other views in my app that are more complicated (with Infinite Scroll or Load More Pager, Geofields and IPGV&M, etc.) and they are working well with Views PHP.

But in a very simple unformatted list to display three fields and 18 itens per page limit, it didn't.

Thanks for the patch!

My experience is the same as #16.

I'm not using Search API, but adding Views PHP fields to a couple of views caused the pager to disappear. And the number of results returned (as shown in Header: Global: Result summary) was limited to whatever number I set in the pager's "items per page" field.

Applying the patch in #5 fixed the problem. No side effects that I can see.

Is there a reason it can't be committed? I see the project is marked "maintenance fixes only" but wouldn't this qualify?

Same as #16 and #17.
#5 works well.

I am using Search API, but was experiencing the problem when it was disabled and on views not interacting with it. The #5 patch fixed it perfectly and easily. This is certainly a bug in the Views PHP module.

Very Annoying Bug pager in views simply dissappared after i added php field

#5 patch fixed it.

Please commit

#5 solved my issue, happily.

@cpm5280; could you try if the combination of these two patches also works:
https://www.drupal.org/node/2276165#comment-8835945
https://www.drupal.org/node/2146435#comment-8889247

Patch #5 works for me even without using search api to get my pager back.

However, can somebody explain the second correction? If $this->wrapped->view->result is not set, how can it be an array to be sliced?

if (!isset($this->wrapped->view->result)) {
  $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
}

Also the patch should be relative to the module path. I can upload it correct once somebody answers the previous question.

Patch #5 fixed my pager, and I do not use Search API.

I confirmed that #5 fixes my missing pager, but I rerolled and renamed the patch to conform with Drupal standards in that I made the module directory the base and removed the permissions change.

Doh! And now this time I really did remove the permissions change.

The patch in #26 worked for me. How about that for timing! Thanks PapaGrande!

When will the patch in #26 be released? I'm seeing a problem with the views pager not showing up with fields that use Views PHP, and the patch fixed that problem.

I'm not using Search API, but my pager disappeared when using Views PHP fields, #26 solved it on 7.x-1.0-alpha1.

The patch in #26 worked for me, I am not using Search API as well, but the pager disappeared after adding a Views PHP filter.

The code that #23 asks about doesn't do anything and so the patch in #26 can't leave views_php working as intended. You can't have code that uses $this->wrapped->view->result as an array after checking that $this->wrapped->view->result is not set so I don't think this can RTBC.

As I understand it views_php is attempting to fix pagination in case views_php has been used in the filtering and thus the results from the database aren't fully filtered until views_php has done it's thing. Perhaps views_php can set a flag as to whether it's doing any filtering and needs to sort out the results otherwise just use the already set values as the patch in #26 does.

So the questionable code would become something like:

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

    $item_per_page = $this->wrapped->get_items_per_page();
    if ($item_per_page > 0) {
      $offset = $this->wrapped->get_current_page() * $item_per_page + $this->wrapped->get_offset();
      $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
    }
}

Where $this->wrapped->view->view_php_filter is the flag set by views_php if there is filtering done by views_php.

One piece of information I can bring to the table is that I just came across this issue while updating a site that hadn't been updated since some time in 2012.

After updating views from 7.x-3.5 to 7.x-3.8 this issue started happening, views_php hasn't been updated so is still the same code from back in 2012 but the site didn't suffer from this issue before updating views.

So the code that is being fixed with the patch in this issue didn't affect the pagination with views 7.x-3.5, unfortunately I currently don't have the spare time to try and figure out what's changed in views to cause this code to break pagination but thought I'd add the information in case someone else can figure it out and provide a better fix.

I just commented out the second correction mentioned in #23 and the code still seems to work fine. Maybe it's just not needed. Otherwise, this patch works great for me.

Also, I'm curious if the change in views that causes this problem is also related to 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 according to my sort values. I generally think this is a related issue, but can't figure out why.

The solution to my sorting problem seems to have been addressed on this page: https://www.drupal.org/node/2276165

I'm using this combined and modified version of the patch in #26 and the one above. This partly addresses @Jan-E 's question in #22.

Since I don't use Search-API I'm curious if this also solves the problem for that.

The patch in #26 seems to work.

The patch in #33, however, has the same problems as the patch in #2276165-6: Pager disappears when Global: PHP used in Views 3.8:
- It will not work when there are more than 999999 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.

@Samfall (#32), the second correction is necessary in my case: if I don't apply it, the first page works, but all the other pages are empty. Also, I don't notice anything wrong with sorting after applying the patch in #26.

I have to admit, though, I don't understand how the second correction

-      $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
+      if (!isset($this->wrapped->view->result)) {
+        $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
+      }

is any different from just removing the following line:

      $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);

If the condition (!isset($this->wrapped->view->result) is ever true, the only thing it will do is generate a warning: Warning: array_slice() expects parameter 1 to be array, null given in ...
And I don't think it will ever be true: when there are no elements, $this->wrapped->view->result is an empty array.

In fact, you could even remove the 5 following lines, and it would do the same thing:

    $item_per_page = $this->wrapped->get_items_per_page();
    if ($item_per_page > 0) {
      $offset = $this->wrapped->get_current_page() * $item_per_page + $this->wrapped->get_offset();
      $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
    }

I can not get the patch in #26 or #33 to work. We are running Views PHP 1.x-dev as well as Search API 1.13 and when I apply the patch in #26/#33, I get a "502 bad gateway" error.

The host (Pantheon) is not willing to change the nginx.conf file settings so I am not sure what the issue is, since no one else is reporting an error like that. We know that the issue is related to Views PHP because if we remove all PHP fields from the View, the pager returns. Even tried Views Lite Pager and that shows something but the pager is non functional.

Has anyone else experienced the 502 bad gateway error? Is that a permissions/memory thing or something else entirely? I'm assuming that the patch (probably) works but I can't confirm one way or the other. We have ~30,000 records . Any feedback/thoughts would be appreciated.

lalweil: Thanks for the tips and link, but I unfortunately tried that already. The patch in #10 was already committed to the version of Search API I have so it really had no effect. I'm getting one of our other devs to try to patch it on his local copy to see if its the host or just us but would still appreciate hearing from anyone else who might not be able to get the patch to work.

I can confirm that #26 does NOT work for us. The pager simply returns "0" in combination with views_litepager.module.

As I found out in my case "$this->wrapped->total_items" is zero so the "!isset()" is never triggered for us.

PS: The NORMAL (full) pager works fine, but my edge case shows that the result needs work, because it creates a different behaviour than expected!

Unfortunately, there is a problem with patch #26: the pager is applied BEFORE any "Global: PHP" conditions listed under "Filter Criteria".

For example, if you have a view with a working pager with, say, 10 items per page, and you add a simple "Global: PHP" condition under "Filter Criteria" such as return rand()%2;, you will notice that your pages do not have 10 items anymore, but only 5, on average.

Because the "views" Module changed since 7.x-3.8.

In the "views" Module, the "views_plugin_query_default" Class replaced the query->range($offset,$limt) from the "execute()" Method to the "result()" Method.
So, In the "views_php" Module, I suppose that the logic in the "post_execute()" Method can be removed.

And I wrote the following patch.

G.I. Joe,

Your patch came through as a garbled mess (with time stamps and some other junk in there). Could you repost please?

Thanks!

#26 also worked for me. Many thanks!

#26 caused the pager to reappear when I'm using a Global PHP to filter results, but like #42, I have an issue.

My PHP filter throws out all values below a certain distance threshold so if no items are to be shown, none are returned from the view, but the pager acts like they are all they and shows all the pages that would be there if the filter were removed.

The patch submitted in 26 solves some problems, but is incorrect, the second condition (!isset) is wrong... must be true when isset.

Hi everyone,

I also experienced this same issue with the pager going missing, but, there is a more pressing issue for me. The problem is, views php "breaks" when search API has a large index (in my case over 100k nodes).

Took me forever to track this down, but essentially, something about just the php-field's presence in the view, slows down my search API view to the point that php times out. In my example, I literally added no php code, and the view load speed all the sudden quadruples or more just by adding a views php field.

What I think is likely happening, is somewhere in the views php, there has got to be some piece of code that is either trying to do some insane parsing on an array/object from the indexed node(s) that greatly slows down the search API view, or it's executing some php code x 100k times. I can't figure out where/why though.

Anyone have any clue why this would occur? As I was saying, this happens even if I put no php code into the field.

Thanks!

Hey All,

I think I found the problem, $this->wrapped->view->query->set_limit(0); inside pre_execute() is problematic for search API and any view with a lot of results. Fixing this would improve this modules performance substantially across the board whenever there is a pager, but particularly with large data sets.

There has got to be some way to not have to query all the results to get the pager info? Seems like other views modules had to of fixed this same problem, might be worth looking at how other modules do it?

Patch from #47 shows pager back, but when I go to second page in pager, I see empty results. First page shows results normally.

But patch views_php-pager_missing-2276165-2.patch from #2276165 works well without problems.

I have the same problem as Murz with the Patch from #47. My pager is back, first page shows results normally. I can adjust the number of items to show and the number of pages change. But going to any other page returns empty results message.

Can you please try this patch?

Also I think logic in "post_execute()" method can be removed.

Removing Logic in post_execute() method works for me. Thanks G.I.Joe

I tested #53 patch. It works.

If any patch can remove codes and not add codes and if it works, this patch should win a gold metal.

I applied patch #53 but I still have the same issue described in post #51. The pager shows up but any page other than page one doesn't have any content.

Is this patch only for version 1.x-dev

Cheers Dan

(deprecated)

(deprecated)

(deprecated)

(deprecated)

I have the same problem when I upgrade the views from 7.x-3.7 to 7.x-3.8, but I didn't use Search API.

#53 is half correct, it shouldn't remove the "for(){php_execute();}" part, that's the views_php wrapped to execute the php code.
Finally, Finally , Finally , I made a solution for all (four) use-case.

1. set 'Items to display' and set 'offset' (1 and 1)
2. not set 'Items to display' and set 'offset' (0 and 1)
3. set 'Items to display' and not set 'offset' (1 and 0)
4. not set 'Items to display' and not set 'offset' (0 and 0)

All four use-case should work properly in "Full shown", "specific number of item", "full pager" and "mini pager".

I uploaded the whole /plugins/views/views_php_plugin_pager.inc (7.x-1.0-alpha1) file.
Please feel free to test and review it, or help me to make a (git) patch and share here.
Please use the views_php_plugin_pager.inc_7.x-1.0-alpha1_fix_update3.zip and ignore my previous (deprecated) comments.

@peterlolty Please, provide a patch not just a zipped file to help module mantainer and others to see which are the changed lines. Check out this:

https://www.drupal.org/node/707484

@peterlolty patch #63 doesn't work correctly with PHP filters. Add a filter

return rand() % 2;

and the page doesn't show 10 items. Able to goto Next page

@jncruces patch #47 clicking to goto next page shows no results.

@vikramy patch #53 PHP filters don't work.

@grom358 which version of "Views" did you used?

sorry about the zip file not git patch,,, please someone help me to make the patch.

@@ -9,9 +9,9 @@

  /**
   * Perform any needed actions just prior to the query executing.
   */
-  public function pre_execute($query) {
+  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) {
@@ -36,16 +36,16 @@
        }
      }
    }

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

    $item_per_page = $this->wrapped->get_items_per_page();
    if ($item_per_page > 0) {
      $offset = $this->wrapped->get_current_page() * $item_per_page + $this->wrapped->get_offset();
      $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
-    }
+    } */
    $this->wrapped->post_execute($result);
  }

https://www.diffchecker.com/dpj9gs3b

@peterlolty To do a patch, just do this:

1) Make sure you have git installed on your pc/mac

2) Go to "Views PHP" main page: https://www.drupal.org/project/views_php

3) Go to "Version control" green tab

4) Copy "git clone" instruction. If necessary, change "7.x-1.x" for "7.x-2.x" depending on what branch you want to patch.

git clone --branch 7.x-1.x http://git.drupal.org/project/views_php.git

5) Once project is cloned, do your changes to module. Make sure not to delete hidden .git files

6) Once done, open console, go to projects root, and do:

git diff > NAME_OF_PATCH.patch

Note: To get a correct name for patch: in this issue, click on "Files" in the bottom then click on button "Patchname suggestion". Copy the suggestion.

Remember, if you google it, you have this information and even more about other topics just in drupal.org. Thanks for your contribution!.

@rcodina Thanks for your impressive comment.

@peterlolty Thanks for the patch!

#69 working for me.

#69 works for me too, thanks!

Fixed the issue for me too

pager showed with the #69 patch but didn't work as expected.

we have total 10 nodes.
we have php filter criteria that returns true or false
we want to show 1 node per page
pager shows 10 page but it should 9 because one node return false with the php filter
every page we saw one node but one page we didnt saw a node only blank page with only pager.

is there any patch for this?

#74Would you mind explain more about your use case? so I may investegate in deep, thanks

#69 patch works for me.

@umuthan

pager showed with the #69 patch but didn't work as expected.

we have total 10 nodes.
we have php filter criteria that returns true or false
we want to show 1 node per page
pager shows 10 page but it should 9 because one node return false with the php filter
every page we saw one node but one page we didnt saw a node only blank page with only pager.

is there any patch for this?

Correct me If I'm wrong but your problem isn't related with views php or any patch, you just have to change your views pager settings: While editing a view, check out pager settings in the bottom of central column of your views settings page. Then open pager settings option and select your desired "Items per page" value. Just delete your views php filters.

@peterlolty I think your patch is fine. Given all good reviews I mark it as RTBTC.

@peterlolty I found a bug with your patch: In a search api view where I have only a "fulltext search" exposed filter, in cases where filter is empty the paginator doesn't appear and all results are rendered.

@rcodina - instead it should not show any results, as you haven't searched yet, right?

@DrCord Yes, this is an option. The other valid option is that all results are shown but with view's pager. The chosen option may vary depending on customer needs.

#69 fixed the issue.

Still NW as per #79.

Let me check!

#69 doesn't work for me. I'm a little late to this thread but here is my situation.

I have a page that is outputting a View which is a list of nodes (full content display). This View should only display the first 2 items and then paginate (pagination handled by "Views Infinite Scroll" module). However it's not working.

Within the nodes that are being displayed in the View, there is a field generated by the "Viewfield" module which is generating a list of bookings in a separate View, and it's within this View that Views PHP is being used to alter data. I know for sure that Views PHP is the culprit because if I try disabling it, the infinite scroll pagination works.

NOT sure if the #86 patch is correct or not, need tester to give feedback.

I tried patch #86 and it did not work, but patch #69 did the trick.

Neither patch #69 nor #86 work for me.

Here is a new patch, which combines #69 with an automated test to confirm that it works. (The patch at 86 is not working, I have hidden it.)

A few more notes:

* I have changed the title, as this does not seem to have anything to do with Search API
* If you use the test in 90, but remove the changes to the plugins/views/views_php_plugin_pager.inc, the test will fail.

Here is the correct version.

I'm trying this patch on views-php-7.x-2.x-dev and views-7.x-3.11. No pager at all.

Does there exist a version that works on 7.x-2.x-dev?

@bkat this patch is for 7.x-1.x-dev

@alberto56 that's why I'm asking if anyone has fixed this issue on 7.x-2.x-dev. There are a couple of other issues marked for that release but they all point back to this issue.

@bkat: Sorry, I did no mean to appear blunt! You mentioned that you tried this patch on 7.x-2.x-dev, but when I tried to apply it, it applies only partially.

Here is a slightly different version of the same patch. In #92, I had included the test file at the very end of the .info file, which worked on 7.x-1.x-dev, but not on release versions which contain packaging information at the end of the .info file.

In the enclosed version, I have added the reference to the test file before the other includes in the .info file, so that the patch applies whether or not there is packaging information at the end of the .info file.

In comment #10 (December 13, 2013), timkang says: "views_php_plugin_pager::post_execute() cannot simply leave $this->wrapped->total_items as-is, since custom PHP views filters can filter out and reduce the number of total results.".

However, starting with Views 7.x-3.8, released May 20, 2014, the method we were using to get the total number of row, "$this->wrapped->view->result", no longer returns the total number of rows, but rather returns the total number of rows _on the current page_.

My understanding is that views_php filtering for branch 7.x-1.x seems to be broken as of 7.x-3.8; I opened #2484077: The filter function is no longer called for rows not on current page as of Views 7.x-3.8 about that.

There is a fixed issue about filtering for branch 7.x-2.x at #1222448: Views PHP Can't Filter, but I'm not sure if it's related.

In any event, this patch probably breaks PHP filtering for views <= 3.7, but it seems that PHP filtering is broken in views >= 3.8 regardless of whether this patch is used. At least, with this patch, paging is not broken as well.

Confirming that php_views + this patch + views >= 7.x-3.8 breaks filtering, and will display more total items than php_views + 7.x-3.7. Setting to needs works.

I figured out how to get paging to work on 7.x-2.x-dev. It's basically just getting rid of the update_wrapped_pager() method in plugins/views/views_php_plugin_pager.inc

I'll create a separate issue for this.

https://www.drupal.org/node/2484407 is where I fixed this on 7.x-2,x-dev

I used the patch in#92 to patch 7.x-1.0-alpha1 and it worked to get the pager back but it failed on trying to patch the .info file.

patching file plugins/views/views_php_plugin_pager.inc
patching file views_php.info
Hunk #1 FAILED at 14.
1 out of 1 hunk FAILED -- saving rejects to file views_php.info.rej
patching file views_php.test

@andyanderso, please try the patch at #97.

Patch in #97 worked great. Sorry for me being a ding-bat and getting #92 and #97 mixed up. Thanks for the work on this.

Patch #97 work fine. Thanks

@yepa thanks. I will put this back to "needs work" for the following reason:

The patch works correctly if you don't have any fields which are removed from your view by php code. For example, if you only have PHP code to modify existing fields.

However, if you have, say, 10 nodes (nids 1 to 10), and 3 nodes per page, but you use PHP code in your view to remove all nodes with even nids (this is a hypothetical example):

* The unpatched version of views_php with views < 7.x-3.8 will work fine: 2 pages, the first with nids 1, 3, 5; the second with 7, 9.
* The unpatched version of views_php with views >= 7.x-3.8 will show only the first page: nodes 1, 3, 5, no pager.
* The patched version of views_php with views >= 7.x-3.8 does not calculate the pages correctly. There would be four page numbers in the pager, because there is no longer any way as of 7.x-3.8 of running the PHP filter code on items not on the current page; this is documented at #2484077: The filter function is no longer called for rows not on current page as of Views 7.x-3.8

I agree with alberto56, it's the common problem for several modules: sub-module(views_php) dont get maintance / update for long time, while the main module(views) have several versions of update. The design of the current views-php miss the current views. We actually need a new group of people to build a whole new design of Views-php for the latest Views

It appears that #97 is for views_php-7.x-1.0-alpha1, but I need the dev version so that another (seperate issue) patch will work.

So I tried making a patch of my own. It's attached. It works for me and my dev version of views_php. Sorry if I named it wrong, I don't understand all the numbers in the naming convesion. Also, there's no .info or .testing stuff in this patch file.

There's really only two lines I needed to change.

views_php/plugins/views/views_php-plugins-pager.inc, line #13:

    public function pre_execute(&$query) {

views_php/plugins/views/views_php-plugins-pager.inc, line #50

    //$this->update_wrapped_pager();

So clearly this is not a rear fix, it just bypasses the function that causes the pager to disappear, but this function is needed to calculate the number of pages when views_php is used to filter or sort a view. I'm justing using views_php to create some extra output in my views, so it's no skin off my rump.

Again, this is for the latest dev version. Hope this helps.

@danmantyla thanks for sharing.

I don't understand all the numbers in the naming convesion

If you submit another patch, adding the issue number from the URL (node/2123315) and adding the comment number (for example, in your case it's 108), helps people who download the patch and use it later trace it back to where they found and the discussion around it. A good name for your patch would have been views_php-pager.dev-2123315-108.patch.

@danmantyla On the files section of this page, look at the right side. There is a button "Patchname suggestion". Press it and see ;)

Can confirm that patch in #97 works to fix issue where Views Infinite Scroll 7.x-1.1 stops working when used together with Views 7.x-3.11 and Views PHP 7.x-1.0-alpha1.

@alberto56, Thanks; This fixes the issue for me.

I will just leave this here.
https://www.drupal.org/node/1016574#comment-9940241

Can someone confirm that this can be moved to close.

This is still an issue for me, and none of the patches fully work because of a change in the Views >= 7.x-3.8 api.

Patch #97 worked for me. To make it work in more scenarios I played with the Idea of checking the Views version to add one more layer of comparability. I don't know if this is something that we should be doing but it seemed to work for me and should also be compatible with Views <= 3.7.

To this I added a function to views_php_plugin_pager.

  function get_views_version() {
    static $version = null;

    if (!is_null($version)) {
      return $version;
    }

    $path = drupal_get_path('module', 'views') . '/views.info';
    $info = drupal_parse_info_file($path);

    $version_string = $info['version'];
    $version_string = str_replace('7.x-', '', $version_string);
    $version_parts = explode('-', $version_string);

    if (empty($version_parts)) {
      $version = FALSE;
      return $version;
    }

    $version_main_parts = explode('.', $version_parts[0]);
    $version = array('major' => $version_main_parts[0], 'minor' => $version_main_parts[1]);
    return $version;
  }

Then alter post_execute()

    $version = $this->get_views_version();
    if ($version['major'] == 3 && $version['minor'] <= 7) {
      $this->wrapped->total_items = count($this->wrapped->view->result);
      $this->wrapped->update_page_info();

      $item_per_page = $this->wrapped->get_items_per_page();
      if ($item_per_page > 0) {
        $offset = $this->wrapped->get_current_page() * $item_per_page + $this->wrapped->get_offset();
        $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
      }
    }

This does not solve the problem of vews_php fields that modify the number of pager records.

Patch in #97 worked great for me. Thanks.

#100 worked for me running views_php version 7.x-2.x-dev - thanks

Patch also work on 2.x version of the module. Need to be commited to all branch.

The patch in #97 doesn't work for me with Views PHP 7.x-1.0-alpha1, Views 7.x-3.11, Search API 7.x-1.16.

This is the patch from comment #108, but rerolled to Drupal issue standards. This patches the 7.x-2.x dev release dated 2015-04-21.

@wylbur Which are the differences between patches #108 and #121? Only the patch name? If not, please provide an interdiff.

Everyone who report RTBC please mention which patch (#num) you mentioned.

The patch on #121 only brings back the pager. The real problem is some of the pages are empty if the result is filtered by Views_PHP. It is like the result rows are there but not displayed.

@#124: Should we split this into separate issues or are they the same?

Patch #121 works great for me and brings back the pager correctly. I'm NOT using views_php for filtering! Just for fields.

+1 for splitting issues

-1 for splitting issues, not support splitting the problem, as we need a general correct solution to commit for fixing the bugs.

@peterlolty
I think they are separate issues, the one the pager disappears the other the page number is incorrect when using a filter.
The one problem we have a solution for and it is simple, the second the problem seem very complex and will take some time to fix.

@NaX , I see your point.
What i mean is, if we want to commit the patch, the fix should be a complete solution, not half nor a workaround. For the people who want the fix at this stage, they may consider any patches shown here which may approach their needs.

With this patch, I'm able to see the pager, with and without a PHP filter.

What was happening was the range was not being set back to zero by the lines in views_php_plugin_pager::pre_execute():

$this->wrapped->view->query->set_limit(0);
$this->wrapped->view->query->set_offset(0);

To effectively set the limit and offset back to zero, this patch resets the range using hook_views_post_build().

#130 RTBC
with PHP filter and PHP field used inside the views.
Also Views navigation works fine.

Committed. Thanks everyone for not giving up on this issue!!

@fizk and all, thanks for your hard work on this issue.

I can confirm that I am finally getting the correct Record Count (# of records found, using the functionality from the pager) using 7.x-1.x-alpha2. However, I still get the Record Count of all of the records in the view before the views_php filter that I have in my view is applied when I use 7.x-2.x-dev as of 2015-Nov-11 (datestamp = "1447293841"). Let me know if you need more details from my site.

@DarrellDuane Can you list steps on creating a new view that would reproduce this on a fresh Drupal install?

@DarrellDuane I think the main part of this bug has been fixed. Can you create a new issue for the specific part you'd like to work on? Thanks,

I'm getting fatal error for code introduced in #130 for all views. Just enabling views_php only, not used in any views yet.

PHP Fatal error:  Call to a member function range() on string in /var/www/sites/drupal/modules/contrib/views_php/views_php.module on line 157

@ckng What version of Views and PHP are you using? Also, if you can, please comment out $view->build_info['query']->range(); in views_php.module on line 157 and print out the value of $view->build_info['query'].

@fizk
The latest version fixed the pager missing issue, but it affected all other views that using " Display a specified number of items " on Pager showing all the results instead of the limited value assigned.
Views 7.x-3.11

@fizk I've created issue https://www.drupal.org/node/2613930 and added instructions about how to replicate the issue.

For my case, $view->build_info['query'] is empty.

@SiaoKiax3 Let's work on that in #2613876: Cannot display specific number of items in view

@ckng Let me know if the latest 7.x-1.x dev works for you. It should contain this patch:

https://www.drupal.org/commitlog/commit/17562/2cd1ba8e85e48deccc371e657d...

I'm still not sure why $view->build_info['query'] is empty for you.

My views is search API solr index type, so technically there are no db query.

The patch should do.

This "fix" hits performance/memory so hard.

Fatal error: Allowed memory size exhausted.

To give you some idea of memory usage and load times.

Without patch (pager doesn't work):
10 MB + 8 seconds

With patch (pager works but performance sucks):
535 MB + 15 seconds

With #1937364-1: Filter does not respect pagination, it runs through all nodes in a search (pager works? and performance is great):
10 MB + 7 seconds

In light of #150 I'm thinking we should re-visit this solution.

Thanks MustangGB, can you create a new issue to fix the performance issue?

I am using 7.x-1.0-alpha3 and tested also latest 7.x-1.x-dev but the pager still not showing when views PHP added. Any idea ? Sure this is fixed ?

Sorry, it works actually. But if I embed a view from a another view into the current Views, the current view's pager doesn't show up anymore, any idea ?

Output code:

 print views_embed_view('product', 'block',$data->nid);

I can confirm it too, in my case it doesn't work (both – when view is page and when view is block and printed with "views_embed_view").
I tried all current versions: 7.x-1.x-dev, 7.x-2.x-dev and 7.x-1.0-alpha3
I am using views 7.x-3.13

I'm using Views Field View module to embed the View at the moment.

I previously tried this patch. Pager showed but, it produced another problem as view was querying all items irrespective of pager as limit was (0,666666).
After applying #69 patch that problem is also resolved.

@abhishek.pareek actually the problem has been fixed and commit already in the latest release.

@peterlolty, actually problem in #157 is real and still exist.

All items are loaded no matter what with latest dev.
Similar issue: https://www.drupal.org/node/2618504

So far I cannot use this fix due to heavy performance impact, and had to revert to the alpha 2 release of views php 1 and apply the patch from this thread:
#1937364: Filter does not respect pagination, it runs through all nodes in a search

@grahamtk: I have the same problem, as requested by fizk I started a follow-up issue for this regression: #2628014: Pager fix causes performance and memory regression

Hi,
Leaving this here in case someone needs it. Using Elastic Search and Views PHP 7.x-1.x-dev, a combination of #69 and #108 didn't work. I mean the pager appeared, but all pages return the same first 20 results.
I also had to remove:

$this->wrapped->view->query->set_limit(0);
$this->wrapped->view->query->set_offset(0);

from views_php_plugin_pager.inc and the pager seems to work correctly now.

For anyone suffering from performance degradation - please, try this patch - #2628014-4: Pager fix causes performance and memory regression

#5 Patch works like a charm. Thank you so much. @mikemadison

This issue is appearing again for us using the latest 7.x-1.0-beta1 released on 23 February 2021

Has anyone else run into this lately?

Facing same issue on latest 7.x-1.0-alpha3 released on 12 November 2015