[release blocker] Missing views-mode for picking userreference and nodereference

nodereference and userreference for Drupal 7.x are now maintained separately in the References module: moving issue over there.

@blup Thanks for requesting this.

I agree. It would be great to see the "Advanced - Nodes that can be referenced (View)" option return for Drupal 7 reference fields.

It certainly added a lot of additional functionality to the field.

Subscribing

I've got this feature working for both modules, but I will do some testing/tweaking before I submit a patch.
Also waiting on this views issue to be solved #993982: template_preprocess_views_view_fields is returning notices about undefined property $inline

There is some help output that says "Use the view's "fields" section to display additional informations about candidate users on user creation/edition form." - I don't see how that was allowed for in 6.x, might look into that.

Another piece of help output says "Only views that have fields will work for this purpose." and there is code to prevent the user choosing a view with row style 'node'/'user' - BUT it doesn't make any difference either way since the implementation forces views into using fields, so I think this stuff can be removed.

And there are a few todo's in the code ported over, which I believe I could address, but I won't at this point.

"Use the view's "fields" section to display additional informations about candidate users on user creation/edition form." - I don't see how that was allowed for in 6.x, might look into that.

In CCK D6, the views 'fields' were displayed in the autocomplete suggestions ("textfield w/ autocomplete" widget), or as the options labels ("select" and "radio/checkboxes" widgets)

On a related note : in D6, we use the 'default' display of the view, which is rather unholy.
Ideally, this would use a dedicated Views display type, 'References selection' or something like that.
The field config screen would then only let you select the views that have such displays, and use a secondary select to pick one of the displays - requires a little bit of AHAH/multistep magic, though.

Yeah showing displays is one of the todos. I guess I can make those available - I don't even need ajax, but you can review if you think my approach is sound. As for a 'references' display, it seems proper, but as the lazy site admin I'd have to say; who is going to bother making a dedicated references display? That seems rather inconvenient, it's just more steps for people to take, and there is no benefit internally as the implementation takes over the display with it's own class. They should be allowed to pick whatever display they please. For example, I might already have a display configured that chooses the exact nodes I need for a block - I should be allowed to just harness that.
I can skip the default display too - but if someone sets up a view specifically for view reference, they're not going to have a page/block/feed, etc.. so it seems like more unneeded configuration work. Is there any reason defaults definitely should not be used? In another module I made that uses views for a similar purpose, I inquired about this, and merlin said to skip defaults, but I think I didn't completely explain what I was using the views for, and I would say most of the time users use the default view because it is the easiest one to set up and choose. In a typical views scenario default displays are not used, but this isn't typical. The other consideration to make is that upgrading from D6, people already have it set to use the default display, and if an upgrade path was to be provided to handle this you can't just arbitrarily pick a display, you'd have to stick with the default.

Alright see what you think of this

I noticed something small I missed but I don't have time to address it now. In node_reference_field_info() I've added an empty 'instance_settings' as per this comment but I have forgotten to do the same for user_reference_field_info(). Also I noticed that the default widget for Node reference is a select box, whereas for User reference it is an autocomplete - just thought I'd point that out.

- empty 'instance_settings' : not needed (see my reply over there)
- default widget : true, autocomplete probably makes more sense

I've removed the instance_settings, and changed a few comments that mentioned old function names.

I lack permissions to administer a patch. When will the patch be added in a module update?

Subscribe

Please give the patch in #10 a go if you want this issue solved. I've made some bold choices in the implementation so you guys will have to see if it's suitable.

Hi,

After applied the patch (by hand, but I think I did it correctly), I got the views option to show up. I was even able to select an option (yay!).

However, when I go back to edit that option, I get this error "Fatal error: Call to a member function get_option() on a non-object in /hermes/web08/b1277/moo.isnitnet/sites/all/modules/views/includes/view.inc on line 2000"

Thanks for working on it! It's quite useful.

FWIW, only patches with Unix-style line endings are supported by the d.o. patch bot, which was enabled yesterday for References. Part of the patch in 10 were in DOS format and parts in Unix format. Rerolled.

I have the same problem as shavynel #14. I have the the latest view 7.x-3.x-dev version (15-01-2011) installed and the latest References dev (15-01-2011) versions installed with the patch in #16 applied.

In node_references.module line 680-681:

// We add a display, and let it derive from the 'default' display.
$display = $view->add_display('node_reference_views_plugin_display');

It seems that the new display is not correctly derived from the 'default' display, a lot of the properties are missing. The get_option() error is caused by the missing $view->display[$display]->handler property.

That sounds really familiar, I think I had the same problem during development of that patch
#969834: Fatal error: Call to member function get_option() on a non-object in views/includes/view.inc on line 557
But it went away once I updated the .info file with the views handler stuff

You may have to clear caches or resave the view or something?

I checked the .info file and it seems that Eclipse forgot to apply the changes in the patch to the info file.

After adding the following in the .info file everything worked:

files[]=includes/node_reference.views.inc
files[]=includes/node_reference_views_plugin_display.inc
files[]=includes/node_reference_views_plugin_style.inc

Sweet! Cleared the cache and had to fix #993982: template_preprocess_views_view_fields is returning notices about undefined property $inline, too, but it seems to be working now.

That advice about patching #993982: template_preprocess_views_view_fields is returning notices about undefined property $inline worked. After implementing that patch, this thread's patch works great.

Just a follow up to my previous post in #21.

I seem to be having formatting problems with the autocomplete dropdown using this patch with node references. Inline fields are coming back with \n after each field. Is anyone else experiencing this?

I've added a picture and here is the array being returned:

{"Vacant [nid:1]":"\u003cdiv class=\"reference-autocomplete\"\u003e \n Vacant \n \u003c\/div\u003e","Tom Kovach [nid:11291]":"\u003cdiv class=\"reference-autocomplete\"\u003e \n Tom Kovach - \n Delaware \u003c\/div\u003e","Dennis Vachon [nid:13835]":"\u003cdiv class=\"reference-autocomplete\"\u003e \n Dennis Vachon - \n New Hampshire \u003c\/div\u003e","David Litvack [nid:15379]":"\u003cdiv class=\"reference-autocomplete\"\u003e \n David Litvack - \n Utah \u003c\/div\u003e","Robert Vacanti [nid:22279]":"\u003cdiv class=\"reference-autocomplete\"\u003e \n Robert Vacanti - \n New York \u003c\/div\u003e"}

This is happening in both in bartik and garland themes.

jcarlson - yeah actually, each field goes on a new line for me too. :/

Seems the problem comes from the PHP function json_encode() it seems to turn
</span> - <span
into
<\/span> - \n <span

But I can't replicate it by passing my own data into json_encode(), I only see it happen with the $matches var in node_reference_autocomplete()

Hmm I wonder if it has to do that #993982: template_preprocess_views_view_fields is returning notices about undefined property $inline patch?

Update:
the - seems to originate at line 712 of .../sites/all/modules/contrib/views/theme/theme.inc

  if ($view->display_handler->get_option('sitename_title')) {
    $title = variable_get('site_name', 'Drupal');
    if ($slogan = variable_get('site_slogan', '')) {
      $title .= ' - ' . $slogan;
    }
  }
  else {
    $title = $view->get_title();
  }
  $vars['title'] = check_plain($title);

I bet the new lines are being created in that file.

What is stranger is that that - only occurs when you use Node: Title. If you do not include Node: Title, but include other fields, the node title prints as Title: Node Name below the others.

OK if you var_dump the rendered output from views, it does actually have the line breaks in it. Obviously they usually get ignored.

The problem come from the file views-view-fields.tpl.php

<?php foreach ($fields as $id => $field): ?>
  <?php if (!empty($field->separator)): ?>
    <?php print $field->separator; ?>
  <?php endif; ?>

  <?php print $field->wrapper_prefix; ?>
    <?php print $field->label_html; ?>
    <?php print $field->content; ?>
  <?php print $field->wrapper_suffix; ?>
<?php endforeach; ?>

See the empty line halfway through the code? If you remove that, the line break goes away.

Should we file a patch with the views module, or is this something we should address on our end by stripping new lines?

No idea. For now... marking this back as needs work. Will continue to tinker with it.

subscribe & thank you for your work on this module.

I'd say we can hardly ask Views to remove all linefeeds in its templates to support our use case. IMO we're better off finding out why \n gets interpreted when placed in the HTML for the autocomplete suggestions.

in modules/system/system.base.css

#autocomplete li {
  background: #fff;
  color: #000;
  cursor: default;
  white-space: pre;
}

So another option is to override that CSS through this module and change white-space to something like 'normal' or 'inherit'.

off the top of my head:

div.field-type-node-reference #autocomplete li {
  white-space: normal;
}

Sounds reasonable

#16: references-missing-views-945004.patch queued for re-testing.

edit: just re-running the test because i can't seem to get the patch to apply to either the latest 1.x or 2.x dev releases. was wondering if something had changed and the patch no longer cleanly applied or if it was something bad on my end.

Going through the queue to identify release blockers.

Again, many thanks @danielb for kicking this.

I did not reply #6 regarding the use of the 'default' view display vs. an explicit, dedicated 'references target' display, but I do feel strongly about this.

On any real world site it's easy to end up with 20-50+ views. Managing them, maintaining them, figuring out which does what and is used where can become tricky. Displays are what tell you where your view is used : page, block, node 'component' through views_attach, custom code through http://drupal.org/project/embed_views (so basic and dead simple it would rightly belong to the display types shipped in core Views, IMHO). I'm a sucker for the "one display for one destination" motto :-).

Direct use of the 'default' display is plain bad practice, isn't how Views was designed, and shouldn't be encouraged - let alone having a feature that *forces* you to use the 'default' views as noderef does in D6...
For that matter, the recent brainstorms about Views UI reshuffle (see #977062: Views redesign part 2) even consider 'hiding' the notion of 'default' display to basic users.

I agree that this adds one manual step for D6 migration - easy step : just create a new display from the default. This is IMO largely mitigated by the fact that Views and CCK/Field migration *will* require manual admin intervention anyway. So quite to the contrary, doing the change now is in fact a better timeframe than any other.

We can even temporarily provide some easy BC layer that uses the default display if no explicit display is provided in the field settings, but prevents you from submitting the settings form if you don't pick a display.

This being said, I do intend to spend some time with the patch at some point :-/, and jump in for this 'display type' thing.

Side note @jyee : the patch doesn't apply because of recent minor changes in the .info files.

Straight reroll.

Just had a quick browse through the patch I've made and even now there are things I would do differently.

The function node_reference_views_display_title() for example can be simplified

<?php
  $view->set_display($display_name);
  $display_title = $view->get_title();

  if (!$display_title) {
    // No title, we have to construct a title.
    $display_title = ucfirst($view_name) ." ". strtolower($view->display[$display_name]->display_title);
  }
?>

Just thinking out loud here.

This might not even be relevant if you change whether they can picks displays, or store the display setting separately.

@yched, thanks for the reroll, it applied without any errors.

One problem however is that it inserts 2 function declarations for node_reference_views_api() (line 405 of the patch) and user_reference_views_api() (line 896 of the patch). The first function declaration for each is correct.

Also, if anyone is applying the changes manually, in hook_views_api declaring the api as
'api' => '3.0',
appears to be invalid. It causes the plugin files not to be included, which leads to broken handlers and the "Call to a member function get_option() on a non-object in /views/includes/view.inc on line 2000" error. The api must be declared as a number (as it is in the first of the two hook_views_api calls):
'api' => 3,

One other documentation bit for anyone who finds this thread:
The view needs to include the node id in the returned fields. If you don't have the nid (e.g. only use the node title), you'll get the following php notice:
Notice: Undefined property: stdClass::$nid in node_reference_views_plugin_style->render() (line 24 of /sites/all/modules/contrib/references/node_reference/includes/node_reference_views_plugin_style.inc).

The reference will also only contain one option (as the array will continue overwriting the only array element when it builds). I'm assuming the same problem will occur for user references.

It might be nice to add an error handler in node_reference_views_plugin_style.inc to validate that $row->{$base_field} is set.

@37 - oh you may have just solved #969834: Fatal error: Call to member function get_option() on a non-object in views/includes/view.inc on line 557

I was able to apply this patch to the dev version of the code with a few manual tweaks. I then followed the instructions in #37 to remove the duplicate hook_views_api() calls. I also found a duplicate hook_field_views_data() call at the bottom of each file (not sure if that was an issue with the patch or how it was applied).

I was then able to create a simple view with a nid and title, create a node reference that used that view with an auto complete widget. Seems to be working great.

However, when I changed the widget to a select box or checkboxes, I got the following error:

Notice: Undefined property: stdClass::$inline in template_preprocess_views_view_fields() (line 207 of .../sites/all/modules/views/theme/theme.inc).

When saving a node that uses the node_reference field with the auto complete, I got theerror twide (with two items):

Notice: Undefined property: stdClass::$inline in template_preprocess_views_view_fields() (line 207 of .../sites/all/modules/views/theme/theme.inc).

This was using both the alpha1 and dev version of views from Feb 8 (note that with dev the line moves to 213).

Hm, it does seem my reroll in #35 had lots of cruft from other patches. Sorry about that.

Here's a tentative reroll after #1046886: [release blocker] Use the 'many_to_one' views filter handler and #962694: [release blocker] Make Node Reference Relationships Work in Views, which introduced a wrapper "references.module" as a common dependency for both noderef and userref modules. This module currently holds the views handlers common to both modules (and in the future can host later code factorization - that's another story).

For now
- relocated the style and display plugins introduced in this patch over to references.module,
- accounted for comments #36, #37
- renamed a couple things.
That's all I could do for tonight. Notably : I did not actually test anything yet :-)

Busy days currently, so I can't really tell how fast I'll go on this, but this patch is #1 on my list.

subscribing...

Been working with yched's #41 patch. Looking great so far.

Several observations/questions with this patch:

1. The problems I was having with inline fields in #22 is fixed.

• Setting field elements and labels to "None" does work well for inline fields.
• Setting field elements and labels to "Use Default" allows for information to break on to the next line (in Bartik theme). Good to have that option for multiple lines.

As always... thanks for working on this.

Just following up on my comment in #36 about setting the title of a view/display. It is possible that someone can set their view's title to <none> and this case isn't handled... although I don't know if it's normal to use <none> when you can just leave it blank.
Someone mentioned this in the View reference issue queue. But I don't see anything in the Views UI that says to use <none> and the only reason it appears to work is that the title gets interpreted as invalid HTML by the browser and nothing is shown.
Possibly consider strip_tags() on the title before checking it?

With the latest Views and References builds, the patch in #41 fails to work. The patch did not cleanly apply (references.info did not have the two new 'files' values) and I cannot edit reference fields after they've been created. Once the field is added to the content type, if I click its edit link all I get is a blank white page. Also, if I add new content (of a content type that has a node reference field), the select list doesn't show up.

Following up on my comment in #40: the minor notice issue about $object->inline is addressed in views (See #993982: template_preprocess_views_view_fields is returning notices about undefined property $inline). Sorry for the extra noise.

subscribe

I couldn't get more than ten results until I made the change below. Cumulative patch attached.

--- a/sites/all/modules/references/node_reference/node_reference.module
+++ b/sites/all/modules/references/node_reference/node_reference.module
@@ -744,7 +744,7 @@ function _node_reference_potential_references_views($field,

// Limit result set size.
$limit = isset($limit) ? $limit : 0;
- $view->display_handler->set_option('items_per_page', $limit);
+ $view->display_handler->set_option('pager', array('type' => 'some', 'options' => array('items_per_page' => $limit)));

// Get arguments for the view.
if (!empty($field['settings']['views']['view_args'])) {

@catmoleman,

I'm using the alpha release of views and an up-to-date cvs checkout of the dev branch of References.

subscribe

• The patch in #48 forgot to include the the two new files from the patch in #41.
• The patch in #48 also needs to be applied to user_reference.module.
• Confirmed that the NID needs to be included as a field in the view (just exclude it from display).
• +1 for a custom display for node references. Perhaps it could auto-add the NID?

@joelstein

Confirmed that the NID needs to be included as a field in the view (just exclude it from display).

Strange, I didn't need to add the NID to get patch #41 to work. Perhaps it is something added by matt2000's #48 patch?

subscribe

I didn't need the NID at all.
This is just a combination of #41 and #48, no credit for me when this goes in.

Hello, I'm new to Drupal, but I think this feature request and patch is about allowing a User Reference with custom User field values? Maybe I'm looking at it the wrong way. Is this patch helping?
What I am trying to achieve is: Add a User Reference field in my "Photo" content type, and have the SELECT list only list Users where custom field 'type' is 'photographer'.

Thanks for any help.

mattab: Yes, that's what this patch will help you accomplish. You first create your view of users, and then setup your field to use this view to drive the allowed options.

While testing out this code, I had to add a page display, which prompted me for a path.

+++ b/references.module
@@ -12,5 +12,43 @@
+        'no ui' => TRUE, // Programmatic use only.

It might be useful to offer this display as an option.

Any thoughts?

For the record : I'm hoping to give the final push on this in Chicago - no chance I can get to it before that, though :-(.

Hello, new to patching, so not sure if I've done something wrong. I've got References 7.x-2.x-dev installed, and I tried installing the patch from #54. I put that patch into the root References folder, and in a command line put it 'patch -p0 < references-945004-54.patch'. I then got a message 'can't find file to patch at input line...' and then I was prompted to enter a file to patch. I put in each file I was prompted for, but references.info gave me a message of 'hunk #1 FAILED at 5'. All the others seemed to go through OK.

But now, when I try to edit a content type and click 'manage fields' then add a new node reference field, I can see the new area 'View - nodes that can be referenced'. I have a problem, after choosing a view from this, and clicking 'save field settings', I just get an empty white screen!

Is this because the patch didn't seem to apply completely? Or is it a bug?

@59, try `git apply references-945004-54.patch`, or `patch -p1 < references-945004-54.patch`. Then make sure both references and node_references are enabled, and clear your caches.

@tim.plunkett - thanks for the tip! I don't have Git, so I tried 'patch -p1 < references-945004-54.patch'. However, I received the same message for references.info: Hunk #1 FAILED at 5. The other files seemed to patch properly...

@jbucks: Hey Justin, the reason you are getting these errors is because the patch was created against an earlier dev version than the one you are trying to apply it to. This is quite common with dev versions since they change over the development circle and the patch lines that need to be added/removed get moved around. In such cases, you can try to apply the patch manually (...it's pretty simple: remove the lines that start with a "-" and add those that start with a "+").

@klonos: Thanks very much! So far adding the patch manually seems to have worked! It's good for me to know how to do that, so I appreciate your tip and the link.

No problem mate. I was shown when I didn't know and was asked to spread the knowledge. So, now that you've learned too I ask the same from you: next time you see someone asking the same question, point them to the right direction ;)

@klonos: will do, I'm actually in the process of doing so right now! =)

This incorporates my idea from #57, which allows you to create a references display, which I find very useful.

Is this still being worked against 1.x or has it moved to 2.x?

7.x-2.x

...thought so ;)

subscribe

subscribe

tested patch #66 on 7.x-2.x and found that it somehow not solved the issue found here:

relations works well for "title" field and all other Node: * fields but not for custom Fields: * including "body" field

anybody have the same?
suggestions?

additions:
views ver 3.0-alpha1
references ver 7.x-2.x-dev(git) with references-945004-66.patch

two content types with relation created

view use relation
nid argument used without relation
fields "title", "body" and "features" with relation set for displaying

P.S. seems like this issue from http://drupal.org/node/962694 ))
but current views dev use new ui and it's not so stable...

Hi casualuser.

At first glance I'd suggest using the latest Views dev version instead of 3.0-alpha1. A lot has changed, added or fixed in Views since that alpha release so that could be the culprit.

jcarlson34, thx for tip
going to try dev views

subscribing!

btw, will other field values be available to the view, by chance? It would be great for OG integration (e.g: limit nodes using selected group audience). I'd be glad to try to help on that.

latest Views dev version is very unstable at the moment, i noticed many problems and errors when i tried it on a test site yesterday

Were you trying the 3.x or the 2.x branch Max?

...you do know that you can help make views more stable by identifying these issues one-by-one and trying patches provided for them. If there is no issue created yet for a problem you noticed, you can always report it.

@klonos: there is no 2.x release for views-7.x so the answer is 3.x

actually i'm helping wherever i can, btw about views, it seems to me that they went too far without creating a release. i don't understand why they are changing the UI when we even don't have a beta release for 7.x, many modules are depending on views and IMO they had to focus on functionality first, and then improving the UI.

You're right Max, I got confused because I currently have both D6 and D7 setups. Still, you should follow up on these issues you've been having instead of 'giving up'. I feel you when it comes to the release thing, but along the way I guess I and kinda got used to having dev versions of -almost- everything ;)

Subscribing

Patch in #66 no longer applied, here's a re-roll...

There was a weird `+ t(` stuck in the middle of that patch, plus it still added CVS Ids in the two new files.

I need a version that can be applied by drush make, so I've re-rolled #82 with --no-prefix.

Drush Make issue to support proper patches: #745224: Apply patches from git diff and git format-patch

ugh, sorry that last patch doesn't apply, don't know what I'm doing wrong :[ Will try to figure it out - in the meantime if someone else can roll a patch that can be applied both through git apply and also by drush make, that would be awesome

Actually the patch in #83 is fine - you just have to make sure you're patching an actual git clone of the module ;-)

#83: references-945004-83.patch queued for re-testing.

Subscribing and waiting, rather impatiently:).

Sorry for letting this unattended, I didn't get much drupal contribution time lately.

I'm planning to get get this over with asap, but first I'll need to wrap my head around the activity since my patch in #41. Looking at patch #84, i can't really sort things out.

subscribing. I have some test results:
I tested #83, but i had no relevant views. I compared it with #41. yched apparently found otherwise in #89, but i hardly could find any difference between them.
Then, I checked the code, and applied this:

       $form['views']['view'] = array(
          ...
-        '#disabled' => $has_data,
          ...
       $form['views']['view_args'] = array(
          ...
-        '#disabled' => $has_data,

Now I can find and choose views. Has something to do with #1078308: Field is locked for adding a new content type that should be available for reference?
But I still can't set the arguments. the form element is greyed out. After flushing cashes, also the 'View arguments' box is OK.
I changed a node with node reference (multivalue) field with Widget = Select list ==> This is good!
I switched the widget to Checkboxes/Radios and tested again ==> This is good!
I switched the widget to Autocomplete and tested again ==> nope, is it only for picking references?

I don't know how specific this feature is: It would be nice if it could work with Nodereference URL widget and Autocomplete Deluxe (for references) (when it is released).

I change the title to narrow down the scope: it is not for displaying references, only for editing/selecting/picking with select/radios.

Resetting title. The feature is supposed to be fully independent from the widget that is configured for the field instance.

subscribing

@yched,

Check out #57 and #66, I found it useful to allow creating a display specifically for references.
Other changes, can't vouch for them :)

Not sure if this is related to this issue, but whenever I use a field of type user reference in views, I get a broken or missing handler error. Is this still being worked on? It used to work before I updated to latest views and references modules.

But now I keep getting broken or missing handler in the relationships for views.

I edited my testresults in #90: "After flushing cashes, also the 'View arguments' box is OK."

I'm just starting to test this, but #82 (and it appears also #83) introduces a dependency on the main references.module to both node_reference.module and user_reference.module without adding a declaration of the dependency in the .info files.

Re: my own #89 : "I'll need to wrap my head around the activity since my patch in #41. Looking at patch #84, i can't really sort things out."
Duh, I forgot that I had continued to work on this after rolling #41, I got confused by the large diff between the followup patches and the state of my own local repo. Never mind :-p.

I merged in the couple changes from the recent patches, and rolled an up to date patch.
The new patch changes the machine names of the display and style plugins, folks testing the patch will probably need to recreate the supporting views :-(.

Still quite a few todos, but mainly polishing, this should mostly work.

Right now, if a user does not have an eligible view, there is no display under the "Views - Nodes that can be referenced" section of the field edit form. It would be a great help to new users if we included text along the lines of:

No eligible views are available for this module. For a view to be eligible, you must add a display of new "References" type

@alakon: very true. That's on my list.

To apply patch in #97 is this correct:

Save references_views_mode-945004-97.patch in modules/references
Command line: patch -p1 < references_views_mode-945004-97.patch

?

@tigeda, for that patch it'd be `patch -p0 < references_views_mode-945004-97.patch`. That patch was rolled with the option of --no-prefix, to mimic old style CVS patches.

thanks @tim.plunkett

I did get an 'Hunk 1 failed' response, but manually added the two lines to references.info

references.info file (please advise if incorrect):

name = References
description = Defines common base features for the various reference field types.
package = Fields
core = 7.x
dependencies[] = field
dependencies[] = options
files[] = views/references_handler_relationship.inc
files[] = views/references_handler_argument.inc
files[] = views/references_plugin_display.inc
files[] = views/references_plugin_style.inc

; Information added by drupal.org packaging script on 2011-04-07
version = "7.x-2.x-dev"
core = "7.x"
project = "references"
datestamp = "1302135802"

running the patch:

public_html/sites/all/modules/references]# patch -p0 < references_views_mode-945004-97.patch
patching file node_reference/node_reference.module
patching file references.info
Hunk #1 FAILED at 6.
1 out of 1 hunk FAILED -- saving rejects to file references.info.rej
patching file references.module
patching file user_reference/user_reference.module
patching file views/references_plugin_display.inc
patching file views/references_plugin_style.inc

I'm getting a notice on the 'Field Settings' screen of node reference autocomplete field.
Notice: Undefined variable: result in references_get_views() (line 86 of /home/site/public_html/sites/all/modules/references/references.module).

Also no views are listed under the 'Hide Views - Nodes that can be referenced' collapsible.

Ive added fields: NID, title, & image to my view. Is there something I am missing in setup?

@Tigeda : yup the warning is "normal", my bad. I'll fix that in the next patch. Meanwhile this shouldn't break any functionality.
Also, only views having a display of type "References" are eligible. I'll add a help text making that clearer (see #98/#99).

@yched thanks for pointing out the display requirement. The notice is also removed now I've added that display.

Sorry if I'm pesting, but I don't get any results when typing into the autocomplete. This is my first use of views in D7, do I have to pass arguments to the view using the field provided in Autocomplete Field Settings screen? If so, what, nid?

Also do I have to setup arguments in the view the same as D6?

sub

subscribe

Updated patch.
Fixed the remarks in #98 and #103, and fixed a couple @todos.
Still a couple @todos to address, but we're getting there.

@Tigeda : no, you don't need to set up the View with any argument. However, you need to make sure the 'References' display uses the 'Reference list' style (that's called 'Format' in the 1st column in Views new UI). By default, the display is created with 'Unformatted list' format. I'm still struggling to find a way to use the correct format by default.

oops, empty patch.

@yched , thanks again for the help, and your work on this module.

Here is an error that comes up after creating a node with an autocomplete field (using views output):

Notice: Undefined index: field_machine_name in node_reference_autocomplete_validate() (line 534 of /home/site/public_html/sites/all/modules/references/node_reference/node_reference.module).

@Tigeda : make sure you use the latest -dev code. Line 534 in node_reference.module seems to be a comment in the current code.

[edit : are you using the noderef field within a 'field collection' ? http://drupal.org/project/field_collection ]

Created #1125906: Display created with wrong 'Unformatted list' style in the Views queue.

Patch #109 is working great for me so far with the latest dev. No log errors found so far.

Does the 'views arguments' for 'Views - Nodes that can be referenced' work? If so, can someone provide an example of what format to input to pass it to the view? For example, arg(1), %1, node:title, etc...

subscribe

@yched Yeh my nodref is within a field collection.

@jcarlson34 : the 'views arguments' are supposed to work (not really tested). But this only accepts constant string values, not token-like placeholders, which admittedly, seriously restricts the scope of the feature.
Adding 'tokens' has been a long running feature request back in CCK, I must confess I couldn't really follow the threads while working on core D7. Main issue is that, when on 'create node' form, we don't have a real $node yet (no $nid, etc). Out of the scope for this patch.

@Tigeda : Ok, then please try with the latest -dev code, I committed a fix yesterday (#1126566: autocomplete widget doesn't work in field_collection widget).

Thanks for the explanation yched. I've been wondering about that feature for a year or two and never could get it to work.

For the scope of this patch though, the new references display is still working great on my site. Thanks again for working on this.

Subscribe. Great to see how much progress has already been made here!

For those following at home : I pushed the code to the '945004_ref_by_view' topic branch in the references.git repo.
I'll try to keep the branch updated as I post patches here. Although, again, we're getting there, it "shouldn't" (tm) take much longer before I can commit to the official -dev branch.

Updated patch (and git branch) :
- 'References' views displays are automatically created with the correct 'Reference list' format (thks dereine & merlinofchaos for the tip) - see comment #108 above
- internal refactoring, factorize the rather complex views management into references.module, to reduce code duplication between node_ref and user_ref modules. There would be further clever factorizing to be done, but that's not necessarily for this patch.

...this is great! Another 'glitch' fixed. We're getting there! Thanx Yves ;)

I have this working, however I noticed that if I filter the list usings views, some characters are shown as html. e.g an apostrophe is shown as #039. Can this be fixed?

@prjcarr : good call - fixed in the '945004_ref_by_view' git repo, will be included in the next patch.

Subscribing, and thanks to everyone who is working on this!

@yched

I've installed the latest patch & the views display is automatically selected with correct list style. Admin-side it all seems to be working great, however (not sure if this has been covered): I'm not getting anything displayed for the reference field.

Note I am using ref. field within a field collection.

I have also worked with the patch in #121, and it is performing well. :)

YAY! :D

I had a bit of confusion whilst trying to get it setup though, you need to add a Display of 'References', just as you would a 'Page' or 'Block' or 'Attachment'. (attached is the example).

Another note regarding comment #126 by Tigeda, the Field Collections module at the moment does not display fields on the Add/Edit Bundle (content type) screen. You can process the values, and save them programatically but otherwise there is no way to add values through the interface currently.

If you wish to use this functionality, with a programmatic form, you could do something like:

    global $user;
    $organisations = my_module_get_organisations($user);
    $field_name = 'field_account_ref';
    $entity_type = 'node';
    $bundle_name = 'department';
    $field = field_info_field($field_name);
    $field['settings']['views']['view_args'] = implode('+', array_keys($organisations));
    $instance = field_info_instance($entity_type, $field_name, $bundle_name);
    $langcode = LANGUAGE_NONE;
    $items = array();
    $form['step_1'] += field_default_form($entity_type, $node, $field, $instance, $langcode, $items, $form, $form_state);

In the field collections module you will find a case on how to save the submit values into a field_collection.

New patch (+ pushed the code in the '945004_ref_by_view' git branch).

Main difference is the reorganisation of settings within $field['settings'], to decouple them from the current organisation of the settings form (view and display selection munged in single one widget, args as a comma-delimited string). When creating a field programmatically (or looking at the exported definition of a field), the settings should come in their 'natural format', and not be tied by the shape of the settings form.

// Previous versions of the patch :
$field['settings']['views']['view'] = 'view_name:display_name';
$field['settings']['views']['view_args'] = 'one, two, three';
// Now : 
$field['settings']['view']['view_name'] = 'view_name';
$field['settings']['view']['display_name'] = 'display_name';
$field['settings']['view']['args'] = array('one', 'two', 'three');

Also attached is a php snippet (to run in devel.module's 'Execute PHP' at page devel/php) to automatically adjust existing field definitions accordingly, for people that have been testing the previous versions of the patch.

TODO : take care of the settings for fields being migrated from D6 with CCK's content_migrate.

I am very new to Drupal and probably have no business playing with patches, but I'm excited to be testing out the progress of this module and its relationship with Views. But I need a little hand-holding to help figure out how to get it up and running, if anyone has a moment to help.

I've applied the patch to my test site but get the following error when trying to create a new 'Reference' display for a view:

Notice: Trying to get property of non-object in views_ui_get_display_tab() (line 1408 of mysite.com/modules/views/includes/admin.inc).

Fatal error: Call to a member function get_option() on a non-object in mysite.com/modules/views/plugins/views_plugin_style.inc on line 37

Is it obvious based on this information which noob mistake I've made?

Thank you, in advance, for a basic lesson in patching.

@ethos_bass : not sure. Make sure you have the latest state of Views 7.x-3.x code ?
Make sure you clear your caches after applying the patch ?

New patch (+ pushed the code in the '945004_ref_by_view' git branch). We should be good to go now.

Handled the case of noderef / userref fields migrated from D6, polished the corresponding user facing text ("you need to create a new 'References' display in your view"), and took care of the last remaining @todo's.

I'll wait a couple days before I commit that to the main 7.x-2.x branch, and tag an official release at last.
Probably still 'beta' for now, I'll need to check the state of issue queue first.

reroll after recent commits ?

subscribing

Hum. Testbot requires patches with a/b prefixes now ?

And committed :-)

Thanks everyone who helped testing, rerolling, etc..., and special thanks @danielb for kicking this off.

Setting to 'fixed'.
+ I deleted the 945004_ref_by_view git branch

Wow that is great news. Congrats and thanks to everyone (yched especially) who helped bring this amazing feature to the References module and to Drupal 7.

Nice. Will we be seeing a 1.x release (at least a beta) soon?

@geerlinguy : yes :-)

Thank you, guys!

Congrats, for the amazing work so far, and all the very best. Eagerly waiting for the 2.x.

I am having an issue.

I am using the modules
References ---- 7.x-2.x-dev ---- 03-May-2011.
Views ---- 7.x-3.x-dev ---- 06-May-2111. (First started with 7.x-3.0-beta3 ---- 28-March-2011, stuck with issue "the node reference field was not listed"
in the views relationship options and on researching found that should change to new version and installed latest dev version.).

I have two custom content types

1. icon having fields title, Icon_image as type image.

2. product having fields title and product icons.

Here I have choosen "node reference" as the field type for the "product icons" field, and set the settings like "Content types that can be referenced" to "icon",
"Views - Nodes that can be referenced" to "icons selection view - References".

Then, I have created a refrence view "icons selection view", having :-
fields -- Content:Icon_image. and set the settings ---- Relationship -- "field_product_icons" (Which I suppose the name of the relation I have created),
Fomatter -- "Image", Style -- "Thumbnail", Image link to -- "Nothing".

Relationship -- Choosen Content:product icons, and set the settings ---- In the For select box: selected the "This references(override)", and checked the "Required this
relationship" check box.

Now, my issue is :- After setting the above mentioned settings, the view is not displaying anything. If I unchek the "Required this relationship" check box and select
in the Relationship options and "Do not use any relationship" in the Relationship select box of the field option, then the list of icons are displayng in the view.

But, I badly need this relationship to be working for this view, because unless this works the list of icons will not be displayed in the product content type while creating
product node.

Was not sure whether to post this here or in the views queue, so posted in both.

Any or all guidance will be a great help for me.

Thanking you all,
Pradeep.

subscribe,
thank you for your great work!

@kpdru : You've just hijacked the issue - please don't do that :-). That's at best (if done unknowingly, which I assume is your case) very confusing for people following the thread (and there was a lot), and at worst (if done knowingly, which I assume is not your case) *very* rude.

This thread was about adding back a missing feature ('task') and it is now 'closed'.
Your question very much sounds like a 'support request' for using views and / or nodereference, which would be much more suited in the forums.

FYI : I just rolled a beta release (straight to beta2, because I messed the beta1 tag...)

Great work, thanks.
I will test soon.

I am hesitating to bring this forward in this late stadium of the development, and wether to create a new issue:

This option 'NODES THAT CAN BE REFERENCED' is now a global field-setting. However, a single field can be used in different content types/entities, and the possible referenced nodes (= view) can change from content type to content type. You could create a separate field for every content type, but that is not the way to go..

Can this option be moved from the global hook_field_settings_form to the local hook_field_widget_form ?

Nope, some places (e.g the views filter for a noderef field) need to know the eligible nodes for a field, independantly of any specific field instance. Those kind of 'set of possible values' are generally handled at the field level.

Side note : setting back a fixed issue to 'needs work' can be ok if the committed patch is buggy (although on thread with ~150 comments, opening a new topic might be a better option), but could be perceived as kind of rude for a feature request ;-)