Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Crossposting this issue: #1087898: PDOException: SQLSTATE[HY000] on batch export
If my view contains a column that is defined by Views PHP, this columns is not exported by 'Views Data Export'.
My guess is that some Views callback is missing.
Comment | File | Size | Author |
---|---|---|---|
#34 | views_php_pre_post_execute-1088776-34.patch | 1.16 KB | boromino |
#33 | views_php_pre_post_execute-1088776-33.patch | 1.16 KB | boromino |
#32 | views_php_pre_post_execute-1088776-32.patch | 1.34 KB | boromino |
#23 | views_php_pre_post_execute-1088776-23.patch | 551 bytes | Anybody |
#17 | views_php_pre_post_execute-1088776-16.patch | 543 bytes | SilviuChingaru |
Issue fork views_php-1088776
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
hadsie CreditAttribution: hadsie commentedI'm getting this same error. You have any luck figuring out a work around? It looks like I'm just going to have to write a custom views field for my solution.
Comment #2
johnvNo, and even worse: my current VDE-exports only export node-titles :-( .
I don't know yet if this is due to a update of VDE of an update of Views.
Comment #3
johnvSolved, see status of #1087898: PDOException: SQLSTATE[HY000] on batch export
Comment #5
gabrielu CreditAttribution: gabrielu commentedHow can this be related to table character encoding. All my tables are UTF8 but the PHP is never called there.
So the problem is about integrating Views PHP with Views Data Export. In the preview of VDE I see the result of my PHP FIeld, but not in the file, the file is always blank.
Comment #6
pineray CreditAttribution: pineray commentedI ran into the same trouble.
However, I applied the following modifications and it worked correctly.
Change the function name php_post_execute() in views_php_handler_field.inc to post_execute() and php_pre_execute() to pre_execute().
Comment #7
johnv@PineRay, is your solution (also) relevant for #1140896: Variable $row does not contain correct values ($data->_field_data does) ?
Comment #8
BWPanda CreditAttribution: BWPanda commentedPineRay's solution worked for me, though I don't really understand it...
I've attached a patch that should be tested to make sure it doesn't break anything.
Comment #9
Amarjit CreditAttribution: Amarjit commentedThe patch actually worked for me but with an error.
Strict warning: Declaration of views_php_handler_field::post_execute() should be compatible with that of views_handler::post_execute() in _registry_check_code() (line 2982 of \includes\bootstrap.inc).
I did some scavenging around on the function 'post_execute'. It seems this function needs the reference for $variables to be passed in. Even though this is not used, it's part of the function prototype.
See here »
Amarjit.
Comment #10
meghanmary CreditAttribution: meghanmary commented@Amarjit - This patch worked for me - thanks so much!
Comment #11
drewish CreditAttribution: drewish commentedWorked well for us too.
Comment #12
ttkaminski CreditAttribution: ttkaminski commentedA quick grep on the source files shows this:
Should these files be updated as well?
Comment #13
junedkazi CreditAttribution: junedkazi commentedYou cannot change the function name. As it is being called from the views_php_plugin_pager.inc file.
You cannot change the function name. As it is being called from the views_php_plugin_pager.inc file.
Comment #14
johnv@junedkazi , the function names have been changed similarly in other patches, too. With succes.
It seems like Views PHP has a lot of D6-code, which is not working anymore. This might be a D6-D7 api change.
Comment #15
junedkazi CreditAttribution: junedkazi commented@johnv I do understand that it is not working and a change is necessary. But by comment was regards to the patch in comment 9 where it is changed for only one file instead of the complete module. Hence the comment you cannot change it at one place as it makes the whole code much more vulnerable if someone applies this patch.
Comment #16
vensires CreditAttribution: vensires commentedI have to offer another idea - based of course on #6. In views_php_handler_field.inc Instead of fixing the function names and the callers, I only added the following functions to the views_php_handler_field class:
Comment #17
SilviuChingaru CreditAttribution: SilviuChingaru commentedThe solution from #16 is working fine and I also think is good for compatibility so here is a patch for this.
A better approach is to move content of php_pre_execute() and php_post_exectue() to pre_execute() and post_execute() and php_pre|post_execute() to return the output of pre|post_execute for views API consistency.
Comment #18
SilviuChingaru CreditAttribution: SilviuChingaru commentedComment #19
DevDaveUK CreditAttribution: DevDaveUK commentedPatch #17 works for me - the views php columns are now populated in the exported CSV, however, I have the following error on the page with my view:
Comment #20
SilviuChingaru CreditAttribution: SilviuChingaru commented@DevDaveUK please post you view (exported). I'm using this patch for 4 months now on production and I don't receive that error.
By the way, did you cleared cache and views cache after applying the #17 patch? You should do that and post your feedback afterwards pls.
Comment #21
DevDaveUK CreditAttribution: DevDaveUK commentedComment #22
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedneed to provide a patch but the fix in views_php_handler_field.inc at about line 119 is
There are several post_execute functions in views. I went with the definition in the views field handler:
modules/field/views_handler_field_field.inc:628: function post_execute(&$values) {
I did not find a specific views handler pre_execute function so I guess the one defined in views.inc should work just fine. Thus no error for that function.
Comment #23
AnybodyThe patch from #17 looks nearly fine.
One thing was just that
was missing the $values parameter, which lead to the problem described in #19. This is now fixed with the patch attached.
The question is, if pre_execute is required anyway. What's the reason for that? Is that ever being called?
views_field_handler does not contain such a function. See https://api.drupal.org/api/views/handlers!views_handler_field.inc/class/...
I've tested the export with the patch and it works great :)
Let's finish this!
Comment #24
rcodina CreditAttribution: rcodina commentedI have the problem described here and patch on #23 don't work for me.
Comment #25
zmove CreditAttribution: zmove commentedpatch #17 perfectly works
Comment #26
fizk CreditAttribution: fizk commentedI can't reproduce this issue with the latest 7.x-1.x-dev. Please reopen if you can and provide a list of steps to reproduce.
Comment #27
rcodina CreditAttribution: rcodina commented@fizk Just try to create a new search api view, then enable cache on it (Search specific for example) and then add a Views PHP field on it. The preview will work but the normal execution of view will fail. If you then disable the cache or delete the PHP field, the views will work.
Comment #28
fizk CreditAttribution: fizk commented@rcodina Thanks, I'll try to get back to this sometime this week. If I forget, please ping me.
Comment #29
abhishek.pareek CreditAttribution: abhishek.pareek at Innoraft commentedpatch #17 did the trick but gives strict warning as described in #19,
patch #23 worked for me.
Comment #30
skesslerThis appears to still be a problem. I tried to apply #23 but that does not appear to work with 7.x-1.0-alpha3.
Thanks,
Steve
Comment #31
skesslerI should update this. It is only a porblem if using batches export.
Thaanks,
Steve
Comment #32
boromino CreditAttribution: boromino at LakeDrops commentedThis patch passes $static between batch segments.
Comment #33
boromino CreditAttribution: boromino at LakeDrops commentedPass $static in batch instead of $_SESSION.
Comment #34
boromino CreditAttribution: boromino at LakeDrops commentedPatch has to be the other way around.
Comment #35
themic8 CreditAttribution: themic8 at Michalak commentedThank you @boromino. The patch works.
Note: I only need the patch when doing a batch export. Otherwise the patch is not needed.
Comment #36
Liam MorlandPatch does not apply. Please put into an issue fork.
Comment #37
nessunluogo CreditAttribution: nessunluogo commented#34 saved me. Thanks @boromino!
Comment #38
skylord CreditAttribution: skylord commentedHm. While updating old clients' site stated #34 applies cleanly on 1.1 and works OK. Please, review it.
Comment #40
SilviuChingaru CreditAttribution: SilviuChingaru at MagazinulCuScule.ro for MagazinulCuScule.ro commentedThis patch is not working for computed fields because the filter is triggered before fields are rendered so the filter will not work on Global: Math or Global: Text fields that have NULL values when the filter plugin is called.
In vs. 7.x-2.x this was solved using code:
but in 7.x-1.x the code is
And because a math field is calculated only in render stage, in pre_render stage, field has no value.
The best fix will be #2451759: Provide method get_value() for views_handler_field_math in views core.