I have a date field in the parent view and a date argument in the child view.

The date argument in the child view is set to day granularity.

I have a date formatter that is Y-m-d, which is what is expected by the child view.

The parent view date field is set to use that formatter, however it isn't having an effect.

If I use the raw token, then the arg passed in is an array containing the date along with a few other things like the tomezone.

If I use the rendered token, I get just the date, which is good, however it has not been formatted as per the formatter that the field is set to use.

Comments

marcus178’s picture

I seem to be suffering from a similar problem.

If I manually put in the argument of 2013-07-01--2013-07-31 the correct information is returned but when I use tokens I get no result, so for example

[!field_holiday_period_dates_1]--{!field_holiday_period_dates_2]

and I have check that these are only outputting a raw value in the correct format

lunk rat’s picture

I also see this issue. I am attempting to do the same as #1. Date field tokens like [%field_date_field] are not passed correctly to the child view. I can enter static value '20130101--20130201' and everything works as expected. But when I try to pass via row tokens I get nothing. I have verified that my tokens are rendered properly by having them displayed in a Global (custom text) field.

I have other (non-date) field tokens passing to the child view just fine.

Any luck on getting this working marcus178 or rooby?

lunk rat’s picture

UPDATE: It seems that the date values are being passed to child view contextual filters as the current date instead field values from the row of the parent view. I discovered this when I created a node having a date field with start/end values in the current month (June 2013), and to my surprise it showed up in my child view even though the token values that were supposed to be passed by the parent view's row were not in this range!

So to sum the behavior of this bug in light of this new discovery:

  1. Build child view with contextual filters that include date filters. Manually pass static filters to child view preview: works as expected.
  2. Add child view as views_field_view field into parent view. Manually pass static values in the "Contextual filters" area of the views_field_view field handler settings, just to test: works as expected.
  3. Enter field replacement tokens for date fields into the "Contextual filters" area of the views_field_view field handler settings: does not work as expected—instead, the child view behaves as if it were given contextual filter values built from the current date instead of from the token replacement field values from the parent row.

I hope this helps to track down the cause of this bug.

lunk rat’s picture

Sorry double post stupid preview thing

rooby’s picture

I have not investigated this further yet.

Becuase the views I am using this with already have custom code I also hhave custom code providing the argument in the proper form.

It would be good to resolve this though.

I do remember seeing something different from #3 though.
I was getting the correct date, but it was a date array, not just a value, which is what was choking it in my case.

lunk rat’s picture

I managed a workaround with the following views_php field, excluded from display, with the following code as my PHP field "Output code":

$date_field_start = new DateTime($data->field_field_date[0]['raw']['value']);
$date_field_end = new DateTime($data->field_field_date[0]['raw']['value2']);
echo $date_field_start->format('Ymd') . '--' . $date_field_end->format('Ymd');

I moved this Global: PHP field above my Global: View field and it showed up in the replacement patterns for my contextual filters to pass to the child views_field_view field. I passed it as [%php] and it worked perfectly to supply the child view with a filter value.

Hope this helps someone work around this bug. We still need to figure out why date fields replacement tokens don't pass correctly.

Mr F’s picture

Issue summary: View changes

I know the issue is 2 years old but for me it's up-to-date.
The workaround from #6 doesn't work for me at all. It just returns the current date :/ Maybe it's because the field is a date repeat field?! I don't know what to do.

Edit:

$date_field_start = new DateTime($data->field_data_field_zeit_field_zeit_value);
echo $date_field_start->format('Ymd');

This did the trick for me.

KurtTrowbridge’s picture

Just wanted to chime in to say this wasn't working for me either - I have a static date I wanted to use as the start date and a Date field to use as the end date, and as mentioned in #1, writing them manually worked, but pulling in the Date field on the filter gave no result. Since I'm using Computed Field elsewhere on the site, I ended up solving it by adding a Computed Field to the node, then passing it as [%field_name]:

$beginning = 19690101;
$date = $entity->chart_date;
$entity_field[0]['value'] = $beginning . '--' . $date;

(Note that the date being formatted with time included apparently doesn't matter - it works even though the date is output as YYYY-MM-DD 00:00:00, both when written manually and passed as a token.)

knipnehpets’s picture

Sorry to report that this bug still seems to be there. Trying the suggested workarounds; thanks for these.

knipnehpets’s picture

I believe the reason that views_php works for some people, and not others, is because views_php 7x-1 (alpha, dev &c) itself has a bug (!) which means it doesn't get the $row->field value like it should (it just gets the nid).

So, how I got this workaround running for me:
I upgraded to views php 7x-2x-dev. In global:php, I was able to get my date field value from the row using just $row->field_name_of_field no problem. As per above, I used the output field only.

Finally, to get this php field to work with global:view, I set the formatting of my original date field to 'plain' (i.e. not 'date and time', which didn't work), and I used
[%php] (i.e. rendered, raw [!php] didn't work ), in the global view contextual filter itself.

Hope this helps.