Allowing recursion in 6.x-1.x

I can confirm this patch "worked for me" - I've recommend people use it when combined with view_of_views - I would like to see it included in a release of viewfield (which is a critically useful module I think)

Cheers

Mark.

The code has now changed significantly. Also, a patch only requires enough comments to explain how it works.

Hi there))

Just 2 very quick questions:

- This issue is reported against view_field 5.x-1.4.
Will the patch work equally fine with the current version 5.x-1.5? Can the patch be applied without further changes?

- Why is the patch it not included in the official view_field release?
Is there something one should be aware of when installing the patch?

Many thanks & cheers!

I'm using version 5.x-1.5 and if you add

_viewfield_nodestack_pop();

to your argument handling code, you can stop it from excluding the current node. The assumption would seem to be that you are taking the responsibility upon yourself to ensure you are not including the viewfield itself as one of the fields of your nodes ;-)
Or something...
Anyway, I'm not sure if that's the intended usage but it seems to be doing the trick for me.

The attached patch provides a field setting that lets administrators decide whether recursion is allowed in the viewfield. Recursion is disallowed by default.

My use case is a view that uses the argument node in a relationship, without actually using that node in the view's output. Without a patch, the view's output is always empty when used in a viewfield.

will this work on viewfiled 5.1.5?

IMHO, this would be great to include as a feature, off by default. My use case is to display a gmap view (a map of the current node location).

I am unable to apply this patch to the latest 6.x-1.x-dev version. Is it me or the patch file?

Running CentOS 5.2

patch <viewfield-recursion-165321.patch 
patching file viewfield.module
Hunk #1 FAILED at 82.
Hunk #2 FAILED at 104.
Hunk #3 FAILED at 153.
Hunk #4 FAILED at 200.
Hunk #5 FAILED at 485.
Hunk #6 FAILED at 493.
Hunk #7 FAILED at 503.
7 out of 7 hunks FAILED -- saving rejects to file viewfield.module.rej

For the record, I applied the patch manually and it works great for my use case, showing a gmap map of the current node. I have changed the status to reviewed and tested by the community. Community, in this case, should be defined as someone who knows little.

I manually patched w/ #5 against 6.x-1.x-dev and it seems to work except for one thing.... it doesnt save my default arg's now.

Thats the only bug I've found so far.

My mistake... I wasn't checking "Use a common default value for all nodes if the user does not override it on the node form."

Here is the module and the patch from what I have against D6.

Would it be possible for you to re-roll this patch against HEAD? I'll review it and perform further testing.

Jer

Duplicate issues 418164, 290023, 273084.

I came back to this again because I needed it again, but now the dev is a lot different than the patch and it will be difficult to patch manually even (for me anyways).

I'm kinda sad this didnt make it in way back when it actually worked. If someone has time, please take a look at this.

Why not comment out this code altogether?
///**
// * Implementation of hook_views_query_alter().
// *
// * Prevent views from loading the node containing the view.
// */
//function viewfield_views_query_alter(&$query, &$view, $summary, $level) {
// global $_viewfield_stack;
// if (!empty($_viewfield_stack)) {
// $query->add_where('node.nid NOT IN ('. implode(',', $_viewfield_stack) .')');
// }
//}

This allows displaying the viewfield view(s) on the same node from which it derives its data.
The viewfield views argument is also stored, for instance [author-uid].
No errors so far.

Am I overlooking something? or is this a quick fix to the problem?

subscribe

subscribe

Patch won't apply to latest version. I attempted to reroll it, but something is wrong. No error messages, just not working.

I don't think that allowing recursion is the right answer/solution to (any of) the underlying goals or issues.

This attempt would only be valid and make sense, if Views itself would provide a view type to query fields (and only fields) instead of nodes. So technically, you're building a view to view a single node. While that might make sense for certain edge-cases, it doesn't for the majority of use-cases. Instead, you demand a (new) layer between an entity's fields and their display. http://drupal.org/project/ds might be what you want.

I'm wondering if this will work in my case: I'm adding nodes via a node reference field to another node. These nodes should have a viewfield in them that display other nodes. Right now, the title of the nodes with the viewfield show up in the view, but not the content (the view referred to by the view field). Should this already be working or is this related to this patch. I'm not exactly sure.

Updating title as there's another issue about this for later versions over at #1176828: Viewfield with [node:nid] argument suppresses the node containing this viewfield.