Argument corrupted in passing to child view

I'm changing this to bug. Two other people have the same issue http://drupal.org/node/1409292#comment-5496396

What was done:
Created View listing nodes with (1) a certain boolean value and any term from a certain vocabulary. This view represents the "landing pages" for some collections of articles.

Created View listing nodes without (0) that boolean value, and with a specific term from that vocabulary. This view represents the "child pages" of those collections of articles.

Added Global:View field to the "landing pages" view, so that each row listing a landing page would also show a view listing the child pages with the matching taxonomy term as well. Set this view field to pass the term as argument. The term was listed among available tokens.

Added contextual filter to the child view, validating incoming argument against taxonomy terms in the specified vocabulary.

The argument was passed in text format as well as tid format, and the validation was also tried in both configurations.

Added to the Header of the child view, a dpm() to see the exact value of the incoming argument.

Expected behavior:
Child views should get the taxonomy term (or term ID) as incoming argument.

Actual behavior:
dpm() reveals that the Child view gets nid as incoming argument.

So, child view always yields the behavior specified for invalid argument.

Exports of parent and child views attached here. TID version

Termname version this time: Exports of parent and child views attached here.

Two other people have the same issue http://drupal.org/node/1409292

And the reason I'm not on that issue is that I'm not using multiple arguments - in fact, unlike the first person in the other issue, nid is not even an argument at all in my scenario.

You said above that you were passing in both tid and term?

Not as two simultaneous arguments, but, I tried it both ways.

how are you getting you tid? is the token available

It was, at one point. I double-checked and I see that in the version attached above in #2 that token isn't, so, I recognize that was a bad test.

I re-created the previous case where I did have a TID token. Ordering that field so that it's not first, makes the tid token available. So, I've done it this way instead of by creating a Relationship.

This version of the scenario is attached here.

This time the result is a little different: This time, the argument is completely absent coming into the child view (as usual, confirmed with dpm() ), so, the child view produces the "filter value not available" behavior, which in this case is "display all results".

Category: bug report » support request

To the extent that this is known/expected behavior on your part, I'll agree that requesting documentation/help is a support request on my part.

But I have to ask, in what way is the passing of NID, or, no argument at all, *not* a corruption of the argument which is both available and specified? Even if there's a known work-around, I'm having a hard time perceiving this as not a bug.

Anyway thanks for your help!

Trying something else:

field_behind_the_scenes has the -tid available as a rewrite output token, so, I'm rewriting that field's regular term output as the -tid. Then using the regular field token as the argument value to send to the child display (not the -tid token, which is actually not available as an argument after all).

Same as ever, getting the NID as the received argument. New versions exports attached.

FYI, I also tried it your way, with a Relationship. Tried it on both parent and child, singly and simultaneously. This yielded absolutely no change at all.

Thanks again!

Thanks, let me make sure to add the relationship as a field. I overlooked that part.

Where I'm doing dpm(): That's in the header of the child view. You could see the actual code I'm using to load the view object and dpm() the args in any of the exports. I will say: the child-view behavior certainly does reflect what args appear (via that means of inspecting) to be sent. When arg is absent, the child view gives the "absent arg" behavior. When NID is sent, the child view gives the "validation failed" behavior.

Thanks again, I'll try the relationship again and report back.

You could see the actual code I'm using to load the view object and dpm() the args in any of the exports.

Well, don't let me send you on a code-hunt. It's as follows:

$handler->display->display_options['header']['area']['content'] = '<?php
$view = views_get_current_view();
dpm($view->args);
?>';
$handler->display->display_options['header']['area']['format'] = 'php_code';

That's in the header of the child view.

OK, the relationship thing works. I'm getting the behavior I need now.

Thanks very, very much.

One more thing along the lines of "support request": Can you assist with my education, and help me to understand why NID would *ever* be passed as an arg value, when a specific token is both available and specified? I won't question the case where no arg at all gets sent - clearly that's what one might expect, when one didn't configure an arg properly.

This really is becoming a problem. When I stated just above that I was now getting the required behavior, it turns out that only in Preview was that happening. Adding the field from the taxonomy relationship made the actual block break (yield no results).

So Preview gave me the right behavior but I can't use it in real life. I don't know why that is, it's certainly got nothing at all to do with Views Field View, but it's a barrier - an unnecessary one, since I can't even imagine why a taxonomy relationship would be required at all. When including the Content: All taxonomy terms field, [term_node_tid] becomes available as a token... when I try passing that, I get NID in the viewfield view instead.

I can't imagine why arguments would not get passed, or, sometimes an argument gets passed and it is the NID rather than whatever value I *really* tried to pass.

Arguments are just not reliably passed to viewfield views. I, and others, have seen this happen with a whole bunch of different configurations. I can't even put hardcode values in the Arguments-to-pass field and see them arrive into the child View. Sometimes nothing is passed, sometimes the useless NID is passed.

What am I missing? Just what, exactly, is necessary, to get a value passed as an argument to the viewfield view? Why is this so unreliable and obscure?

OK, I understand. Thank you for confirming that it isn't simply my own ignorance at work, here. Although, if it had been a matter of ignorance on my part, then, that would not have been unwelcome either.

So: Are you able to recommend a work-around for me? If people are generally *not* using values from fields as their arguments into the viewfield view, then, what exactly *are* they doing?

Or, knowing what you do about how arg-passing is done, is there any wizardry you can think of to make a work-around even while the "real" feature isn't working? Perhaps an alternative implementation idea which does not depend on views-field-view at all?

Thanks a lot!

Aha, last thing: Could you link me to the issue where the matter you described is open? I'm interested to read the details. TYVM again.

There is currently an issue with using values from fields

Well, OK. That is primarily what I have been trying to achieve in my particular use-case.

However, "I've tried setting the default argument to !1, and some other ridiculous-seeiming things" including "put[ting] hardcode values in the Arguments-to-pass field " and that that doesn't work either. Frankly, these don't seem that ridiculous, and even while you've confirmed that using args from field-values might currently be troublesome, could you educate me about why nothing else I've tried yields a successful arg-passing either? ***

I remain convinced that there's something which you and all the other users of this module have managed to divine somehow (according to http://drupal.org/node/1171604, dereine's language there is quite convincing indeed) and which I'm just not understanding (notwithstanding filthypixel's and MBroberg's clear instructions).

For the moment, I'm busy creating a real README file largely based on MBroberg's post #3 in the above-linked issue. It's clearly going to be a useful and welcome contribution, though I confess feeling a little insincere about doing it (even in the sincere spirit of helpfulness and participation) since those instructions don't work for *me*. I guess I'll just offer a patch the 6.x branch with that, not the 7.x branch, as a means of mitigating that conflicted feeling.

*** except in the extremely special, and not-workable, case where I use the relationship. See #15 above, the arg passing works but the overall solution does not (through no apparent fault of views_field_view)