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.

Comments

Category:feature» bug

I'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.

Status:Needs review» Active

No, 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.

Status:Active» Fixed

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

How 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.

I 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().

Status:Active» Needs review
StatusFileSize
new1020 bytes

PineRay'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.

Status:Active» Needs review
StatusFileSize
new1.09 KB

The 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.

@Amarjit - This patch worked for me - thanks so much!

Status:Needs review» Reviewed & tested by the community

Worked well for us too.

A quick grep on the source files shows this:

plugins/views/views_php_handler_field.inc:   * @see self::php_post_execute()
plugins/views/views_php_handler_field.inc:   * @see self::php_post_execute()
plugins/views/views_php_handler_field.inc:  function php_pre_execute() {
plugins/views/views_php_handler_field.inc:  function php_post_execute() {
plugins/views/views_php_plugin_pager.inc:        if (is_callable(array($handler, 'php_pre_execute'))) {
plugins/views/views_php_plugin_pager.inc:          $handler->php_pre_execute();
plugins/views/views_php_plugin_pager.inc:        if (is_callable(array($handler, 'php_post_execute'))) {
plugins/views/views_php_plugin_pager.inc:          $handler->php_post_execute();
plugins/views/views_php_handler_sort.inc:  function php_pre_execute() {
plugins/views/views_php_handler_sort.inc:  function php_post_execute() {
plugins/views/views_php_handler_filter.inc:  function php_pre_execute() {
plugins/views/views_php_handler_filter.inc:  function php_post_execute() {

Should these files be updated as well?

Status:Reviewed & tested by the community» Needs work

+++ b/docroot/sites/all/modules/views_php/plugins/views/views_php_handler_field.inc
@@ -111,7 +111,7 @@ class views_php_handler_field extends views_handler_field {
-  function php_pre_execute() {

You cannot change the function name. As it is being called from the views_php_plugin_pager.inc file.

+++ b/docroot/sites/all/modules/views_php/plugins/views/views_php_handler_field.inc
@@ -125,14 +125,14 @@ class views_php_handler_field extends views_handler_field {
-  function php_post_execute() {

You cannot change the function name. As it is being called from the views_php_plugin_pager.inc file.

@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.

@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.

I 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:

<?php
function pre_execute() {
 
$this->php_pre_execute();
}
function
post_execute() {
 
$this->php_post_execute();
}
?>

Issue summary:View changes
Status:Needs work» Needs review
StatusFileSize
new543 bytes

The 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.

Title:Views PHP columns are not supported by Views Data ExportViews PHP pre and post execute extender implementation