Autocomplete widgets not referencing the single entity result

Thanks for the patch. I've moved implementation of the fix for this issue into #1472596: Free tagging entity reference to a vocabulary does not create the term, only allows existing terms.

Could we get this fix looked at separately to #1472596? This issue's a simple little bugfix, and the other one's a pretty chunky feature request now. They don't even seem to be that related. I'll try the patch out and see if it needs a re-roll, as I'm running into the issue described here too.

Just tried it. Applies cleanly and fixes the issue. Please commit this if testbot agrees.

Cross-referencing #1901594: _entityreference_autocomplete_tags_validate not getting target_id, which also contains a fix for this.

Ok, closed the other one as duplicate, fixed the documentation and wrote some very basic test coverage.

Looks good, just small nitpicks:

1. +++ b/plugins/selection/abstract.inc
   @@ -21,8 +21,9 @@ interface EntityReference_SelectionHandler {
   +   *   An nested array of entities, the first level is keyed by the
   

   An nested => A nested

2. +++ b/tests/entityreference.handlers.test
   @@ -194,6 +194,21 @@ class EntityReferenceHandlersTestCase extends DrupalWebTestCase {
   +    $this->assertEqual(form_get_error($element), t('There are no entities matching "%value"', array('%value' => $invalid_input)));
   

   I think t() should be replaced with format_string()

1. Yep :)

2. Nope, this isn't an assertion message, it's the actual validation error that we're checking with assertEqual(), that has to be t() as the original is using t() too. Just like clickLink() and drupalPost() button labels still use t() in tests.

1 can be fixed on commit I'd say, unless you want a new patch :)

Marked #2185141: Required entity reference is possible to save with invalid, but tricky content. as a duplicate.

This is also an issue with the views handler.
#1702172: Saving allowed even when input is not valid in autocomplete results

With regards the patch, it works as advertised.

Patch #6 fixes my issue.
Before the patch the validation function returned the entity type and after i after it returned the entity id.

thanks!

The match_operator '=' gets ignored in favour of the default 'CONTAINS' aka 'LIKE'.

Not sure if this is the best way to fix it, or even if this is the right issue, but I've attached a patch to address this concern.

I rerolled the patches in #1 and #6 and made the changes referenced in #8. I believe most of the referenced issues simply confuse the matter. This patch fixes the issue described in comment #1.

@darrick - Applied patch from #15 to Entity Reference 7.x-1.1, cleared caches twice, no effect on issue in #1.;

Patch here: https://www.drupal.org/node/1702172#comment-8681155 applied and did solve the effect in issue #1 here.

@ashedryden - looking at the patches ... mine in #15 fixes the issue when using the default generic select class. I've also applied the patch you mention to fix the issue when using a view for selection.

It works fine and solved my issues.

The patch solved the problem for me perfectly

https://www.drupal.org/node/1974202 was closed as duplicate.

This issue has quite a few duplicates and is also a blocker for other issues so bumping up the priority a bit to reflect this.

Would be great to get some maintainer eyes on.

#15 worked for me too. Please commit.
I raised the priority to critical, because this issue is quite old and has the serious effect of allowing invalid data to be stored. So applications that expect a value for these fields can break. Furthermore, often the person who submitted the form will not notice the problem until her or she gets back to it and tries to submit again.

Patch in #15 works, +1 for commit.

#15 works well and the code looks good to me. +1 for commit :)

Committed. Thank you everyone for your patience.

Patch in #15 works for me too