- ๐ฉ๐ชGermany Anybody Porta Westfalica
@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?
- ๐ฉ๐ชGermany Grevil
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?
- ๐ฉ๐ชGermany Anybody Porta Westfalica
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.
- ๐ฉ๐ฐDenmark uv516 Denmark
Drupal 11.2:
When I call FormState::setError multible times it only show the first message.
I call:$form_state->setError($form,$message);
- First commit to issue fork.
- Merge request !13015Issue #3465041 by prudloff, xjm, smustgrave, larowlan:... โ (Closed) created by dipakmdhrm
- ๐ฉ๐ชGermany rgpublic Dรผsseldorf ๐ฉ๐ช ๐ช๐บ
I really, really like #42 as well. I often thought about this. This would be so useful. There is no way to overwrite specific error messages with more specific or different ones at the moment. With page attachments / headers we already have the concept of specific keys so that's a very "Drupal-ish" idea as well. This could indeed be introduced in a followup. I think the best way to do that would be a new addErrorByName (instead of setErrorByName). That would also be a more fitting name now that we actually append stuff. This way we could add the new $eid signature. Those two could exist in parallel for quite a while (to avoid any compatibility problems) and then later by deprecated. Incrementally more and more errors would get the $eid. And finally we make the switch. After that we could introduce more stuff to actually modify/overwrite things like removeErrorsById($eid) etc.