Checkboxes default value is ignored by forms system during processing of AJAX request

Could you create a unified patch using git, please? See http://drupal.org/patch/create for more information.

Needs to be fixed in d8 first and then backported

And back to normal as well

It has not been backported on D7 yet.
I tested (manually) the patch on a 7.9 and it seems work.

Hello

After more use of my patched installation, i found at least one bug caused by the #5 patch, but, actually it seems come from node_reference module and not really from the patch.

If you use the references module and you create a new node reference field like that :

• create a new field, node reference type and an autocomplete text field as widget and submit
• on the field-settings edit form choose only on content type as referenceable and submit

So you get the global edit field form, where the 'content type referenceable' settings is displayed again, and there, all the content types are checked and not only this you selected in the first step.

If you uncheck all the content type but one and you submit. The setting is saved and if you test the field, only the content type checked can be referenced. But if you edit again, both field-settings form or global field edit form, all your content types are checked again.

This behaviour is due to the #5 patch (if the patch is not applied, the behaviour is ok)

So i digged down in the references module (because, it's the only form where i found this bug) and i think the problem comes from the way how the #default_value node reference field is built.
It is done in the node_reference.module line 82 :

<?php
$settings = $field['settings'];

  $form = array();
  $form['referenceable_types'] = array(
    '#type' => 'checkboxes',
    '#title' => t('Content types that can be referenced'),
    '#multiple' => TRUE,
    '#default_value' => $settings['referenceable_types'],
    '#options' => array_map('check_plain', node_type_get_names()),
  );
?>

I didn't manage to find where the $field['settings']['referenceable_types'] array is populated (I suppose it's populated by the field API) but the result can be see with the debug function :

<?php
'#default_value' => 
        array (
          'atelier' => 'atelier',
          'article' => 0,
          'date' => 0,
          'page' => 0,
          'recette' => 0,
        ),
?>

The handler of default value for checkboxes is defined by the patch like that :

<?php
'#default_value' => isset($value[$key]) || (is_array($element['#default_value']) && in_array($key, $element['#default_value'])) ? $key : NULL,
?>

So in the situation i describe above the condition match and the default value for the checkbox element is set to a not NULL value and the render for checkbox element is checked.

So, the problem comes from the node references module and i posted an issue for that (http://drupal.org/node/1365412) , but maybe we have to anticipate this kind of error with just a little change :

<?php
'#default_value' => isset($value[$key]) || (is_array($element['#default_value']) && in_array($key, $element['#default_value']) && $element['#default_value'][$key] != 0) ? $key : NULL,
?>

where the condition doesn't match if the $key is in the array but $element['#default_value'][$key] equals to 0, and so the checkbox element is not checked when it is rendered.

I'll try to make a new patch with this little add.

Cheers

here the patch with the little change mentioned above
thanks for review
cheers

This might be a legit bug, but without a test to reproduce it, this patch cannot be accepted.

The solution looks like a hack at first sight, so the real issue might be elsewhere, but anyway, we cannot proceed without a test to reproduce it.

Hi

Sorry i just see this issue is for D8 (actually i saw it, but as the #5 patch is for D7, i go on in this way).

As, this issue is still in the D7 version, how can i do to test this patch for D7 ? do i have to create a new issue for D7 or just change the version for tag for this issue to submit the patch, then port again the issue to D8 ?

In an ajax callback, the current values of element, i.e. the $form_state['input'], overrides the default value, so if the element already exists in the form and has input, so changing #default_value doesn't matter. See _form_builder_handle_input_element

So is this a bug or by design?

> So is this a bug or by design?

If it's by design it really needs documenting, as it's a real headdesker.

Patch from #10 re-rolled against d8.

Thinking more about this I reckon it's by design.

If you display a form element to the user, and they enter data, and then it's AJAXed in some way, the user is going to expect that their input is not lost.

Obviously, there will be particular cases where you *do* want that to happen -- perhaps the AJAX callback is meant to process and modify the user's input, or there's just some sort of good reason to replace it.

But the basic behaviour seems right to me. Though it would be good to get input on this from the FormAPI expects.

Also, either way, it needs documenting.

How can it be by design when the checkboxes element (or I assume this might be all multiple-value elements) is handled differently from other elements? I have a simple form that looks like:

  $form['role'] = array(
      '#type' => 'select',
      '#title' => t('Role'),
      '#options' => $roles_options,
      '#default_value' => $role_selected,
  );
  $form['dates'] = array(
      '#type' => 'checkboxes',
      '#title' => t('Dates'),
      '#options' => $dates_options,
      '#default_value' => $dates_selected,
  );

When the form is rebuit with AJAX, the role field shows the computed value, but not the dates field? Inconsistency like that is clearly a bug to be fixed...

A simple workaround is to unset the input in form state. So in my example I would simply add:

unset($form_state['input']['dates']);

> How can it be by design when the checkboxes element (or I assume this might be all multiple-value elements) is handled differently from other elements

Hmm, that's a very good point!

On my case, I made an ajax callback which adds options to a checkboxes list, I want those new options be checked by default. I understand the design behavior, but I think it's necessary some way to archieve the other case.

@juanjo_dv you should be able to achieve that with https://api.drupal.org/api/drupal/developer%21topics%21forms_api_referen...

function fees_form_alter(&$form, &$form_state, $form_id) {
switch ($form_id) {
case 'fees_node_form':
$form['title'] = NULL;
$class_name[0] = 'Select';
$class_name= $class_name+get_class_list();
$form['field_common_class_id']['und']['#options'] = $class_name;
break;
case 'fees_paid_node_form':
$form['title'] = NULL;
$query = 'select n.nid,f.field_fees_name_value,c.field_common_class_id_value from node n
JOIN field_data_field_fees_name f ON n.nid = f.entity_id
JOIN field_data_field_common_class_id c ON n.nid = c.entity_id
JOIN field_data_field_status s ON n.nid = s.entity_id and s.field_status_value = 1';
$result = db_query($query);
$fees_list[] = 'Select';
foreach ($result as $record) {
$fees_list[$record->nid] = $record->field_fees_name_value;
}
$form['field_common_fees_id']['und']['#options'] = $fees_list;

$form['field_common_fees_id']['und']['#ajax'] = array('event' => 'change', 'callback' => 'ajax_student_list_fees_callback','wrapper' => 'student-list');
$form['field_common_student_user_id']['und']['#prefix'] = '

';
$form['field_common_student_user_id']['und']['#type'] = 'checkboxes';
// $form['field_common_student_user_id']['und']['#default_value'] = $selected;

$selected = isset($form_state['values']['field_common_fees_id']) ? $form_state['values']['field_common_fees_id']['und'][0]['value'] : 0;

if(isset($selected) && $selected > 0) {
$options = _ajax_student_list_fees_callback($selected);
$form['field_common_student_user_id']['und']['#default_value'] = array(115,121);
$form['field_common_student_user_id']['und']['#options'] = $options;
}
break;
}
return $form;
}

function ajax_student_list_fees_callback($form, $form_state){
return render($form['field_common_student_user_id']['und']);
}

But fees is not checked. May I know what I did wrong here?

This attached patch solved my issues

for type checkbox there is shame issue
i fix by

foreach($form as $key_field=>&$info)
if(!empty($info) && $info[LANGUAGE_NONE]['#type']=='checkbox'){
$info[LANGUAGE_NONE]['#checked']=(bool) $info[LANGUAGE_NONE]['#value'];
}

Developing a custom form with D8.5 I've experienced same problems to set #default_value after ajax callback. Just rerolled #28 to D8.5 and fortunately works fine.

Same issue with "checkbox"(Checkbox.php) form element
Patch attached.

Sorry, previous patch is wrong.

From what I can check the patch from #35 and #40 are the same. Please don't upload duplicate patches.

I feel we should focus on the "checkboxes" element instead of "checkbox" and keep the issue within the title scope.

I found one bug. When I try to update user entity via admin page I can't remove user roles.

I'll try to fix it by my self, please review my patch.

I have got checkboxes into cells of a table $element that is added (via Ajax) into a buildOptionsForm (form settings) of a @ViewsStyle plugin
So my use case regards checkboxes elements added via ajax into a form that has already been added by a parent ajax process.

Both #43 and #40 don't work for me, and the checkbox that should load with a #default_value => TRUE are instead alla unchecked.
Either I am unable to unset the $form_state input as there is no way to do that in D8 (afaik), as $form_state->input property is protected.

So any luck for me with any of the solutions here proposed ... (will keep following this).

In Checkbox::valueCallback(), $input is checked for FALSE but not NULL. Now this one seems to work, though $input shouldn't be set to NULL and still needs to be fixed.

This one seems to be a won't fix issue.
There is no practical way (at least in some cases) to distinguish new (dynamically added) checkboxes (which need to be set to their default values) from empty ones (which need to be left empty) after submit. It happens because browsers do not submit anything for empty checkboxes. All such checkboxes are treated as unchecked. FormBuilder::handleInputElement() tries to resolve it:

      // For browser-submitted forms, the submitted values do not contain
      // values for certain elements (empty multiple select, unchecked
      // checkbox). During initial form processing, we add explicit NULL
      // values for such elements in FormState::$input. When rebuilding the
      // form, we can distinguish elements having NULL input from elements
      // that were not part of the initially submitted form and can therefore
      // use default values for the latter, if required. Programmatically
      // submitted forms can submit explicit NULL values when calling
      // self::submitForm() so we do not modify FormState::$input for them.

Though it doesn't work at least when checkboxes are added in a #process callback of a form and new checkboxes get added also before the rebuild.

Just perplexed with this issue then found this thread.

Thanks for some of above comments mentioning that it happens because checkboxes field having user input.

Following strategy helped me to solve it.

$input = $form_state->getUserInput();
unset($input['breakpoints']);
$form_state->setUserInput($input);

Here "breakpoints" is my checkboxes field getting dynamically changed. So, just clear user input against that field while you handle it in Ajax update.

I tried out patch 46. It works for ajax loaded form parts. However, a side effect is that all normal checkboxes such as boolean fields in nodes are impossible to tick off (and save that way). After ticking off a checkbox and saving a node, the checkbox (and field value) is still 'on'.

The patch basically breaks all non-ajax loaded checkboxes in Drupal.

This patch should solve the issue now, please review

My latest patch didn't solve the issue, I ended up using the workaround in #48

I have tried #48. It successfully unset and update the form_state value of the field. In my case it is radio button. But I can't show the default_value as checked after ajax callback. Any suggestions.

Just tried patch 46 as I was having issues with an altered BEF form. It did partially work for me, but I had to add a condition in my form to pull the right default value on ajax call. Hopefully no side effects on other forms?

Attached patch should fix the issue mentioned in #50.

@Anas_maw,

When I have applied #51 patch on my website. It is working fine with ajax base checkbox functionality. But, when I try to unpublish any content that content does not unpublish due to the code in the patch.

I have installed a new drupal setup and apply the patch then I found the checkbox does not mark uncheck.
You can try yourself with drupal fresh installation.

Thanks

This patch is working fine in both the cases. Please review
1. If the user uses an ajax loaded form, in this case, it is working fine.
2. Also, If the user uses a boolean field like a normal checkbox. even then it is working fine.

The attached patch fixes the issue mentioned in #58.

I have checked and found core this code ( if ($input === FALSE || is_null($input)) {) in Checkbox.php.
So we can apply another patch for this condition.

Please Reveiw.

Hey, Can someone delete the 1100170-60.patch. Because, it is uploaded mistakenly.

This patch fixes the #51 patch issue.

Fixing the last few patches to include both checkboxes.php and checkbox.php.

Here is the patch which fixes the failed test cases of patch #62. Please review.

I feel we should focus on the "checkboxes" element instead of "checkbox" and keep the issue within the title scope.

So if I open a separate ticket reporting that it's not just the #default_value property which is affected but dynamic changes to the #description property are also ignored, I won't get told my new bug report is a duplicate of this one?

(Oh, and happy 11th anniversary for this ticket. 🎉)

Just a heads up, the current approach (like in #63 and #71) can causes issues with core checkbox inputs (e.g The chechboxes used in Manage form display's widget settings), making them unable to save.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.