unnecessary error reported for options validations

Make sense.

I can see the benefit for having that error message. You should rarely see it, and in the case that it happens, it either means something is going wrong or someone is trying to hack the forms on your site. In both of those cases, I'd want to know.

I can undestand cleaning this message up a little bit, but let's not remove it.

This issue is active on drupal.org too.

When changing this very issue project to ie Drupal Webmaster then press tab the error is produced.

1. Click on Project: field
2. delete core
3. select 'Drupal.org webmasters'
4. press enter
5. Click on Project: field
6. press tab
7. Presto

I bumped this up to latest D6 assuming d.o is using that version too.

The patch looks useful but needs work as form.inc has too places this message occurs and filter module has a similar message.

includes/form.inc:              form_error($elements, $t('An illegal choice has been detected. Please contact the site administrator.'));
includes/form.inc:          form_error($elements, $t('An illegal choice has been detected. Please contact the site administrator.'));
modules/filter/filter.module:  form_error($form, t('An illegal choice has been detected. Please contact the site administrator.'));

Steps to reproduce

Running this jQuery with ie firebug

$('#edit-title').focus()
$('#edit-project-info-project-title').val('Drupal core')
$('#edit-project-info-project-title').blur()

$('#edit-project-info-project-title').val('Drupal.org webmasters')
$('#edit-title').focus()
$('#edit-project-info-project-title').blur()

[ Powered by #1115636: Issue Macros and Templates - _default]

Please fix the reported issues. Don't forget to set status to needs review when submitting a new patch.

Actually, this error message in the watchdog has been indispensable for us when working with the services module. Services 3.x uses the FAPI for processing of api calls. In this case, the forms are being used by the web service but are never presented to the end user. As it is now, the return from the services calls include any errors as returned by form_get_errors(). These errors are generic, and do not inclue the field name. This makes debugging issues very difficult, as the only way to find out which field was the offending field is to look in the watchdog. But people working with the API do not have access to the Drupal watchdog...

So, I would suggest that

1) The message that we present to the the user includes the name of the offending field. We do this in the case of required fields, which should invalid field data be any different?

2) We keep the watchdog log message, which I think is still useful. In my use case, as maintainers of the Drupal site we need to be able to support our API users, and so having form errors logged is useful.

This is an issue for all versions of Drupal, so should be addressed in D8 first.

To me, this is more useful. Includes the fix from the original patch, but also fixes up the error message so that it's more useful when reported on the form.

We noticed this issue as our logs were getting quite a lot of error messages where we could not do anything about. We had use cases triggered by bots/scripts with all sort of input strings/SQL queries (useful) as well as just normal users who were trying to access views with exposed filter options that are not present anymore (not useful).

#8 makes a step forward as it doesn't trigger error messages if there is no value.

However, if there would be a configuration option for an administrator to decide whether they want more/less noise about this particular situation that would be much helpful.

Following the steps to reproduce from the IS I tested this on Drupal 7.80-dev, Drupal 8.9 and Drupal 9.3.x and was not able to reproduce the problem.

Therefore, closing as cannot reproduce. If you are experiencing this problem reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!

Thanks for closing