Non-default displays cannot receive arguments

Enabling the option "Aggregate queries" introduces the problem. There is a caveat in the option description: Views Field View can attempt to aggregate your queries to prevent Views from running a separate query for each instance of this field. This option attempts to aggregate these queries. This may only work on simple views and will not support default arguments as one might expect. Unfortunately this feature either doesn't work or doesn't degrade nicely.

After enabling the option and saving the view, calling up the wrapper-view yields PHP notice:
"Notice: Undefined index: arguments in views_field_view_handler_field_view->pre_render() (line 135 of .../views_field_view/views_field_view_handler_field_view.inc)."

@Jonathan Webb - The feature works there was just a bug in the way query aggregation handles arguments on displays. The module was trying to pull the arguments from the appropriate display on the child view without looking at the default. When the desired display was default or where the child display had overridden arguments this was fine. However, when the arguments are not overridden they and the default display is not used, the arguments are in ['default'] and not in the array for the child display that is being used.

I replaced:

 $configured_arguments = $child_view->display[$child_view_display]->display_options['arguments'];

With:

 // Find the arguments on the child view that we're going to need if the arguments have been overridden.
 if (isset($child_view->display[$child_view_display]->display_options['arguments'])) {
   $configured_arguments = $child_view->display[$child_view_display]->display_options['arguments'];
 }
 // If the arguments have not been overridden, retrieve them from the default.
 else {
   $configured_arguments = $child_view->display['default']->display_options['arguments'];
 }

It works properly for all the views I have tested.

Degrading nicely would be great but unfortunately there not really a way for the module to know whether aggregation caused unexpected results. Reviewing this again I think default arguments should work just fine. I'm not sure why i had put that in previously...

Committed.

There is still an issue in pre_render with the arg parsing. $argument = substr($token, 1, -1); - only works with field-based args ("[whatever]"), not argument-based args ("!1" or "%1"). Also, in general, when using argument-based args from the parent view, the reliance on the field_alias properties becomes problematic.

Attached is a wrapper for Version Control API's commitlog_commit_items view. if you visit http://site/vfv-wrapper/[id] it should display a node with nid=id as well as the visual diff for a commit items with vc_op_id=id. In this wrapper view you can compare the result of using "!1" as the argument or "[nid]" as the argument. Using "!1" I was still getting an incorrect view result, even with tizzo's patch above.

I was able to get this working for my test case with the attached patch, but I'm not sure that I follow the logic in pre_render enough to call it a fix. The two places I'm unsure of (in my patched version) are at:

• Line 137: 'values' => array($value), -- this may need to be 'values' => array_pad(array(),count($values),$value),
• Line 204: //if ($matching_item) { -- I commented out this $matching_item condition because it fails if argument-based args are used; I know this isn't the right solution, even though it fixed my issue.

Both tizzo and Jonathan are out this weekend, so we need an assessment on how to move forward.

Working on this...

applied patch to 7.x-dev and it get field arguments moving down to child view for me.

here is the patch rolled for D7...

got to try figure out what's happening to cause this error.

Notice: Undefined property: view::$row_index in views_handler_field->get_render_tokens() (line 1267 of /var/aegir/platforms/holly-drupal-7.2/sites/store1.holly.lan/modules/views/handlers/views_handler_field.inc).

Missed a line here so rerolled this patch.

Still getting the error described above, but now know that issue is because the view's row_index has not been set... still trying to figure out how to set that puppy.

Actually it seems to be a bug with the token processing. Attaching a D7 patch.

It seems that someone is submitting a D7 patch without updating the report. tsk tsk tsk
By the way, has a solution been found for the 6.x-1.0-beta1 version? I'm having the same problem.

After the initial patch was committed in #3 there was another patch in #4. Both of these I believe are for D6. Because this issue lies in both versions (D6 & D7), I think that is why the version wasn't changed. Patches relating to D7, have it explicitly mentioned in the patch filename. Either way, someone from this module needs to come sort out this mess.

I realize that there are patches for this, but none of them have been tested yet, so really there is no solid solution. Yeah, I agree, this needs some cleaning up.

Drupal 6 compatible versions of the module are not supported anymore.