make migrate field handler behave the same way as term reference: accept entity labels, allow creation of entities

+      // Use the query for the selection handler for this field.
+      $handler = entityreference_get_selection_handler($field_info, $instance, $entity_type, $entity);
+      // WARNING: buildEntityFieldQuery relies on patch!
+      $query = $handler->buildEntityFieldQuery($values, 'IN');
+      $results = $query->execute();

Hm. Why don't you use ->getReferencableEntities() directly?

You don't have to use the label, just get the ID and build the labels separately if you need to.

No, EntityReference_SelectionHandler::getReferencableEntities() returns HTML, that's documented... the Views-based selection handler, for example, can return rich HTML labels.

If you want plaintext, it's your job to downcase to HTML (that's what's missing in #1665818: Ampersands and other characters are not displayed correctly in <select> widgets)... but in that particular case you probably just want to call entity_label() yourself, because you actually want the entity label, not whatever the selection widget wants to display to the user.

Thans @joachim. Here is rework of the joachim's patch based on getReferencableEntities().
Also added special fallback for taxonomy_term.
[TDB]: Add ignore_case option.

Better status.

Added support for ignore_case parameter.

Looks nice to me, +1 to RTBC.

This works fine out of the box, but documentation is necessary before push to repo.

Thanks for review, I'll take a look & try to add docs on the next week.

Same patch rerolled with HTML encoded entity label support.

Applied patch, saved the day. RTBC!

@Sardis, could you write/prepare a documentation about a new options for this destination plugin. See this documentation https://www.drupal.org/node/1224042

Need API docs before it can be committed.

Here's the documentation for this feature, that, however, requires review as well:
Documentation link

I've also added public function fields(), that should enlist sub-fields for entityreference fields in the Destination section within Migrate UI. That removes notices like:
"field_my_entityreference:source_type" was mapped but not in the list of destination fields.
Also small CS fixes.

It just doesn't work if the selection handler is the \EntityReference_SelectionHandler_Views - an array lives in the $options['match'] at \entityreference_plugin_display::query() and db_like() against it produces a lot of warnings, because addcslashes() can't convert an array to string. Fixing this you'll get in trouble with selection handler again - it'll return labels having an HTML and they will never match with values from source.

The saddest thing is not that this is not working, but that it's impossible to fix this not adding breaking changes.

Also, the create_entity_bundle argument is still not documentented.

I can't speak to the use case in #21, but i think what was intended to be fixed was actually fixed by this patch.

After applying the patch at #19, i was able to migrate a new node that had an entity reference to an existing node with just the entity label (node title) in the source data (CSV if that is important).

I've been forced to refuse the idea of using the contributed (this one) field handler for entity references as it doesn't have some features I need. I'd suggest to not rely on this one and create yours to as much as possible meet the purposes of your migrations.

I needed to add this functionality for a old D7 project, and needed to support a Views based selection handler.

Here's a patch that support that. Essentially:

• Instead of using the 'IN' operator which was a bit of a hack, loop over the input values, and use the previously supported '=' operator.
• Switch to loading all matching entities and then asking the entity system for their labels. This is to avoid all the sillyness with un-escaping or having to fiddle around with stripping HTML. My views selection handler was adding tons of markup for example. Seems much nicer to fetch the clean entity label.
• Document the create_entity_bundle subfield.
• Always call field_attach_validate for all entity types, I'm not sure why it needed to be specifically taxonomy terms only.

Hope it helps someone else!