illegal choice detected on import (with notifications fields)

Hi,

I'm experiencing this problem, a year after it was reported !? so I wonder if anyone found a way to solve this.

I'm aware of the other similar problem http://drupal.org/node/375200 and http://drupal.org/node/462720.
The former seems not to be related to notifications, therefore I suspect problem is in CCK Content Copy. I also tried looking into notifications code and could not find anything wrong.

In my case the '0 =>1' element is only in the notifications_node_ui array. Also, the problem seems to reappear after removing the element, importing (creating new type) and exporting the new type again.

I can reproduce the problem easily by
- create new content type with not additional fields and with default values when ever possible, i.e. I only defined Name, Type and Description for the new type
- export the type, the 0=>1 appears in the notifications_node_ui array
- delete the type
- import back (fails), remove the 0=>1 and try again (succeeds), but the next export shows the problem again.

Updating the problem CCK version (6.x-2.7).
Marked http://drupal.org/node/375200 as duplicated.

I tried debugging this by tracing the code up to point where the '0 => 1' gets injected into notifications_node_ui array, and I'm not any more sure if this is even a problem or if the problem is in fact in the core ... anyways hopefully someone finds this helpful.

Here's what I think is happening:

first the content_copy.module handels the export request:

function content_copy_export($form_values) {
...
    drupal_execute('fieldgroup_group_edit_form', $group_state, $form_values['type_name'], $group, 'edit');
...
}

then the form.inc handles the form processing as follows ( as a kind of a top-down pseudo-callstack, '// (x) =>' are my comments)

function drupal_execute($form_id, &$form_state) {
...
  drupal_process_form($form_id, $form, $form_state);
...
}


function drupal_process_form($form_id, &$form, &$form_state) {
  $form_state['values'] = array();

  $form = form_builder($form_id, $form, $form_state);
...
}

function form_builder($form_id, $form, &$form_state) {
...
if (isset($form['#input']) && $form['#input']) {
    _form_builder_handle_input_element($form_id, $form, $form_state, $complete_form);
  }
...
}

function _form_builder_handle_input_element($form_id, &$form, &$form_state, $complete_form) {
...
 // Load defaults.
    if (!isset($form['#value'])) {
      // Call #type_value without a second argument to request default_value handling.
      if (function_exists($function)) {
        $form['#value'] = $function($form);  // (1)=> $function = 'form_type_checkboxes_value'
      }
...
}

function form_type_checkboxes_value($form, $edit = FALSE) {
  if ($edit === FALSE) {
    $value = array();
    $form += array('#default_value' => array());
    foreach ($form['#default_value'] as $key) {
      $value[$key] = 1;                             // (2)=> RESULTS in 0 = 1
    }
    return $value;
  }
  elseif (!isset($edit)) {
    return array();
  }
}

As a result the Subscriptions UI form element (type=checkboxes) has been given field (on line (1) )

  '#value' => array( 0 => 1) 

After this I run out of time and had to stop, but my guess is that this value gets somehow added to the actual checkbox values...I'm bit confused with all this because the drupal documentation (or the drupal book) does not mention checkboxes form elements to use the #value at all ?

Btw. The #default_values of the checkboxes at the (1) is

#default_value (Array, 6 elements)
      form (Integer) 0
      comment (Integer) 0
      links (Integer) 0
      teaserlinks (Integer) 0
      subform (Integer) 0
      block (Integer) 0

so it's still 'clean'

hope this helps, I might give this another look if I have time on monday...

Same problem here. I'm using the feedapi module and some of feedapi's parsers. Feedapi lets content of one type generate content of another type, with a given input format. If you haven't yet defined said input format, I imagine that when the form is rendered, it automatically defaults to the default input format (often 1), even though in the database it is zero. I wonder which module is best placed to correct the situation, content_copy or the myriad of contrib modules which alter the content type form.

Isn't this a duplicate of #383482: Cannot import non-existing node types with export?

This solved the issue for me as well:

removing

    0 => 1,

although i only had that within notifications_node_ui
not notifications_content_type