FormState::setErrorByName does not set multiple errors on the same element

@smustgrave: Pinging here, as this issue for example blocks contrib issues like 🐛 Use of $form_state->setErrorByName() within email_registration_user_login_validate prevents other core errors Needs work . Also see #39

To me, it looks like a misconception in multiplicity here, what can we do for "Needs subsystem maintainer review" as of #37?

I know this is probably far-fetched and might need too much refactoring, but in some cases it would be super helpful if each element error could have their own ID. This way, it would be possible to override specific element errors by ID.

I just came to this idea, while taking a look at 🐛 Use of $form_state->setErrorByName() within email_registration_user_login_validate prevents other core errors Needs work . Basically what we want there is to only overwrite the error message that gets thrown, when using incorrect credentials (password / username) and leave all other errors thrown (e.g. the "Too many failed login attempts" error message). An optional "$eid" parameter would be enough:

  /**
   * @param string $name
   *   The name of the form element. If the #parents property of your form
   *   element is array('foo', 'bar', 'baz') then you may set an error on 'foo'
   *   or 'foo][bar][baz'. Setting an error on 'foo' sets an error for every
   *   element where the #parents array starts with 'foo'.
   * @param string $eid
   *   (optional) The error id to use for your error
   * @param string $message
   *   (optional) The error message to present to the user.
   *
   * @return $this
   */
  public function setErrorByName($name, $eid, $message = '');

The only problem is, that core would need to adjust all its "setErrorByName()" calls. Otherwise, this wouldn't have any real benefit.

What are everybody's thoughts on this? Would you agree with this feature request? Should I create a follow up issue for that?

Agree with additional benefits from #42!
That shouldn't be a blocker and might be a follow-up, but it has been a good idea to allow a key for such, to allow altering!

Like other areas do better or worse since Drupal 7, e.g. https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_... ($key) or #attached in Drupal 8+! It's a lovely and helpful general concept.

Good point @Grevil!

Let's hear what the maintainers think.