I am using views_data_export to create a CSV download with the Exposed Filters form in a block. One of the exposed filters is a Select widget (for content type). I get an error message at the top of my file when I download it.

I think the problem is that the value of the Select widget is an array, and the code expects a string (as for a text box/area). It passes that value through check_plain(), which hands it off to htmlspecialchars(), generating the error.

I will supply a patch as soon as I have an issue number.

Files: 
CommentFileSizeAuthor
#15 views_data_export-exposed_filter_token_bug-1888614-15.patch1.16 KBmichfuer
PASSED: [[SimpleTest]]: [MySQL] 97 pass(es).
[ View ]
#12 vde-exposed-filter-1888614-12.patch1.49 KBJvE
PASSED: [[SimpleTest]]: [MySQL] 97 pass(es).
[ View ]
#7 vde-exposed-filter-1888614-7.patch1.48 KBbenjifisher
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#1 vde-exposed-filter-1888614-1.patch1.1 KBbenjifisher
PASSED: [[SimpleTest]]: [MySQL] 78 pass(es).
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new1.1 KB
PASSED: [[SimpleTest]]: [MySQL] 78 pass(es).
[ View ]

The attached patch fixes the problem for me. I am not sure what effect it will have on other file formats, or if the Exposed Filter form is not in a block. My guess is that the file format will not matter, since add_http_headers() adds the filter information as tokens in the 'Content-Disposition' header, which (I guess) is independent of the format.

I am also not sure whether the option can be anything other than a string or an array. At least, I think this patch is a step in the right direction.

Status:Needs review» Fixed

Thanks very much for the patch, fixed in 7.x-3.x.

Version:7.x-3.x-dev» 6.x-2.x-dev
Status:Fixed» Patch (to be ported)

Needs backport

Status:Patch (to be ported)» Fixed

Pushed in 6.x-2.x

Status:Fixed» Closed (fixed)

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

Status:Closed (fixed)» Needs work

#1 doesn't work with the between-date-exposed-filter because option in that case is like

<?php
array('value' => array('date' => '2013-06-28'),
   
'min' => array('date' => '2013-06-28'),
   
'max' => array('date' => '2013-06-28'),
);
?>

Code:

<?php
  $option
= implode('--', $option);
?>

causes error in that case: "Array to string conversion in views_data_export_plugin_style_export->add_http_headers() (line 330 of D:\xampp54\htdocs\specsavers.localhost\brand2\code\sites\all\modules\contrib\views_data_export\plugins\views_data_export_plugin_style_export.inc)."

https://drupal.org/node/1298814#comment-6870686 works in that case.

Status:Needs work» Needs review
StatusFileSize
new1.48 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

@sinn, thanks for pointing this out. I guess if I had looked harder in the issues queue, I would have found #1298814: PHP warning when exposed filters contain non-scalar data. (now closed as a duplicate of this issue) instead of opening this one.

I am not too surprised that the patch in #1 fails to cover some cases: see my comment there.

The latest patch in the other issue has some funkiness:

<?php
           
foreach($filter_data as $key=>$data) {
             
$data = is_array($data) ? implode('-', $data) : $data;
             
$filter_data = $key . '-' . $data;
            }
?>

Even if PHP allows it, I do not like replacing an array while iterating over it, but surely this snippet does not do what we want: the effect is to set $filter_data to $key . '-' . $data for the last entry of the original array, discarding the results of earlier entries. Also (and the first thing I noticed) it violates Drupal coding standards: => should have a single space on either side.

Please test the attached patch. It could be more concise, but I think it is pretty clear. I tested it on my site, but not with a date-range filter.

Note that my patch ignores $key unless $data is an array. I do not feel strongly about this: if you think the key should be included, then I can roll a new patch.

Are we confident that "array of array of strings" is as bad as it can get? Maybe we should do something with array_walk_recursive() in order to future-proof this bit of code.

Version:6.x-2.x-dev» 7.x-3.x-dev
Status:Needs review» Needs work

I am using patch #7 on one of my sites now and it does fix the notice.

I do not know if the resulting $tokens string is useable though.

Example:
One date field "field_date" and one date-range field "field_date_range".

$tokens['%exposed'] with only range filled:
field_date_value_value----field_date_range_value_min-2011-7-9--max-2012-5-16
$tokens['%exposed'] with only date filled:
field_date_value_value-2012-6-10-field_date_range_value_min-----max---
$tokens['%exposed'] with neither filled:
field_date_value_value----field_date_range_value_min-----max---

Perhaps an array_filter() is needed on $data before implosion?

Status:Needs work» Reviewed & tested by the community

Patch in #7 works for me. (Patch in #1 did not.) Note that the new patch needs to be run against the dev version of the module. I'm marking this RTBC and switching the version back to 7.x-3.x.

Any word on when we can expect to see a new stable version?

Thanks!

Whoops sorry - our ticket updates crossed in the blogosphere. Can I leave this RTBC or does it need more work?

If I remember correctly, the token is used to create a default file name for the download. It is configurable to some extent. It is not useful for me.

If that is right, then the problem in #8 is an annoyance, not a serious problem. Unless you need to be able to parse the file name ...

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new1.49 KB
PASSED: [[SimpleTest]]: [MySQL] 97 pass(es).
[ View ]

The same patch from #7 with a filter for empty values.

$tokens['%exposed'] with only range filled:
field_date_value_value--field_date_range_value_min-2011-7-9--max-2012-5-16
$tokens['%exposed'] with only date filled:
field_date_value_value-2012-6-10-field_date_range_value_min---max-
$tokens['%exposed'] with neither filled:
field_date_value_value--field_date_range_value_min---max-

Issue summary:View changes
Status:Needs review» Reviewed & tested by the community

Patch #12 works for me

Seems to take care of me.

StatusFileSize
new1.16 KB
PASSED: [[SimpleTest]]: [MySQL] 97 pass(es).
[ View ]

I feel like recursion is appropriate here since I never can anticipate the depth of a particular field/filter used by Views. This patch doesn't do anything the others don't, just takes a recursive approach.