Saving allowed even when input is not valid in autocomplete results

r u serious this is happening with you?? I tried creating this situation but i never found such error..
IF the entity is not found then it will not create that Node..

Same issue here. My required reference field validates when a title is typed in autocomplete, but not selected from dropdown adding the nid.

For example, manually typing in "netflix" validates, even though field should be "Netflix (X)"

End result - the form submits, and the reference field is empty even when required.

I can confirm this bug.

I can create a node that has 'asdfasdfgqerbge' for the value of the entityreference field and it still saves.
I can assure you that entity does not exist.

Hi,
I am not able to replicate this issue. Can you please give me some more inputs like related module version and drupal version which you used so that we can replicate?

Thanks.

I just tried on a different site and it works as expected.

I'll check again on the problem site tomorrow and see what's going on.

I'm facing the same issue here (Checked with both versions 7.x-1.0 and 7.x-1.x-dev).

As stated above, the problem arises when the entityreference field is used with the "Views: Filter by an entity reference view" mode.
In my case, I'm referencing nodes.

During my tests, the code that seems to cause the validation to be ineffective is this function (in EntityReference_SelectionHandler_Views.class.php):

  public function validateAutocompleteInput($input, &$element, &$form_state, $form) {
    return NULL;
  }

Seems like this is directly related to #1819618: Incorrect autocomplete validation with views selection mode claiming that this bug has already been fixed fore the "simple" mode here: #1389238: Autocomplete widget improvements. The view mode might need a similar fix as well.

I'm wondering if the same code that was added to the EntityReference_SelectionHandler_Classic.class.php file to fix the "simple" mode wouldn't fit our needs?

I've tried to copy-paste it from EntityReference_SelectionHandler_Classic.class.php to EntityReference_SelectionHandler_Views.class.php, and it's working well in my case. Here is what my EntityReference_SelectionHandler_Views->validateAutocompleteInput() function looks like now:

  /**
   * Implements EntityReferenceHandler::validateAutocompleteInput().
   */
  public function validateAutocompleteInput($input, &$element, &$form_state, $form) {
      $entities = $this->getReferencableEntities($input, '=', 6);
      if (empty($entities)) {
        // Error if there are no entities available for a required field.
        form_error($element, t('There are no entities matching "%value"', array('%value' => $input)));
      }
      elseif (count($entities) > 5) {
        // Error if there are more than 5 matching entities.
        form_error($element, t('Many entities are called %value. Specify the one you want by appending the id in parentheses, like "@value (@id)"', array(
          '%value' => $input,
          '@value' => $input,
          '@id' => key($entities),
        )));
      }
      elseif (count($entities) > 1) {
        // More helpful error if there are only a few matching entities.
        $multiples = array();
        foreach ($entities as $id => $name) {
          $multiples[] = $name . ' (' . $id . ')';
        }
        form_error($element, t('Multiple entities match this reference; "%multiple"', array('%multiple' => implode('", "', $multiples))));
      }
      else {
        // Take the one and only matching entity.
        return key($entities);
      }
  }

What do you think?
(the attached patch just adds the content of the function, as shown above)

Patch revamped to match the expected format.

Actually using the code from the Generic class could not work properly as the View method adds an additional level in the returning array: The bundle type. I've run some additional tests and corrected the patch to take this into account.

The patch in #9 didn't work for me. Saving is still allowed.

I've just tested the following:
I've installed a Drupal 7.19 (standard install) with:
- Entityreference 7.x-1.0+4-dev
- Views & Views UI

I've create 2 basic pages "Basic page 1" and "Basic page 2" to have some initial nodes.

Then I've created an Entityreference view listing my nodes.
I've added an Entityreference field to the Basic page content type:
- using the "Autocomplete" widget
- using the view I've created
- required

When I tried to edit one of my basic pages, here is what happened:
- When I filled the entityreference field with "aetiouoiu", the node was updated, but the entityreference field was left blank.
- When I filled the entityreference field with "Basic", the node was updated, but the entityreference field was left blank.
- When I filled the entityreference field with "Basic page 1", the node was updated, but the entityreference field was left blank.
- When I filled the entityreference field with "Basic page 1 (1)", the node was updated, and the entityreference field was correctly saved.

Then, I've applied my patch #9 to entityreference.

When I tried to edit one of my basic pages, here is what happened:
- When I filled the entityreference field with "aetiouoiu", the node couldn't be saved because the text entered did not match any entity.
- When I filled the entityreference field with "Basic", the node couldn't be saved because the text entered matched several entities. Note: There is a cosmetic issue in this case: The html returned by the view is displayed in the error message.
- When I filled the entityreference field with "Basic page 1", the node was updated, and the entityreference field was correctly saved, referencing my node 1.
- When I filled the entityreference field with "Basic page 1 (1)", the node was updated, and the entityreference field was correctly saved, referencing my node 1.

@castelar, what is different between my tests and yours?

Just tried again, and it works. Even works when the letter case does not match. Thanks!

Patch reviewed to fix the cosmetic issue I was talking about in #11.

Marking as needs review for the test bot.

+++ b/plugins/selection/EntityReference_SelectionHandler_Views.class.php
@@ -147,7 +147,48 @@ class EntityReference_SelectionHandler_Views implements EntityReference_Selectio
+      $entities = $entities[key($entities)];

Use $entities = current($entities); instead.

Patch re-rolled with Dean's improvement.

Bug exists also for node-filters (not views). Tested with Entity Reference 7.x-1.0 on a Drupal 7.23

I've applied patch #15 but the bug still exists.

I have a taxonomy with a field collection field containing an entity reference to a user using the "Views: Filter by an entity reference view" mode.

Could the field collection layer be contributing to the problem?

I've try the patch, and works so fine, but when you filled with a "0", saves the node with no reference. I tried to fix it, even with rules, with no results

Patch works, thanks all

PS: I think field collection can best be handled in a separate issue

This is actually a bug in EntityReference-SelectionHandler-Generic.class.php as well, which is being fixed over at #1959624: Autocomplete widgets not referencing the single entity result.

So here is a re-roll using the new generic method.

Same issue with entityform having entityreference field, referring to node.
Patch worked but in error message span entities are displaying instead of rendered message(drupal default Bartik theme).

Multiple entities match this reference; " <span class="views-field views-field-title"> <span class="field-content">Emma Roberts</span> </span> (11137)", " <span class="views-field views-field-title"> <span class="field-content">Michael Fassbender</span> </span> (11136)"

Patch #20 worked for me! Thanks Pacproduct.

Well to be fair, patch #20 was created by akamustang.

This seems the same issue: https://www.drupal.org/node/2317149

Somehow the node number should not be present because it is not friendly for a site visitor submitting forms. It's okay for site maintainers because we can instruct why the node number is there. A site visitor we are unable to instruct them not to backspace/delete the node number.

#20 fixed my issue, applied to Entity Reference 7.x-1.1.

#20 fixed my issue, applied to Entity Reference 7.x-1.1.

Yes, the same. Thanks for patch.

Patch needs work when using a more complex entity reference view, see also comment #21 new patch will follow.

New patch with interdiff.

This patch will work nicely with #980144: Issues with "required, multiple" fields in forms

Missed the double quote in 'Multiple entities match %label": !multiple'.

New patch:
* Better form errors (less tech talk)
* Better filtering of user/database input, where needed

Looks good and works fine. Minor error-messages- and filtering-fixes were already done.

Marked #1819618: Incorrect autocomplete validation with views selection mode as duplicate of this issue.

#1819618 also has some better error messages, that could be added to this issue:
https://www.drupal.org/files/issues/interdiff-1819618-7-9.txt
Added in #1819618-9: Incorrect autocomplete validation with views selection mode by dooug.

The patch from #31 is working very good and fixes a truely major issue. It just cost me hours to find out this reason and fix for our problems.

Please please add it to the latest .dev release and create a new stable release as soon as possible.
This is already a very old issue.

Thank you so much! =)

We've been running with #31 for over a year with no issues to report. Any chance of a merge and stable release?

Great patch if we can get some test written for this we can commit it to the dev branch.

On initial testing of the patch in #31 it's very elegant and works well.. Would be good to get it into the main release.. Will save us a LOT of hassle and extra admin finding out whet the person meant when the node is saved blank..

The patch #31 works perfectly. Thank!

Anyone fancy having a crack at the tests?

This was always my fear with this module takeover that every issue would just end up as "Needs tests".

:'(

Nice patch!

I feel like having a crack at the tests. Even the generic selection handler had no test and I'm trying to add the tests for the following scenarios.

• Validation checks for autocomplete with EntityReference_SelectionHandler_Generic.
  • No validation error occurs for an existing title.
  • A validation error occurs for an invalid title.
  • A validation error occurs for a title shared by many entities.
  • A validation error occurs for a title shared by several entities.
• Validation checks for autocomplete with EntityReference_SelectionHandler_Views.
• No validation error occurs for an existing title.
• A validation error occurs for an invalid title.
• A validation error occurs for a title shared by many entities.
• A validation error occurs for a title shared by several entities.

I fixed the wrong file doc and some points in the patch #41 following the coding standard check.

The following issue may need to be resolved before we use the autotest properly. The autotest failed but it succeeded in my environment. I'd like someone to run tests locally to investigate.

#2857322: Functions of Token module is used without checking Token module status

The change between patch #41 and this patch is small and I created a interdiff with #31 again.

I adjusted some small points in the patch #43.

Tests in the patch pass in my environment and fail on drupal.org CI system... I don't understand why it fails. I'd like someone to test it in a local environment.

The test only patch #48 lacks the addition of files[] in .info file. Here's a correct one.

+files[] = tests/entityreference.form.test

Hmm, patch+tests passes fine for me too, and tests only fails as expected, not sure why the testbot is failing.

So I tried on a different install and was able to reproduce the testbot errors.

After some hunting I found that _entityreference_autocomplete_validate() calls entityreference_get_selection_handler() which returns EntityReference_SelectionHandler_Broken.

This seems to be because the EntityReference_SelectionHandler_Views plugin isn't being loaded.

A quick check to confirm this by commenting out the if statement in plugins/selection/views.inc (i.e. if (module_exists('views'))) to force the plugin to always be added. This seems to work and all tests now pass.

It seems that this file (plugins/selection/views.inc) is getting called before views(/ctools) is being enabled by the test.

I'm thinking the solution should be that after the test dependencies are enabled we force it to add the views plugin. I tried to do this in setUp() without much luck. Is this something you could have a go at hgoto?

@MustangGB thanks. I see. Your insight helped me a lot!

As far as I understood, it's impossible to reload the plugin file plugins/selection/views.inc as require_once is used to load the file in ctools function. So we need to enable views module before entityreference module so that plugins/selection/views.inc is loaded only after views module is enabled.

I'd like to try a revised patch. (Of course, this works in my environment.)

Perfect, very comprehensive tests, and they're passing now as well.

Patch in #20 works for me too with Entityreference and select entity by views

Nice work on patch #54! Thanks +1

This applies cleanly to 7.x-1.4, but causes 500 errors on autocomplete after each character entered.

@ashedryden thank you for testing. Can you share the detail of the error and steps to reproduce?

I have tried patch #54 and works with entityreference 7.x-1.1, but not return error if I select the same identity with the same ID but only with the same label.

I have a fieldcollection multiple field with a entityreference field. I select entity by autocomplete widget.

• I create my node and select from entityreference field my entity with ID = 1.
• Click on ADD ANOTHER ITEM, select one more time entity with ID = 1
• Click on SAVE button and my node is created but contains two equal values.

Thanks.

@Kris77, thank you for testing.

I don't fully understand what you want. If you want to forbit duplicate entities, you would be interested in the following issue or module rather than this issue.

#2010488: Forbid to use duplicate entities in entityreference field
Entityreference unique: https://www.drupal.org/project/entityreference_unique

I think the issue tag "to" is added by mistake.

@hgoto thank you so much for your reply and suggestions. I will try to be clearer.

This my scenario:

• Entityform type: FORM1
• In FORM1 i have a field collection field: FC1
• In FC1 i have a entityreferencefield with autocomplete widget: ER1

So, when i visit page to create my entityform type(FORM1)

• I select entity in ER1 and click on field collection button "add more item",
• Select the same entity and click on field collection button "add more item" but error not appear.
• Click on SUBMIT button but error not appear and the form is submit with two same entities .

I've tried your solutions but none of them seems to work with field collection.

@Kris77 thank you for the detailed explanation. I got it.

If I understand your requirement correctly, it's not very related with this issue. I believe it's better to file a new issue with "Support request" or to use Drupal Answers in order to get hints to implement that feature :)

(In my opinion, that requirement needs to be implemented with a custom code.)

I'm not sure if this is related to this issue but today we found out the following.

We have a node with an entityreference field that only allows one other node type as values. When creating content in this node the dropdown is showing valid values. However it's possible to bypass the type by pasting the complete node title + id in the field.

So practical example:
Title | NID | Node type
Test 1 | 1234 | X
Test 2 | 5678 | Y

When creating a node of type Z with the node reference field set to only allow node type X. It's possible to reference to node "Test 2" of type Y by pasting the value "Test 2 (5678)" into the field.

What I think is happening is because we supplied a valid node + id it's bypassing the check for the type. Or was the "allowed types" option in the field settings never intended for validation on the save event and only for the dropdown values.

Let's say we have some creative users on our site :)

If this issue is not related I'll happily create a new issue for it.

@BramDriesen Are you using Mode Simple (with optional filter by bundle) or Views: Filter by an entity reference view?

@MustangGB Just checked and we are using Simple (with optional filter by bundle).

It's not particularly clear in the summary, but this issue is for the second mode, i.e. views.

I've not attempted to replicate your issue yet, that said I would have thought it'd been sorted out by #1959624: Autocomplete widgets not referencing the single entity result, which is already included in the latest release.

Either way, probably best to open a new issue I'd say.

I checked the version of the module and we are using the latest stable release.

Created a new issue: #2894475: Saving entity ignores the allowed bundles settings when a valid nid is supplied

While the patch from #54 works, there are a couple of issues with error handling.

%label is not populated in my case, but simply blank. I assume this should show the label of the field?

I believe there are other threads discussing the UI problems of having to have the NID in parentheses after the tag. This is confusing enough for the user and hopefully will be changed in the future. However, this error Specify the one you want by appending the id in parentheses, like "canc (569)" will be totally confusing to users in my opinion. What are they supposed to do with an ID that has no meaning to a non-technical person? I would suggest to focus on how they can fix the issue without even mentioning IDs. What we want them to do is start typing a term, wait for the suggestions and click on the desired term.

How about something like: You have not made a valid selection in <field label>. Please go back to question <field label>, start typing in the field and wait for suggested choices under the field. Pick a suitable choice of the presented options by clicking on the desired term.

I believe there are other threads discussing the UI problems of having to have the NID in parentheses after the tag. This is confusing enough for the user and hopefully will be changed in the future

What if we have different entity with identical label ?
One solution could be to make entity reference field to have configuration field which supports token which would later replaced between parantheses.
Fore ex. If we have authored by [node:author] or [node:content-type] as configured value then in auto complete it should show
The first node (author by admin) or
The first node (blog)

This can also be accomplished with views if view is set as referenced entity source.

Hi nithinkolekar,

I did not intend to move the discussion about the UI issue into this thread. I am sure all these issues are considered for a potential solution. To get this patch committed though I feel we should adjust the language used in the error message. Referencing the ID may not be the most useful. I believe it would be most helpful to ignore the ID for now and just tell users what they are in fact supposed to do, i.e. you have to select the most suitable option from the autocomplete suggestions. I proposed an alternative. How do you feel about that?

I am very glad to see this issue addressed and would be appreciative if we can get it committed.

Thanks, J.

Here's an updated patch. Not sure why '5' was originally chosen in this patch as "too many". Since the widget itself defaults to 10, I changed it to match that. Makes that message much less likely to occur generally as well.

Ideally we should match whatever that value is for the widget-- see #2185019: Autocomplete field widget, add option to display more than 10 items in the autocomplete drop down for work on making that configurable.

I realize the wording of that error message is still pretty cryptic, but I think we can always address that in a follow-up patch. imo this is a critical issue because forms are being submitted with invalid values that subsequently don't get saved but pass form validation.

I agree that it is a major issue and would love to see it committed too. I can live with adjusting the error message later. Do you not have the issue that %label is blank in the message though?

Don't think so, or didn't notice it if I did. Let me go back and test again.

Shouldn't it be > 1? Otherwise there is still ambiguity

Edit: it was 5 because the Generic handler is 5, these should match or have a base class to keep them in sync. Moreover, the query only asks for 6 items, so it's checking > 5 to catch if they bleed past this.

Reuploading #54.

@WorldFallz If you look at the code you will see above that check for > 5, that it selects a limit of 6, so it will never be > 10. This keeps the two in alignment until an appropriate base class is created(hopefully) to keep these in sync.

Just a couple notes while manually testing, @jelo What's the scenario where there is no %label? I couldn't reproduce that.

Also, there is some security hardening with this VS \EntityReference_SelectionHandler_Generic::validateAutocompleteInput

1. The filter_xss() that strips tags, may be overkill, strip_tags() and check_plain() would suffice for the item_list sanitation?
2. The casting to (int) assumes id's are ints and may incorrectly return 0 instead of NULL, and a bit strange casing an int in a string concatenation. I'd remove that but I'll let the committer or another community member decide.

Tracked down the issue @jelo is having. It's in the case of multiple values the form changes and the #title is dropped.

/includes/form.inc:1444

// Although discouraged, a #title is not mandatory for form elements. In
// case there is no #title, we cannot set a form error message.
// Instead of setting no #title, form constructors are encouraged to set
// #title_display to 'invisible' to improve accessibility.

This seems to be a core issue, because the error that gets produced on just required and empty is

field is required

instead of !name field is required.

I've RTBC'd the related core issue #980144: Issues with "required, multiple" fields in forms

Awesome. I applied the core patch and this entityreference patch and now everything works as designed. Would be great to see this committed!

I can confirm this patch works

Checking patch entityreference.info...
Checking patch plugins/selection/EntityReference_SelectionHandler_Views.class.php...
Checking patch tests/entityreference.form.test...
Applied patch entityreference.info cleanly.
Applied patch plugins/selection/EntityReference_SelectionHandler_Views.class.php cleanly.
Applied patch tests/entityreference.form.test cleanly.

Thank you, #80 works for me.

A more human-friendly error message would work better for authenticated users who don't know or care about IDs (especially if the ID doesn't show in the autocomplete options which appear).

Maybe something like, 'Too many items like "@value" found for %label. Try typing again and select the one you want from the options that appear.'

Five+ years with Major priority fom the beginning and still not committed yet.

@damien-tournoud
I know this module is in "Minimally maintained" status but issue like this should be committed with exception when 286,306 sites are using this module.

RTBC

#80 fixed this for me as well.

patch #80 also worked for me and is a huge help in avoiding nodes being saved with empty references. I agree that the error labels could be more human-friendly but would like to see this patch committed.

If you really want to see this get in, then send a kind private message requesting this to all of the maintainers of this project that might not be subscribed to this issue.

There still remains a potential issue with patch #80.

If you have a list of entities that the entity reference field targets and someone enters a partial match which results in one result, but they don't select it, then the unselected entity will end up filling the field's value.

Say you have the following nodes with the titles:

• Foo
• Bar
• Baz

And you set up a required entity reference field to use a view to select these nodes.

On the form, if you were to type in Fo then you would get the suggestion for Foo. If you do not select this result, instead click outside of the field, then the field's value will remain as Fo. Yet when you submit the form, there is no validation error, instead the Foo node is used for the field's value.

I'm not sure if this is supposed to be the expected result, but it doesn't seem right.

This seems to be an issue with \EntityReference_SelectionHandler_Views::validateAutocompleteInput() in how it calls $this->getReferencableEntities($input, '=', 6). The logic sets the $match_operator to '=' yet that operator is not respected, it ends up building the query as if it was set to 'CONTAINS'.

The culprit seems to be in \entityreference_plugin_display::query() (lines 67-70) where it starts building the match value as a STARTS_WITH (%MY SEARCH VALUE) then it sees that the match operator is not 'STARTS_WITH' so then it completes the value as CONTAINS (%MY SEARCH VALUE%) operator.

So in conclusion \EntityReference_SelectionHandler_Views::validateAutocompleteInput() thinks that \entityreference_plugin_display::query() supports a '=' match operator when it doesn't.

Quick question, why is there an arbitrary limit of 5 results and then an error is triggered? Also that error message assumes the user can see the ids (which by default is true but not in all cases).

#1702172-79: Saving allowed even when input is not valid in autocomplete results
it was 5 because the Generic handler is 5, these should match or have a base class to keep them in sync. Moreover, the query only asks for 6 items, so it's checking > 5 to catch if they bleed past this.
-JoelPittet

not sure if this answers your question but it seems to make sense.

straight up reroll of patch 80 which by all indications is "good to go in"
reroll, for some reason cicd very strict on this. Only had some fuzz locally for me.

Just going to run automated tests then jam this in once it's all green.

Minor change to tests/entityreference.form.test for PHP 8.2 compatibility

Cool to see this being fixed after 12 years ;-) thanks @joseph.olstad!!

https://www.drupal.org/project/entityreference/releases/7.x-1.6-rc2

https://www.drupal.org/project/entityreference/releases/7.x-1.7

please try the latest release

https://www.drupal.org/project/entityreference/releases/7.x-1.9