new cck views integration breaks if views fusion is used

yep, that seems to be a views_fusion problem, I'll try to reproduce it.

Any progress on this? I too am getting the error, only on fused views; the component views work as expected. I'm using the latest 4.7 versions of Views, Views_Fusion, and CCK.

For what it's worth, the view properly structures the header of the table and the row elements for the first entry from view #1, but once it hits the view #2 portion the row is empty.

Many thanks,

Mark

I'm getting this error for CCK nodes when viewed using the views calendar module too.

I had a look at this, the updated cck views integration doesn't work with views_fusion. I've updated views_fusion, so not multiple cck fields are working again.

attached is a patch for CCK 4.7, which makes multiple CCK fields also working, if the option "do not group multiple values" option is chosen.

However the option "group multiple values" is still broken (with views_fusion). I'll tackle this after this one is fixed.

and here is the patch for 5.x, please review, it's quite simple

I'm not familiar with Views Fusion; Could you elaborate on why this is needed ?

views fusion fuses views together by using node relations for joining the data of multiple nodes together.

so you can list data of multiple nodes in one view. for this views_fusion makes use of the table_alias_prefix of views, which prefixes tablenames. that's necessary as views_fusion combines two queries into one. so with prefixed tablenames, the tablename can't be hardcoded to 'node_data_'. $field['field_name'], instead the real used tablename must be used: $field_data['tablename'] - which might be prefixed or not.

I still did not take the time to really review this, sorry.
But I'm not sure how the error reported in the initial post (invalid argument in foreach) could be corrected by a patch that alters the code _inside_ the foreach loop ?

http://drupal.org/node/113714 also reports the 'Invalid argument in foreach() / content_views.inc line 149' error,
when using a calendar View (also reported in comment #4 above).

Not sure if this is related to the Views fusion issue, so I'm not marking any duplicate for now.

the (invalid argument in foreach) error has already been fixed by a views_fusion update. the problem with this error was that due to the views fusion table aliasing: views wasn't able set the $field_info variable any more, so it was null.

the patch just updates the (ungrouped) cck views integration code, so that it works with fused views, too.

Patch committed to 4.7 and 5 branches.

I'm leaving this open if a fix is needed for the 'group multiple values' handler as well.
BTW, there is a similar hardcoded tablename in the argument handler.

Actually, since the multiple code does the selecting from the database it is doing things correctly, the only reason the ungrouped was different was that it needed to pull the value in from the views data and was using the wrong field. Since the data is from the database using the original fieldname like that seem correct.

Also, the queryname is free. no need to build it. see attached patch.

Looks OK.
I'll wait until we get http://drupal.org/node/117621 in to commit the $field_data['queryname'] thing.

Committed - thanks !

there is still one thing broken if one uses views_fusion with CCK fields: the grouping of multiple fields. I just had a look at this issue. Attached is a patch, which makes it working.

The patch changes the handler to use the nid-field of the appropriate node table, if views_fusion is used.
Note: You also need to install the latest views_fusion version to make it work.

The patch applies to 4.7 as well as for 5.x.

This seems more embarrassing. The previous patch for 'non grouped values' was just using sensible vanilla-Views-API stuff.
Adding a 'Views Fusion'-specific code branch is, well, not that clean...

Is this really the only way ? I mean, you must get that issue for every views field handler that uses the $data param ?

I'm not familiar at all with Views Fusion (just browsed through the code), so the following might be plain naive or completely off-spot :
Maybe the views_fusion_views_merge function could set its own handler for the fields - this handler would be just a wrapper that 'translates' the $data param to the expected vanilla-Views form and calls the actual field handler ?

The problem just is that this handler accesses another field, the nid of the view. Obviously there are multiple nids when views_fusion is used, and custom implementations have to use the right one or they'll break as soon as views does aliasprefixing.

So the patch just takes the alias_prefixes of views into account, which views_fusion uses. views_fusion now also adds the used prefix to the $field_data, so that custom handlers can easily identify the right prefix. So does the patch to access the right nid.

As far as I know $data is intended to be the whole data fetched from the db, so I don't think I should filter this one. And then, yes it's the only way I can think of.
There might be also some other handlers for fields or filters with need some little fixes to work with views_fusion, but actually it would be fine to have at least the major custom handlers like this one from CCK working correctly.

Yes, it's an extra line for views_fusion support. But it's a views integration, and views supports views_fusion (by providing it's table alias prefixes since 1.2), so imho a well done views integration should support it too.

Attached is an updated patch - the last one accidentally contained an additional space, which has been removed in this one.

+1 works on drupal 5.0, please commit this. ysched, What exactly is "embarrassing" about this code?

Any idea when this patch might be committed??

Subscribing.

I'm also interested in knowing when this patch might be made, as fields with multiple values won't work for me when grouped.

this won't happen in 4.7... It's time to strongly consider upgrading to D5 and testing the 4.7 migration path and filing issues against D5 upgrade path....