Add a limit to the number of results in _node_reference_options().

I think this is critical, since it causes fatal out of memory errors.

For me, the solution was to remove the code that modifies display_options['pager']['options']['items_per_page']. What was happening is the default (0) was clobbering any value set in the view itself. This also fixes #1330494: Node Reference field doesn't recognize "Items to display:Display a specified number of items".

Am I missing something? Is there a condition where items_per_page needs to be set by the module?

I think we need some kind of special widget to meet the requirement or just use the auto complete text field. #3's patch limited the available options and did not solve the problem of referencing by node type.

This patch combined the two approaches above, but adds a limit for user references as well as node references. I also thought 10 was too few items, so changed the initial default to 25.

Thanks a lot... i spent so much time trying to understand why my views number of items doesnt work at all

Hi people.

I applied the patch and works good for me.

Before:

After:

Thank you very much.

Fixed.

Commited in dev branch.

Thank you very much for contribution people.

Good Work.

Regards.

Am i reading this correct? The node/user ref fields used to not limit the number of items listed in a select list? And now this has been hard coded to limit to 25?

But this has now broken my site as i need more items there. Does it not make more sense to have this as an option?

I agreed with liquidcms. I have a site that makes heavy use of node and user references with the chosen widget, and when I installed the dev version the site's users could only see 25 options, and weren't able to select options outside of that set of 25.

So despite the fact that liquidcms and ShaunLaws raised serious issues with this "fix", 3 years later it gets slipped into the production release.

We manage a website that has node references running into the hundreds (which isn't an unreasonable number), and after a few content changes things came crashing down (the node forms are busy and you don't expect to have to monitor the select box each time you make an edit). Time was wasted and clients were affected.

I think this change should be rolled back, or at the very least expose an option for the widget to specify a custom limit. 25 is utterly arbitrary.

Agree with the previous post, this change breaks the systems.

With this limit at 25, if you edit a node with an option out of the first 25, the field is empty and you may lose information if the user saves.

At least it should be configurable and with default "0" to assure the system is not broken and no information is lost.

I changed the coded limit from 25 to 2000, this is sufficient in my case while waiting for a fix

Is it really the case that one must edit the source to have more than 25 options displayed? If so, I'm stunned that anyone thought that was in any way reasonable. If not, the documentation should explain how to change the limit to a more realistic number.

2.4 is out and the problem persists

Confirming this is a problem. It would be good to have an option in the field config to limit these, but the default should be to show ALL options.

Agree with awolfey. Let people who want to set a limit set it through an option, but arbitrarily limiting everyone to 25 makes no sense. I just spent hours trying to figure out why my node with 100+ references, which had worked flawlessly for years, suddenly gave me "this post can't be referenced" errors when I tried to save it: https://www.drupal.org/project/references/issues/3279888#comment-14584580

Even when I didn't update any values and just hit Save, I'd still get errors. And there was no clarity on why the errors were happening....all posts I can find about "this post can't be referenced" deal with caching or issues with the view. This will cause lots of people grief when they get around to updating this module.

I just ran into the same issue, which broke our existing nodes with more than 25 references in a field. I was able to quickly fix that scenario by setting "limit" to the # of submitted ids - attaching the very simple patch here. There may be other places where the limit still causes problems, but this is a start.

Thanks for the solution there #3 you completely broke my site. What a noob fix, how did this get into a Drupal update? How does Drupal allow things to go out there that WILL CLEARLY break a site. makes me sick.

Drew

I share the frustration, why is there no working release for this module? It should not have been released in the first place

Can you revert this commit? Broke our site. If someone has an issue with too many nodes loading into their field widget, they should use a View to build their widget -- this is existing functionality.

Why would you limit it to 25? Pain in the....!!! Please change it!