An illegal choice has been detected - GET requests with BEF combined

Created on 11 April 2019, over 5 years ago
Updated 12 September 2024, 2 months ago

Problem/Motivation

If you:

  1. Create a view
  2. Set method to GET
  3. Add multiple sorts
  4. Use better exposed filters to combine sort by and order by

The code adds a non-urlencoded space to the option value. Drupal core web/core/lib/Drupal/Core/Form/FormValidator.php then marks this as an illegal choice, ie this code in core:

elseif (!isset($options[$elements['#value']])) {
  $form_state->setError($elements, $this->t('An illegal choice has been detected. Please contact the site administrator.'));
  $this->logger->error('Illegal choice %choice in %name element.', ['%choice' => $elements['#value'], '%name' => empty($elements['#title']) ? $elements['#parents'][0] : $elements['#title']]);
}

Proposed resolution

URL encode the option value if method is GET.

Remaining tasks

Apply patch

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Fix illegal choice error with combined better exposed sorts for GET requests.

πŸ› Bug report
Status

Needs work

Version

7.0

Component

Code

Created by

πŸ‡¬πŸ‡§United Kingdom scott_euser

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States emanaton

    I'm having this issue as well, but have a solution which I'm pasting here for posterity and to help the next coder who's still having this issues.

    My fix is to add the following as an additional submit function on the Views Exposed Form (i.e. adding this function to the `$form['#submit']` array within a `hook_form_views_exposed_form_alter` implementation):

    /**
     * Set the default sort from the BEF filter in the $form_state.
     *
     * This is being done so that the view's pagination URLs have a default value
     * set. Without this, click on pagination before executing a sort results in
     * an error message being displayed: "An illegal choice has been detected.
     * Please contact the site administrator."
     *
     * @param $form
     * @param \Drupal\Core\Form\FormStateInterface $form_state
     *
     * @return void
     */
    function my_theme_fix_bef_filters(&$form, \Drupal\Core\Form\FormStateInterface $form_state) {
      if (
        // if there's "sort_by" then the user hasn't explicitly set the sort order.
        !$form_state->getValue('sort_by')
        // check that the better exposed filter combined sort option has been set...
        && !empty($form['#info']['sort-sort_bef_combine']['value'])
        // ... and get whatever key it's configured under for ease of reference...
        && ($combined_sort_key = $form['#info']['sort-sort_bef_combine']['value'])
        // ... and check if the sort options are exposed to the user...
        && !empty($form[$combined_sort_key]['#options'])
        // ... and that there's a usable key set as the first sort option.
        && !!($sort_value = array_key_first($form[$combined_sort_key]['#options']))
      ) {
        $form_state->setValue($combined_sort_key, $sort_value);
      }
    }
    
  • Status changed to Needs work over 1 year ago
  • πŸ‡¬πŸ‡·Greece vensires

    I am reopening this as it's still a case for version 6 of the module and still a fix is needed.

    In my case, I have three different exposed sorting options: created, price and title. The first time I am changing the sorting, it changes and no error is displayed. The second time I change the sorting, the message An illegal choice has been detected. Please contact the site administrator. appears though the sorting still works.

  • Status changed to Closed: won't fix over 1 year ago
  • πŸ‡¬πŸ‡·Greece vensires

    I reverted to the last status of the ticket before my comment because the issue I faced was different it seems - at least in 6.x.

    I had two different views on the page: one was my main content's view and the other was a search view. Both were using BEF - resulting in both using the sort_bef_combine key. When changing the sorted property of the main content's view, the other view was also catching the same value and was trying to set it as default but obviously failed validation.

    The solution in my case was thus patching with the last patch from πŸ› Enable changing sort_bef_combine parameter key RTBC which - thank God - also applies to 6.x and set a different machine name for the element containing the combined keys. As a result, we now have two different fields and no ambiguation exists.

  • Status changed to Needs review about 1 year ago
  • πŸ‡³πŸ‡±Netherlands arantxio Dordrecht

    So we have noticed that this issue still existed on our site and created a patch based on the code from @scott_euser.

    It should apply to both 5.x and 6.x

  • Status changed to Needs work about 1 year ago
  • πŸ‡³πŸ‡±Netherlands arantxio Dordrecht

    So apparently it was due to old referenced links. After the update the code has changed from blank spaces to underscores, when links are referenced they still had the blank space in them and now the better exposed filters doesn't handle the old way.

    It would be nice if we could handle this so people upgrading don't have to update all their content.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Curious if #11 solve the problem for anyone?

Production build 0.71.5 2024