confusing error & behavior when creating a new referenced entity containing parentheses

@adroid I am having the same issue. Did you find a workaround or patch?

https://www.drupal.org/node/2520416 is possibly a related issue. It's referenced in EntityAutocomplete.php

  public static function extractEntityIdFromAutocompleteInput($input) {
    $match = NULL;

    // Take "label (entity id)', match the ID from inside the parentheses.
    // @todo Add support for entities containing parentheses in their ID.
    // @see https://www.drupal.org/node/2520416
    if (preg_match("/.+\s\(([^\)]+)\)/", $input, $matches)) {
      $match = $matches[1];
    }

    return $match;
  }

It would be good to see this annoying bug fixed.

This just came up when trying out in my Drupal install. I hope this bug will be solved soon. Thanks!

I wrote a patch which fix this issue for me. Please, review.

Updated patch. Fixed cases for anonymous users.

Another fix after tests fail.

Improved version.

#18 solves this issue for me.

Correct me if I am wrong but a test is needed.

This latest patch does not work for me.

After adding the patch and then trying to create a term "taxonomy_term (yo)" I receive the following message:

The referenced entity (taxonomy_term: yo) does not exist.

Patch from #18 worked like a charm, thanks!

I think the fail_test patch shows that the current patch doesn't solve _all_ cases of parentheses being used in the title of the referenced entity. (@Leo Pitt in Leo Pitt #27 already found out that text in parentheses didn't work).

Thus far, #18 is working for me in 9.2.9.

Have you thought about the implications?
Currently - without the patch - using the scenario Article+Tags in the IS, if you type "Foo (2)", and a term with ID 2 exists, that term will be used.
It doesn't matter what label you put before the "(2)", the label of term with ID 2 will be used.

The work on this issue, and its patch, only adds to this confusion since the behavior of the widget will be different depending what is within the parentheses, and according to the entities already existing in the database.

Talking about the widget... this is how the entity autocomplete form element is meant to work, with expected input being "Label (ID)". Allowing a different pattern is changing the way entity autocomplete works.

My suggestion: close this issue with "work as designed". Then we can open a different feature request issue proposing a widget extending entity autocomplete but allowing parentheses. This can also be a contrib module initially, to speed up adoption.

RE the misleading error, we can create another issue providing meaningful errors when parenthesis are used within the entity autocomplete element.

# edit - pls ignore or delete this message if you are admin. thnx

--
#18 not working on 9.4.5

Using Drupal core 9.4.8 + term reference with views reference display.
Patch #18 fixed my issue.

Drupal 9.5.
[For me] Today pathces are not needed for use with Autocomplite (Tags style) widget. Even if linked entites contain brackets.
But with popular_tags module (mb with some others) patch #18 is necessary.

Sadly this does not work in Drupal 9.5.9 at all. Putting any text in parentheses triggers an error so entities containing text in parentheses can not be referenced at all (nor created). Applying patch from #18 does not solve the issue.

Sadly this is an error which seems to be too deep to be fixed in short term so I developed custom solution.

I have basicly only added new custom fields with same names as taxonomy fields I already had but with formatter "Text (plain)". Then I used hook_entity_presave() to match text inputted by user into those custom fields and check whether taxonomies exists by name or not, setting them to previously created taxonomy reference fields as target_id. In this custom solution you also have full control over what you want to use as a delimited between each taxonomy entity (for example ";" instead of "," or so)

I guess proper "Drupal" way would be either somehow fix the error or create custom taxonomy field formatter with the logic needed for that but to be fair that would take so much more time and effort as everything with Drupal that those custom hacks works better and are faster to implement.