There has been an ongoing issue with Views PHP and Search API where the value field never, ever, returns anything to the output box when using a Search Index as the base entity for a view using a PHP Field.
Recently, a post regarding the Search API Views contributed module https://drupal.org/node/2096275 added a couple of calls into their query.inc file that will call the Views PHP pre/post execute functions:
try {
// Patching per: https://drupal.org/node/2096275
// Trigger pager pre_execute().
$this->pager->pre_execute($this->query);
$start = microtime(TRUE);
// Execute the search.
$results = $this->query->execute();
$this->search_api_results = $results;
// Store the results.
$this->pager->total_items = $view->total_rows = $results['result count'];
if (!empty($this->pager->options['offset'])) {
$this->pager->total_items -= $this->pager->options['offset'];
}
$this->pager->update_page_info();
$view->result = array();
if (!empty($results['results'])) {
$this->addResults($results['results'], $view);
}
// We shouldn't use $results['performance']['complete'] here, since
// extracting the results probably takes considerable time as well.
$view->execute_time = microtime(TRUE) - $start;
// Patching per: https://drupal.org/node/2096275
// Trigger pager post_execute().
$this->pager->post_execute($view->results);
}
this actually DOES partially resolve the issue with the value field not being connected to the output field. However, it also causes the pager to break.
When there is a view php field in the view, the pager goes away. When there is not a view php field in the view, the pager works fine. if I remove the patch above (the pre_execute and post_execute calls) then the pager immediately begins working but the value field no longer passes information onto the output box.
I've spent several hours trying to backtrace data through views php and I'm not seeing anything immediately obvious.
The biggest thing I notice is that in the $view object that is being passed around in the views_php.module file is that the $view->current_page and $view->items_per_page aren't being set properly after the post_execute function runs. I have tried manually setting this to match what is in $view->query->pager but that doesn't seem to make a difference.
Views PHP saves lives! However it's been very difficult trying to integrate more and more complex features into Search API powered views. This could well be a Search API issue, but if anyone could help me a bit to understand how Views PHP actually renders the pager with the data, that would be incredibly helpful.
Note: This may be related to: https://drupal.org/node/2024689
Thanks !
Comment | File | Size | Author |
---|---|---|---|
#130 | 2123315-fix-pager-130.patch | 408 bytes | fizk |
#69 | views_php-paging-2123315-69.patch | 1.15 KB | peterlolty |
#47 | views_php.patch | 1.07 KB | jncruces |
#43 | views_php-search_api-paging-2123315-43.patch | 2.54 KB | G.I.Joe |
#33 | views_php-search_api-paging-2123315-33.patch | 1.21 KB | Samfall |
Comments
Comment #0.0
mikemadison CreditAttribution: mikemadison commentedcorrectly wrapping php code
Comment #1
mikemadison CreditAttribution: mikemadison commentedAfter digging into this, I believe I have the reason.
In views_php/plugins/views/views_php_plugin_pager.inc ~line 40
The module is setting the total number of items to the count of the view's result. This is fine when the view isn't paged. However, if the view IS paged, the view->result object is only going to contain the number of rows specific in the 'per page' setting. So, if I have 500 items, paged with 10 items per page, my view->result is always going to be 10, no matter what page I'm on or how many items are there.
As far as I can tell,
is actually set when coming into this function from the view. So, I have tried this minor change in the code and as far as I can tell, all is well. The paging starts working again, the $value field continues to work, and all is well in the world.
Comment #2
mikemadison CreditAttribution: mikemadison commentedComment #3
Colin @ PCMarket CreditAttribution: Colin @ PCMarket commentedHi 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
Comment #4
mikemadison CreditAttribution: mikemadison commentedI am able to reproduce the problem. In digging a bit, it appears that the pager is redundantly setting the $view->result object. So, I'll apply the same logic as in the other patch to this. Basically, turning:
into:
I'll get a new patch in a moment
Comment #5
mikemadison CreditAttribution: mikemadison commentedComment #6
Colin @ PCMarket CreditAttribution: Colin @ PCMarket commentedPatch applied properly and has restored a working pager on my views when a view_php field is enabled
Thank you for the great work!
Comment #7
sassafrass CreditAttribution: sassafrass commentedMy 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!
Comment #8
gthing CreditAttribution: gthing commentedWoo! 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!
Comment #9
johntang CreditAttribution: johntang commentedOn 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 :(
Comment #10
timkang CreditAttribution: timkang commentedI 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 inviews_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.Comment #11
johntang CreditAttribution: johntang commentedYes, It should be fixed caused by Search API module, I have tested #10 patch. No have changes from PHP Field module.
Comment #12
johntang CreditAttribution: johntang commentedComment #13
welly CreditAttribution: welly commentedI'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.
Comment #14
johntang CreditAttribution: johntang commented@welly
Did you reverted views_php_plugin_pager.inc before try this patch?
Comment #15
welly CreditAttribution: welly commentedGood question, @johntang. I suspect I didn't but I will try again. I'll re-download the module and add the patch again.
Comment #16
Vuds CreditAttribution: Vuds commentedHello 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!
Comment #17
rclemings CreditAttribution: rclemings commentedMy 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?
Comment #18
szt CreditAttribution: szt commentedSame as #16 and #17.
#5 works well.
Comment #19
DrCord CreditAttribution: DrCord commentedI 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.
Comment #20
nimek CreditAttribution: nimek commentedVery Annoying Bug pager in views simply dissappared after i added php field
#5 patch fixed it.
Please commit
Comment #21
cpm5280 CreditAttribution: cpm5280 commented#5 solved my issue, happily.
Comment #22
Jan-E CreditAttribution: Jan-E commented@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
Comment #23
ñull CreditAttribution: ñull commentedPatch #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?
Also the patch should be relative to the module path. I can upload it correct once somebody answers the previous question.
Comment #24
bdombro CreditAttribution: bdombro commentedPatch #5 fixed my pager, and I do not use Search API.
Comment #25
PapaGrandeI 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.
Comment #26
PapaGrandeDoh! And now this time I really did remove the permissions change.
Comment #27
lee20 CreditAttribution: lee20 commentedThe patch in #26 worked for me. How about that for timing! Thanks PapaGrande!
Comment #28
creeksideplayers CreditAttribution: creeksideplayers commentedWhen 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.
Comment #29
MustangGB CreditAttribution: MustangGB commentedI'm not using Search API, but my pager disappeared when using Views PHP fields, #26 solved it on 7.x-1.0-alpha1.
Comment #30
yugi CreditAttribution: yugi commentedThe patch in #26 worked for me, I am not using Search API as well, but the pager disappeared after adding a Views PHP filter.
Comment #31
Altcom_Alan CreditAttribution: Altcom_Alan commentedThe 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:
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.
Comment #32
Samfall CreditAttribution: Samfall commentedI 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.
Comment #33
Samfall CreditAttribution: Samfall commentedThe 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.
Comment #34
user3077953 CreditAttribution: user3077953 commentedThe 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.
Comment #35
user3077953 CreditAttribution: user3077953 commentedI have to admit, though, I don't understand how the second correction
is any different from just removing the following line:
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:
Comment #36
hot_sauce CreditAttribution: hot_sauce commentedI 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.
Comment #37
mikemadison CreditAttribution: mikemadison commentedIf you follow the link to the Search API issue linked in comment #10, that might help you hotsaucedesign.
Comment #38
hot_sauce CreditAttribution: hot_sauce commentedlalweil: 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.
Comment #39
AnybodyI 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.
Comment #40
AnybodyPS: The NORMAL (full) pager works fine, but my edge case shows that the result needs work, because it creates a different behaviour than expected!
Comment #41
AnybodyComment #42
user3077953 CreditAttribution: user3077953 commentedUnfortunately, 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.Comment #43
G.I.Joe CreditAttribution: G.I.Joe commentedBecause 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.
Comment #44
hot_sauce CreditAttribution: hot_sauce commentedG.I. Joe,
Your patch came through as a garbled mess (with time stamps and some other junk in there). Could you repost please?
Thanks!
Comment #45
akolahi CreditAttribution: akolahi commented#26 also worked for me. Many thanks!
Comment #46
jaylotta CreditAttribution: jaylotta commented#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.
Comment #47
jncrucesThe patch submitted in 26 solves some problems, but is incorrect, the second condition (!isset) is wrong... must be true when isset.
Comment #48
panthar CreditAttribution: panthar commentedHi 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!
Comment #49
panthar CreditAttribution: panthar commentedHey 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?
Comment #50
MurzPatch 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.Comment #51
wickwood CreditAttribution: wickwood commentedI 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.
Comment #52
vikramy CreditAttribution: vikramy commentedCan you please try this patch?Also I think logic in "post_execute()" method can be removed.
Comment #53
vikramy CreditAttribution: vikramy commentedRemoving Logic in post_execute() method works for me. Thanks G.I.Joe
Comment #54
vikramy CreditAttribution: vikramy commentedComment #55
skyredwangI tested #53 patch. It works.
Comment #56
skyredwangIf any patch can remove codes and not add codes and if it works, this patch should win a gold metal.
Comment #57
jordanrussellsmith CreditAttribution: jordanrussellsmith commentedI 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.
Comment #58
danharper CreditAttribution: danharper commentedIs this patch only for version 1.x-dev
Cheers Dan
Comment #59
peterlolty CreditAttribution: peterlolty commented(deprecated)
Comment #60
peterlolty CreditAttribution: peterlolty commented(deprecated)
Comment #61
peterlolty CreditAttribution: peterlolty commented(deprecated)
Comment #62
peterlolty CreditAttribution: peterlolty commented(deprecated)
Comment #63
peterlolty CreditAttribution: peterlolty commentedI 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.
Comment #64
rcodina CreditAttribution: rcodina commented@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
Comment #65
grom358 CreditAttribution: grom358 commented@peterlolty patch #63 doesn't work correctly with PHP filters. Add a filter
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.
Comment #66
peterlolty CreditAttribution: peterlolty commented@grom358 which version of "Views" did you used?
Comment #67
peterlolty CreditAttribution: peterlolty commentedsorry about the zip file not git patch,,, please someone help me to make the patch.
https://www.diffchecker.com/dpj9gs3b
Comment #68
rcodina CreditAttribution: rcodina commented@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!.
Comment #69
peterlolty CreditAttribution: peterlolty commented@rcodina Thanks for your impressive comment.
Comment #70
rcodina CreditAttribution: rcodina commented@peterlolty Thanks for the patch!
Comment #71
rakesh.nimje84@gmail.com CreditAttribution: rakesh.nimje84@gmail.com commented#69 working for me.
Comment #72
klokie CreditAttribution: klokie commented#69 works for me too, thanks!
Comment #73
jlyon CreditAttribution: jlyon commentedFixed the issue for me too
Comment #74
umuthan CreditAttribution: umuthan commentedpager 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?
Comment #75
peterlolty CreditAttribution: peterlolty commentedComment #76
peterlolty CreditAttribution: peterlolty commented#74Would you mind explain more about your use case? so I may investegate in deep, thanks
Comment #77
bkno CreditAttribution: bkno commented#69 patch works for me.
Comment #78
rcodina CreditAttribution: rcodina commented@umuthan
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.
Comment #79
rcodina CreditAttribution: rcodina commented@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.
Comment #80
DrCord CreditAttribution: DrCord commented@rcodina - instead it should not show any results, as you haven't searched yet, right?
Comment #81
rcodina CreditAttribution: rcodina commented@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.
Comment #82
zmove CreditAttribution: zmove commented#69 fixed the issue.
Comment #83
MustangGB CreditAttribution: MustangGB commentedStill NW as per #79.
Comment #84
peterlolty CreditAttribution: peterlolty commentedLet me check!
Comment #85
jaydee1818 CreditAttribution: jaydee1818 commented#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.
Comment #86
peterlolty CreditAttribution: peterlolty commentedNOT sure if the #86 patch is correct or not, need tester to give feedback.
Comment #87
peterlolty CreditAttribution: peterlolty commentedComment #88
Robert_T CreditAttribution: Robert_T commentedI tried patch #86 and it did not work, but patch #69 did the trick.
Comment #89
jaydee1818 CreditAttribution: jaydee1818 commentedNeither patch #69 nor #86 work for me.
Comment #90
alberto56 CreditAttribution: alberto56 commentedHere 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.)
Comment #91
alberto56 CreditAttribution: alberto56 commentedA 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.
Comment #92
alberto56 CreditAttribution: alberto56 commentedHere is the correct version.
Comment #93
bkat CreditAttribution: bkat commentedI'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?
Comment #94
alberto56 CreditAttribution: alberto56 commented@bkat this patch is for 7.x-1.x-dev
Comment #95
bkat CreditAttribution: bkat commented@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.
Comment #96
alberto56 CreditAttribution: alberto56 commented@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.
Comment #97
alberto56 CreditAttribution: alberto56 commentedHere 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.
Comment #98
alberto56 CreditAttribution: alberto56 commentedIn 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.
Comment #99
alberto56 CreditAttribution: alberto56 commentedConfirming 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.
Comment #100
bkat CreditAttribution: bkat commentedI 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.
Comment #101
bkat CreditAttribution: bkat commentedhttps://www.drupal.org/node/2484407 is where I fixed this on 7.x-2,x-dev
Comment #102
andyanderso CreditAttribution: andyanderso commentedI 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.
Comment #103
alberto56 CreditAttribution: alberto56 commented@andyanderso, please try the patch at #97.
Comment #104
andyanderso CreditAttribution: andyanderso commentedPatch in #97 worked great. Sorry for me being a ding-bat and getting #92 and #97 mixed up. Thanks for the work on this.
Comment #105
yepaPatch #97 work fine. Thanks
Comment #106
alberto56 CreditAttribution: alberto56 commented@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
Comment #107
peterlolty CreditAttribution: peterlolty as a volunteer commentedI 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
Comment #108
dan.mantyla CreditAttribution: dan.mantyla commentedIt 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:
views_php/plugins/views/views_php-plugins-pager.inc, line #50
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.
Comment #109
alberto56 CreditAttribution: alberto56 commented@danmantyla thanks for sharing.
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.
Comment #110
rcodina CreditAttribution: rcodina commented@danmantyla On the files section of this page, look at the right side. There is a button "Patchname suggestion". Press it and see ;)
Comment #111
klase CreditAttribution: klase commentedCan 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.
Comment #112
pramodganore CreditAttribution: pramodganore commented@alberto56, Thanks; This fixes the issue for me.
I will just leave this here.
https://www.drupal.org/node/1016574#comment-9940241
Comment #113
pramodganore CreditAttribution: pramodganore commentedCan someone confirm that this can be moved to close.
Comment #114
alberto56 CreditAttribution: alberto56 commentedThis 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.
Comment #115
NaX CreditAttribution: NaX commentedPatch #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.
Then alter post_execute()
This does not solve the problem of vews_php fields that modify the number of pager records.
Comment #116
DarrellDuane CreditAttribution: DarrellDuane commentedPatch in #97 worked great for me. Thanks.
Comment #117
joake CreditAttribution: joake commented#100 worked for me running views_php version 7.x-2.x-dev - thanks
Comment #118
zmove CreditAttribution: zmove commentedPatch also work on 2.x version of the module. Need to be commited to all branch.
Comment #119
peterlolty CreditAttribution: peterlolty as a volunteer commentedComment #120
edxxu CreditAttribution: edxxu at INsReady commentedThe 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.
Comment #121
wylbur CreditAttribution: wylbur commentedThis 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.
Comment #122
rcodina CreditAttribution: rcodina commented@wylbur Which are the differences between patches #108 and #121? Only the patch name? If not, please provide an interdiff.
Comment #123
peterlolty CreditAttribution: peterlolty as a volunteer commentedEveryone who report RTBC please mention which patch (#num) you mentioned.
Comment #124
Sinan Erdem CreditAttribution: Sinan Erdem commentedThe 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.
Comment #125
Anybody@#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.
Comment #126
NaX CreditAttribution: NaX commented+1 for splitting issues
Comment #127
peterlolty CreditAttribution: peterlolty as a volunteer commented-1 for splitting issues, not support splitting the problem, as we need a general correct solution to commit for fixing the bugs.
Comment #128
NaX CreditAttribution: NaX commented@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.
Comment #129
peterlolty CreditAttribution: peterlolty as a volunteer commented@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.
Comment #130
fizk CreditAttribution: fizk commentedWith 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():
To effectively set the limit and offset back to zero, this patch resets the range using
hook_views_post_build()
.Comment #131
peterlolty CreditAttribution: peterlolty as a volunteer commented#130 RTBC
with PHP filter and PHP field used inside the views.
Also Views navigation works fine.
Comment #134
fizk CreditAttribution: fizk commentedCommitted. Thanks everyone for not giving up on this issue!!
Comment #135
DarrellDuane CreditAttribution: DarrellDuane commented@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.
Comment #136
fizk CreditAttribution: fizk commented@DarrellDuane Can you list steps on creating a new view that would reproduce this on a fresh Drupal install?
Comment #137
fizk CreditAttribution: fizk commented@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,
Comment #138
ckngI'm getting fatal error for code introduced in #130 for all views. Just enabling views_php only, not used in any views yet.
Comment #139
fizk CreditAttribution: fizk commented@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']
.Comment #140
ktch_my CreditAttribution: ktch_my commented@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
Comment #141
DarrellDuane CreditAttribution: DarrellDuane commented@fizk I've created issue https://www.drupal.org/node/2613930 and added instructions about how to replicate the issue.
Comment #142
ckngFor my case, $view->build_info['query'] is empty.
Comment #144
fizk CreditAttribution: fizk commented@SiaoKiax3 Let's work on that in #2613876: Cannot display specific number of items in view
Comment #145
fizk CreditAttribution: fizk commented@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.Comment #147
ckngMy views is search API solr index type, so technically there are no db query.
The patch should do.
Comment #148
fizk CreditAttribution: fizk commentedComment #150
MustangGB CreditAttribution: MustangGB commentedThis "fix" hits performance/memory so hard.
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
Comment #151
MustangGB CreditAttribution: MustangGB commentedIn light of #150 I'm thinking we should re-visit this solution.
Comment #152
fizk CreditAttribution: fizk commentedThanks MustangGB, can you create a new issue to fix the performance issue?
Comment #153
simone960 CreditAttribution: simone960 commentedI 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 ?
Comment #154
simone960 CreditAttribution: simone960 commentedSorry, 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:
Comment #155
lanzs CreditAttribution: lanzs commentedI 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
Comment #156
simone960 CreditAttribution: simone960 commentedI'm using Views Field View module to embed the View at the moment.
Comment #157
abhishek.pareek CreditAttribution: abhishek.pareek at Innoraft commentedI 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.
Comment #158
peterlolty CreditAttribution: peterlolty as a volunteer commented@abhishek.pareek actually the problem has been fixed and commit already in the latest release.
Comment #159
ckng@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
Comment #160
grahamtk CreditAttribution: grahamtk commentedSo 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
Comment #161
MustangGB CreditAttribution: MustangGB commented@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
Comment #162
cirrus3d CreditAttribution: cirrus3d commentedHi,
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:
from views_php_plugin_pager.inc and the pager seems to work correctly now.
Comment #163
skylord CreditAttribution: skylord commentedFor anyone suffering from performance degradation - please, try this patch - #2628014-4: Pager fix causes performance and memory regression
Comment #164
rifatn CreditAttribution: rifatn commented#5 Patch works like a charm. Thank you so much. @mikemadison
Comment #165
BDuell CreditAttribution: BDuell at Ubertus.org commentedThis 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?
Comment #166
keshavv CreditAttribution: keshavv at gai Technologies Pvt Ltd for gai Technologies Pvt Ltd commentedFacing same issue on latest 7.x-1.0-alpha3 released on 12 November 2015