Export issues with CCK Date fields

Confirming Issue

I can also confirm the reported issue, though it's not just on exposed date filters as the original poster stated, but appears to be on any date filter.

I do have the "apply parent sort" option set, which I've seen suggested in other posts is necessary to have parent filters applied.

Follow on to previous post: I found that if I remove all filters from the Data Export display, it magically works. I guess if it doesn't have filters it takes the ones from the parent view and if it does it ignores the parent filters?

edit: Disregard, this was a rabbit hole caused by having more than one view hitting the same path.

I was using Views Calc Table under Page (display) > Style settings > Calc Table and I figured it (calc table) was getting in the way.

So I made a new view with standard Table style in the default display, along with my date range filters and all other parameters
and then simply created a 'Page' and 'Data Export' displays. I figure the trick
is to set everything in the default display so that your Page and Data Export displays are totally cloned.

The only tweak required after that is the 'Data Export' display > View > Style settings > CSV > gear icon (Style Options) > activate "Provide as File" > activate "Parent Sort" - it works as advertised now.

#1516988: empty cells with exposed date filter is a duplicate of this.

Hi,

Does anyone fix this issue? I have same problem when I use exposed filters and batched export. For some reasons views does not render CCK fields. I have looked to the preprocess function _views_data_export_body_shared_preprocess and then checked $view->style_plugin->rendered_fields[$num][$id] values for CCK fields is empty. When batch export is disabled all works as expected.

Regards,
Alex

Additional note: May be it will help to figure out. I have checked methods "advanced_render" and "render" in "views_handler_field.inc". The variable $values contain incorrect aliases. In other word $this->field_alias does not match with alias keys which contain $values variable. It's unclear why view build incorrect aliases. It's possible that views was incorrect cached by Views Data Export module?

I can confirm Alex Ilchuk's findings: this boils down to a difference in the field_alias for CCK date fields between batch and non-batch exports.

Here are the specific field aliases I am getting (specific to my setup, but it illustrates the issue):

node_uc_order_node__node_data_field_complete_date_field_comp (without batch - works)
node_uc_order_node_node_data_field_complete_date_field_compl (with batch - does not work)

Notice that in the first one, there are two underscores between the base table alias and the field alias. Views truncates field aliases at 60 characters (both of the above are that long), but the difference in underscores causes the aliases to be different.

Ultimately, the incorrect alias is causing the field to return a blank value at line 208 of the file cck/includes/views/handlers/content_handler_field.inc (in the CCK module):

<?php
...

    $item = array();
    foreach ($db_info['columns'] as $column => $attributes) {
      $item[$column] = $values->{$this->aliases[$attributes['column']]};
    }

...
?>

I will try to figure out where the alias is being generated next, in hopes of finding a solution.

I traced the issue with the field alias to the $query::queue_table() method, line 356 of views/plugins/views_plugin_query_default.inc:

<?php
...

    if (!$alias && $join && $relationship && !empty($join->adjusted) && $table != $join->table) {
      if ($relationship == $this->base_table) {
        $alias = $table;
      }
      else {
        $alias = $relationship . '_' . $table;
      }
    }

...
?>

When the data export is performed as a Batch, this if statement returns TRUE, but the second if statement returns FALSE. So $alias is built as $relationship . '_' . $table.

It's worth noting that you can solve this issue simply by adding another underscore in the line of code that builds the alias. (so it would be: $alias = $relationship . '__' . $table;).

I'm not sure if this is the right solution, however. Maybe there's a reason why only a single underscore is used there. It would be worth talking with the Views folks about this. Perhaps that "else" statement is a fallback that is rarely used, and it SHOULD have two underscores, but no one has encountered the issue yet. I don't know enough about the Views internals to be certain.

Turns out this is due to an issue with the Date module: #1289270: date arguments and filters do not work with relationships

The issue is fixed in the dev release of Date 6.x-2.x.

Special thanks to merlinofchaos and dawehner for helping me in IRC and ultimately tracing it to that issue.