Hello,

I've got a content type with a node reference field. I've got a view that is supposed to be delivering the nodes available to be referenced. The view works fine on its own, but in the node creation form for that original content type, the nodererence isn't honoring the "items to display" value set in the originating view. This seems similar to the problem reported in #263936: Items per page not affecting list of nodes in referncednodes field, but instead of the default 10, it seems to be treating the view as if there were no limit (i.e. items to display = 0). Moreover, that bug was patched a while ago, so this likely isn't the same root cause.

Any thoughts?

Comments

zwhalen’s picture

zwhalen commented
Title: A Nodereference field isn't honoring the items per page limit set in the "allowed values" field » A Nodereference field isn't honoring the items per page limit set in the "allowed values" view

By the way, I tried this out in a couple of different installs, with different reference widgets (select list, radio) and get the same bug every time.

zwhalen’s picture

zwhalen commented

OK, I think I got something figured out. I'm not submitting it as a patch, though, because it's probably wrong somehow and I'm only barely sure I follow the logic here at all.

So it seems that the problem is in _nodereference_potential_references_views, which includes $limit as a parameter. When that function builds the new view display, content_references, it just looks for that $limit value instead of borrowing it from the 'default' display like I think it's supposed to.

The line in question is 864, which I changed from this:
$limit = isset($limit) ? $limit : 0;
to this:
$limit = isset($limit) ? $limit : $view->display['default']->display_options['items_per_page'];

That feels ugly to me, but it does seem to work as I expected to.

madjr’s picture

madjr commented

same problem here

i will check your fix

apart from limiting quantity to 10 (so that it doesnt overwhelm the user), i also want to add an ajax pager, which is another thing is not allowing.

and the different styles: table, grid, etc. are also not being allowed.

node reference and views integration in the node edit page/form = incomplete/buggy.

i also wonder what would be the logic of not allowing a node/teaser view to be displayed..

hopefully we can get a fix for these soon

DeFr’s picture

DeFr commented
Version: 6.x-2.8 » 6.x-2.x-dev
Category: bug » support

Generaly speaking, the fix mentionned in #2 isn't a good idea: _nodereference_potential_references_views when called without $limit is supposed to return all the allowed values ; this means that a form submission of a node with an item that's not returned by _noderefernce_potential_references_views will be rejected.

Consider the following scenario:

  1. You create a node A, of a type that as a nodereference field in it
  2. For some reason, the views content change (for example, your view is listing nodes of a specific content type sorted by creation date, and a bunch of nodes of this type are created, pushing the olders one on page 2)
  3. You try to edit node A to fix a typo in the title

In this case, you're pretty much screwed: the value that was in the nodereference field can't be used, perharps isn't even shown depending on the widget.

To get something stable, that works reliably, you have a few options:

  • If you want to use all the power of Views or there's a lot of nodes that can be referenced, but you want to present them in a user friendly manner, use something like http://drupal.org/project/noderelationships and its nifty "Search and reference" module
  • If you want some simple widgets (select / radio) on the edit form, because you know that there's only a few node that can be referenced, tweak your view so that only those are returned, ever. For example, you could add a "Referencable by XX" numeric field on the content type of the referenced nodes, with a checkbox widget, and add a filter on your view to only return the nodes where its checked. That way, you're sure that content won't become invalid just because new nodes where returned by the view.
madjr’s picture

madjr commented

@DeFr

i will check those

hopefully one might work for us

thanks :)

zwhalen’s picture

zwhalen commented

I still maintain that this is a bug, or at least something that needs to be accounted for in the module settings. When the Views UI includes the option to limit a view to a specific number of results, I consider that an essential part of "The full power of views," so I just want to use that in a context other than a page display. If a view behaves or sorts differently depending on context, that's unexpected and undesired behavior.

In my case, I'm going to have hundreds of possible nodes in the to-be-referenced content type, and my view is going to be filtering that down based on several criteria and then randomly sorting it to 5 possible candidates. I can't count on my users to do that search and sorting themselves, so "noderelationships" doesn't really replace the functionality I need.

I'll accept that my solution isn't the best -- it's just a quick hack -- but surely there's a way to arbitrarily limit the number of nodes that appear in the reference widget? If not, there probably should be.

Renee S’s picture

Renee S commented

I think the issue title says it all: the field should be honouring the items-per-page limit. Right now it's not. I would definitely call this a bug. I have 30 possible reference fields, and I don't think there's any good reason for this field not to use the Views setting, or at the very least return all the items that the view itself returns!

rp7’s picture

rp7 commented

subscribing

Renee S’s picture

Renee S commented
Category: support » bug

Don't shoot me, but... changing back to 'bug'. :)

DeFr’s picture

DeFr commented

@Reinette: From your description, you're not at all hitting this bug, but #505272: The result of autocomplete does not include all instead. This is about CCK displaying all the values if you use either a select / radio / checkbox widget ; if you're hitting a limit, then, that's something else, and I would guess that it's the autocomplete hardcoded limit of 10 dealt with in #505272.

jkopel’s picture

jkopel commented

I have the same issue, and feel that it warrants being called a bug.
My CCK field is using a drop down (not autocomplete) and the view returns 11 results.
My dropdown only ever shows 10.

I feel the node reference should honor the view setting, or at the very least let the content creator know that they are only seeing the first 10 out n possible references.

If my results are a HUGE drop down then so be it. At least they are logical and not arbitrarily limited in some invisible manner.

jkopel’s picture

jkopel commented

It looks like my prior post was a mistake.
The number of items was being set correctly, but there is a problem regardless.
It seems that if you do not have a item limit
i.e. $limit is null and

$limit = isset($limit) ? $limit : 0;

Then the pager plugin is getting set incorrectly, there is a pager being set, and the items per page is then defaulting to 10.

If you force it to not use a pager:

$view->display_handler->set_option('pager', array('type' => 'none'));

Then all is well and you get an unlimited dropdown.
That is pretty heavy handed though, and it should get the pager setting from the default view or something.
Perhaps this should be its own issue...

Renee S’s picture

Renee S commented

To clarify, I'm using a drop-down, not autocomplete.

DeFr’s picture

DeFr commented

Yuck, that's definitely not the intended behavior then. Experimenting a bit though, that's not what I get when using Views 2.12, where setting the limit to 0 does give all the items, but playing a bit with Views 3, the code in CCK's display handler doesn't kick in...

So first of all, can you confirm you're using Views 3 ?

#12 also seems to hint at Views 3 and its pluggable pager more than Views 2.

Azol’s picture

Azol commented

I have a feeling that #998494: Node Reference field always displaying 10 results when using the Advanced View option. [views-6.x-3.x] contains potential solution for this bug (see #2 and #8 of that issue).
If so, let us mark this issue as duplicate and close it.

Renee S’s picture

Renee S commented

I tried both solutions yesterday and no dice. Yes, I'm using Views 3 (though first encountered the problem on Views 2, no idea if it's the *same* problem or just the same symptom, tried some things back when I first encountered it, no dice then either :)

Renee S’s picture

Renee S commented
Status: Active » Closed (duplicate)

D'oh. Error between keyboard and chair. #8 in that issue fixed my problems, once I spelled my module correctly... :)

Probably safe to say it's the same issue.

mirabuck’s picture

mirabuck commented

I've addressed this by creating a module that applies a limit when nodes are being added but not when they are being edited. It's useful if you want to do something like display two random choices on node add but a full range of choices on node edit. You'll find it here: http://drupal.org/project/limited_nodereference

raghugs’s picture

raghugs commented

Hello everybody I am too suffering from this bug.
I have tried to fix this issue by applying jkopel code suggestions
But the.node reference field still shows all references.

I am designing a mobile friendly website.
And trying to implement user selectable related content using node reference.
Using the views output as block to display two related contents per block.
This bug breaks the output badly

I am using views 2 in drupal 6.22