1. Create two node types:
Type 1: Basic - no special fields.
Type 2: Add a multiple nodereference field (type1) to it that allows any Type 1 nodes
2. Add one Type B node and several Type 1 nodes. Reference some of the Type 1 nodes from your Type B node.
3. Create a view where you add your 'type1' field as a relationship and then add the Type 1 nid and title fields using the relationship selector. Add Type 2 nid as an argument.
4. Display your view - you should see all Type 1 nodes that are referenced by a Type 2 node.
5. Create a new node type, Type 3 and add a single nodereference field (selection widget) that uses your new view as its source.
6. Go to the node/add form for Type 3. There is only one option available in the selection list. We would expect all the nodes from step 4 to show.
A little debugging showed that it's because in includes/views/handlers/content_plugin_style_php_array_ac.inc, $base_field is getting set to 'nid' (which refers to the nid of the referencing Type 2 node) instead of something more like 'node_node_data_field_typea_nid' (which is the nid of my Type 1 nodes). If I set $base_field to 'node_node_data_field_typea_nid' in the file I mentioned above, then I see the expected list of nodes from step 4.
Maybe there is a better way to do this (that works), but I haven't figured it out yet.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | noderef-views-relationships-1.patch | 15.77 KB | tauno |
Comments
Comment #1
yched commentedHm. Understandable misconception.
Noderef 'Views mode' allows you to define the nids that the field can reference as being the nids retrieved by a View. This is only determined by the view's filters and arguments, which, roughly put, restrict the selected nodes by adding 'WHERE' clauses to the query.
The view's 'fields' do not come into play here, they're only 'what gets displayed for the nodes that were selected'. In the case of a view used by a noderef field, the view's fields are what gets displayed in the select list or autocomplete suggestions (depending on the widget you picked for your noderef field)
With the view you describe, the nids retrieved are the ones of your Type 2 nodes, not the ones of the related nodes. It just 'turns' out that the view's fields are all on the relationship.
Now, I'm not sure I fugure out what you're trying to achieve in terms of "what can be referenced from where", but you need to build your view so that the 'base node' retrived (without following a relationship), are the ones you want set as 'referenceable'.
Comment #2
tauno commentedOk,
I was starting to suspect what you said in your response. I had hoped that it would use the first 'nid' field in the fields list (even if it was from a relationship node). Could that still be ambiguous?
Would a patch that checks the view fields for the first nid field and uses that (or default to the current logic if none are found) be an improvement for nodereference to make it "relationship" aware? If so, I may be able to submit a patch.
Maybe I can rewrite my view to get what I want another way, but I've had some trouble with getting the filters/arguments right to show:
Type 1 nodes that are referenced by "any Type 2 node that belongs to a specific Organic group (argument 1)" or "a specific Type 2 node (argument 2) that belongs to a specific OG (argument 1)"
It's the "that are referenced by" part that's causing me grief. But, my challenges with views aren't an issue for this queue.
Thanks for the quick response and clarification of how nodereference w/ views works.
Comment #3
yched commentedActually, our 'PHP autocomplete array' row style lacks the exact same feature as the one I filed for Views's built-in 'Node' row style in #327366: Let row plugins follow relationship :-) : you cannot specify that you want to follow a relationship.
Code wise, adding this to content_plugin_style_php_array_ac.inc is no big deal, but this implies some work on the corresponding UI for the noderef 'field settings' form:
1st select the view, then (AHAH ?)-update the list of available relationships to pick from.
This might even require 3 steps : select the view / select the display (we currently always use 'default', which is more of a hack) / select the relationship.
Not personally planning to work on this in the near future...
Comment #4
tauno commentedI've made an attempt to write a patch for this feature, but I'm running into some problems. I've mostly figured out the the UI to select the display and relationship (although I'm still having some AHAH related issues), but I'm having trouble understanding how to use the display and relationship that the admin selects. Not knowing the internals of CCK or Views makes this tough.
The code currently adds a new display to the selected view that uses the custom view plugin in CCK. I'm guessing that I would to alter this so it uses the selected display, but changes the plugin to the one defined by CCK. I haven't been able to figure out how to do this yet. Any suggestions for how to approach this?
Comment #5
drewish commentedyched, I'm trying to build RSS feeds of a node's referenced nodes. In this case you can't use the relationships because it's using need full nodes rather than fields. I think what it would really take would be a second argument handler that does a backlink on a given nodereference field. Any chance of this getting committed? Or should I just stick it in my custom module?
Comment #6
yched commenteddrewish : sounds like this is #327366: Let row plugins follow relationship ?
Another feature feat. request (for noderef, this time) that might be able to get you there is a relationship for backreference (reverse of the one we currently have). Nodequeue, for instance, has it both ways (or maybe it's Tags module, can't remember right now).
Separate issue, though.
river_t: thanks for taking a stab at this. I suggest you post what you have so far, so that we / someone :-) can help if needed.
Comment #7
tauno commentedI figured out some of the problems I was having and got a mostly functioning solution. The attached patch (against cck-2.1) does two things:
Known problems:
yched or anyone else want to take a look and help me refine this patch?
Comment #8
yched commentedOK, many thanks for this, river_t.
I will definitely try to look into this soon, but it might not be before a couple weeks - be warned and don't take it personally ;-)
Comment #9
darren ohTo avoid having to write custom code for all relationships, I recently added this feature to Views Or.
Comment #10
sethcohn commentedHad almost the exact same problem as is described in the original issue. Took a while to find this issue, because the problem wasn't really clear until I tried to debug it.
After debugging, essentially, the problem is, as described: includes/views/handlers/content_plugin_style_php_array_ac.inc, $base_field is getting set to 'nid' (which refers to the nid of the referencing Type 2 node) instead of something more like 'node_node_data_field_typea_nid' (which is the nid of my Type 1 nodes)
Since all of the views come back with nid as the referencing node, the result array is built using the same key (due to the $base_field being identical in all results), ending up with a single result, and the wrong one at that.
This is broken behavior, not just a feature request. As the description of this code says you can 'make a view, and populate a select or autocomplete with it' UNLESS you are looking for items that are already a node references themselves, in which case, you can't use this.
Views Or didn't work for me (same problem, no change - nid continues to be the original node, not the nid of the referenced node).
The workaround for me was to use the CNR module, and put a corresponding node reference on the nodes in question, then make a view that looks for nodes that refer to the original node, and list them. (In other words, reverse the polarity of the neutron flow...) Don't try to build a view of referenced nodes that a particular node references, you must build a view of nodes that reference the desired node - the results are nearly identical looking _except_ that one works, the other doesn't, because one returns all nids=particular node, the other returns nids=referenced nodes.