The Search API query differs from the normal drupal one in that it doesn't fire the pre_execute() and post_execute() callbacks on the pager plugin.
I'm not quite sure if this is a bug or not, as I've not seen it break pagers...
However... views_php does it's magic off of the pager's pre/post execute hooks and as such, it doesn't work with views based on Search API indexes.
It might be the case that views_php is doing something a bit dirty and as such this should be switched to a views_php issue (or resolved some other way), but I thought I'd start off here as the query plugin is differing from the default views query plugin.
Would be really handy being able to use views php with Search API index views!
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 2096275-1-trigger_pager_pre_post_execute_callbacks.patch | 933 bytes | andrewbelcher |
Comments
Comment #1
andrewbelcher commentedHere's a patch that 'duplicates' the functionality of the default query engine... Not sure if I've necessarily put them in the right place or not...
I haven't seen any other knock on issues with it...
Comment #2
drunken monkeyAs usual with Views, I have no idea what's going on or whether this patch is right, but since it doesn't appear to break anything immediately (though it's rather probable that some pager somewhere that doesn't properly check its arguments will throw around errors now) and helps at least in this use case, I just committed the patch.
Thanks for your contribution!
Comment #4
mikemadison commentedThis absolutely works. I did some debugging with views php.
In a 'non' search API view, the pre and post execute functions get called and can be dpm'd no problem. In a search API view, they do not. Once this patch is applied though, suddenly they start working.
This is a great catch and thanks for adding it in.
The symptoms I've been seeing are that any php code added to the 'value' field through ah custom php field is not returned to the output. This means that any manipulation done through views php is NOT sortable in the view. This can cause major problems if you're outputting your view in a table.
Comment #5
mikemadison commentedHas anyone noticed that the $data object in the value field seems to have significantly LESS information (like all of the fields) in a Search API view than a normal one? This patch does make the value field return properly and makes it accessible for sure, but I'm not sure if it is a 100% solution since it still doesn't quite behave the same way.
All I see in the $data object in a Search API view now is a few values related to the Search API entity. I can use the actual entity ID to do any DB queries I want and return values etc., but the value field is completely ignorant of what fields have been added to the view.
Comment #6
mikemadison commentedThis also seems to cause the pager to break when a PHP field is added to a view after this modification is made.
Comment #7
drunken monkeyYou are welcome to debug this and see how/whether it can be fixed. But it's clear that we can't just work with any fields that might be out there, if Views doesn't provide a framework for that.
For changing the values, see #2098575: Cannot alter fields in view.
Comment #8
mikemadison commentedI believe I have figured out the issue with the paging. It isn't actually a Search API problem, however this patch WILL cause the issue to occur. I have created a patch over in Views PHP here - https://drupal.org/node/2123315 - that resolves the issue for me. I have a more robust explanation of what is going on and reference back to this issue.
Comment #9
mikemadison commented