I created new "content type".
I created new "group one".
One text field in "group one"
Save was without problem.

I export new content type.
Delete new content type.
I tried import as "create new"

OK - The content fields table content_type_test has been created.
OK - The content type test has been added.
OK - Created field txt field one.
Error - The field txt field one (field_txt_field_one) was added to the content type test, but an error has occured updating the field settings.
Error - Please check the errors displayed for more details.

Error - An illegal choice has been detected. Please contact the site administrator.
Error - The default value is invalid.

I havent set default value.
Is this bug ?

$content[type] = array (
'name' => 'test',
'type' => 'test',
'description' => '',
'title_label' => 'test',
'body_label' => 'Body',
'min_word_count' => '0',
'help' => '',
'node_options' =>
array (
'status' => true,
'promote' => true,
'sticky' => false,
'revision' => false,
),
'comment' => '2',
'old_type' => 'test',
'orig_type' => '',
'module' => 'node',
'custom' => '1',
'modified' => '1',
'locked' => '0',
);
$content[groups] = array (
0 =>
array (
'label' => 'group one',
'settings' =>
array (
'form' =>
array (
'style' => 'fieldset',
'description' => '',
),
'display' =>
array (
'description' => '',
'teaser' => NULL,
'full' => NULL,
'label' => NULL,
),
),
'weight' => '0',
'group_name' => 'group_group_one',
),
);
$content[fields] = array (
0 =>
array (
'widget_type' => 'text',
'label' => 'txt field one',
'weight' => '0',
'rows' => '1',
'description' => '',
'field_txt_field_one' =>
array (
0 =>
array (
'value' => '',
),
),
'default_value_php' => '',
'group' => 'group_group_one',
'required' => '1',
'multiple' => '0',
'text_processing' => '0',
'max_length' => '',
'allowed_values' => '',
'allowed_values_php' => '',
'field_name' => 'field_txt_field_one',
'field_type' => 'text',
'module' => 'text',
'default_value' =>
array (
0 =>
array (
'value' => '',
),
),
),
);

Comments

sentinelcz’s picture

Component: CCK in core » content.module

Note: I tried import the same again and second time was OK.

I have next example

* The content fields table content_type_bb has been created.
* The content type first has been added.
* Added field bb.
* The field bb (field_bb) was added to the content type first, but an error has occured updating the field settings.
Please check the errors displayed for more details.
* An error has occured adding the field date (field_date).
Please check the errors displayed for more details.

* An illegal choice has been detected. Please contact the site administrator.
* The default value is invalid.

$content[type] = array (
'name' => 'first',
'type' => 'bb',
'description' => '',
'title_label' => 'Title',
'body_label' => '',
'min_word_count' => '0',
'help' => '',
'node_options' =>
array (
'status' => false,
'promote' => false,
'sticky' => false,
'revision' => false,
),
'comment' => '2',
'old_type' => 'bb',
'orig_type' => '',
'module' => 'node',
'custom' => '1',
'modified' => '1',
'locked' => '0',
);
$content[groups] = array (
0 =>
array (
'label' => 'aa',
'settings' =>
array (
'form' =>
array (
'style' => 'fieldset',
'description' => '',
),
'display' =>
array (
'description' => '',
'teaser' => NULL,
'full' => NULL,
'label' => NULL,
),
),
'weight' => '0',
'group_name' => 'group_aa',
),
);
$content[fields] = array (
0 =>
array (
'widget_type' => 'text',
'label' => 'bb',
'weight' => '0',
'rows' => '1',
'description' => '',
'field_bb' =>
array (
0 =>
array (
'value' => '',
),
),
'default_value_php' => '',
'group' => 'group_aa',
'required' => '0',
'multiple' => '0',
'text_processing' => '0',
'max_length' => '',
'allowed_values' => '',
'allowed_values_php' => '',
'field_name' => 'field_bb',
'field_type' => 'text',
'module' => 'text',
'default_value' =>
array (
0 =>
array (
'value' => '',
),
),
),
1 =>
array (
'widget_type' => 'date_select',
'label' => 'date',
'weight' => '0',
'select_day' => '1',
'select_month' => '1',
'select_year' => '1',
'years_back' => '3',
'years_forward' => '3',
'increment' => '1',
'description' => '',
'group' => 'group_aa',
'required' => '0',
'multiple' => '0',
'granularity' =>
array (
'Y' => 'Y',
'M' => 'M',
'D' => 'D',
),
'todate' => 'optional',
'input_format' => 'site-wide',
'input_format_custom' => '',
'output_format_date' => 'd.m.Y - H:i',
'output_format_zone' => '',
'output_format_custom' => '',
'output_format_date_long' => 'l, j F, Y - H:i',
'output_format_zone_long' => '',
'output_format_custom_long' => '',
'output_format_date_medium' => 'j F, Y - H:i',
'output_format_zone_medium' => '',
'output_format_custom_medium' => '',
'output_format_date_short' => 'd.m.Y - H:i',
'output_format_zone_short' => '',
'output_format_custom_short' => '',
'tz_handling' => 'none',
'field_timezone' => 'Africa/Algiers',
'field_name' => 'field_date',
'field_type' => 'date',
'module' => 'date',
),
);

seanr’s picture

Same problem here, with this code:

$content[type]  = array (
  'name' => 'Issue',
  'type' => 'issue',
  'description' => '',
  'title_label' => 'Title',
  'body_label' => 'Body',
  'min_word_count' => '0',
  'help' => '',
  'node_options' => 
  array (
    'status' => true,
    'promote' => false,
    'sticky' => false,
    'revision' => false,
  ),
  'comment' => '0',
  'event_nodeapi' => 'never',
  'forward_display_' => '1',
  'image_attach' => '1',
  'upload' => '1',
  'old_type' => 'issue',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
  'location_maxnum' => '0',
  'location_defaultnum' => '0',
  'location_weight' => '9',
  'location_collapsible' => 1,
  'location_collapsed' => 1,
  'location_addanother' => 0,
  'location_name' => '',
  'location_street' => '',
  'location_city' => '0',
  'location_province' => '0',
  'location_postal_code' => '0',
  'location_country' => '1',
);
sirkitree’s picture

Title: Export - Import » Illegal choice has been detected on Export - Import
Version: 5.x-1.4 » 5.x-1.5
Priority: Normal » Critical

webchick/sirkitree here. We had this issue as well... CCK 5.x-1.5.

We created a content type manually and then to test, simply exported the type, deleted it, and re-imported it (no other changes). The content type (shown below) consists of a node reference field (Artist), an image field (photo) and two text fields (photographer first/last name).

When importing back, the nodereference field (which was listed first) was created, but it said there were errors with the field settings when importing it back in. All other fields after that failed.

In desperation, we merely tried re-ordering the fields in the export so that the two text fields were added first, followed by the noderef/image field -- the only change we did was re-order the fields and re-number their indexes appropriately -- and LO AND BEHOLD it worked! Woah. Go figure.

No time to debug this further, but here's the before/after dump which might help.

Before (errors-o-plenty):

$content[type]  = array (
  'name' => 'Official photo',
  'type' => 'official_photo',
  'description' => 'Upload official pictures.',
  'title_label' => 'Title',
  'body_label' => 'Caption',
  'min_word_count' => '0',
  'help' => '',
  'node_options' => 
  array (
    'status' => true,
    'promote' => false,
    'sticky' => false,
    'revision' => false,
    'moderate' => false,
  ),
  'fivestar' => 0,
  'fivestar_unvote' => 0,
  'fivestar_stars' => 5,
  'fivestar_style' => 'default',
  'fivestar_position_teaser' => 'hidden',
  'fivestar_position' => 'below',
  'comment' => 2,
  'comment_type' => 'comment',
  'comment_view' => 'node_comments',
  'privatemsg_link' => 
  array (
    'node' => false,
    'teaser' => false,
    'comment' => false,
  ),
  'community_tags_display' => 1,
  'old_type' => 'official_photo',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
);
$content[fields]  = array (
  0 => 
  array (
    'widget_type' => 'nodereference_autocomplete',
    'label' => 'Artist',
    'weight' => '-4',
    'description' => '',
    'default_value_widget' => 
    array (
      'field_artist' => 
      array (
        0 => 
        array (
          'node_name' => '',
        ),
        1 => 
        array (
          'node_name' => '',
        ),
        2 => 
        array (
          'node_name' => '',
        ),
      ),
    ),
    'default_value_php' => '',
    'required' => '1',
    'multiple' => '1',
    'referenceable_types' => 
    array (
      'artist' => true,
      0 => 1,
      'blog' => false,
      'comment' => false,
      'forum' => false,
      'official_photo' => false,
      'page' => false,
      'photo' => false,
      'poll' => false,
      'forum_reply' => false,
      'story' => false,
      'fan' => false,
      'album' => false,
      'label' => false,
      'landing_page' => false,
      'review' => false,
      'track' => false,
      'video' => false,
      'video_mashup' => false,
    ),
    'advanced_view' => '--',
    'advanced_view_args' => '',
    'field_name' => 'field_artist',
    'field_type' => 'nodereference',
    'module' => 'nodereference',
    'default_value' => 
    array (
      0 => 
      array (
      ),
    ),
  ),
  1 => 
  array (
    'widget_type' => 'image',
    'label' => 'Photo',
    'weight' => '0',
    'max_resolution' => '1600x1600',
    'image_path' => 'offcial_photos',
    'custom_alt' => 0,
    'custom_title' => 0,
    'description' => 'Your photo size cannot be larger than 1 MB.  If your photo is larger than 1 MB, you will receive a "photo is required" error message.  If this happens, please resize your photo and resubmit.',
    'required' => '1',
    'multiple' => '0',
    'field_name' => 'field_photo',
    'field_type' => 'image',
    'module' => 'imagefield',
  ),
  2 => 
  array (
    'widget_type' => 'text',
    'label' => 'Photographer First Name',
    'weight' => '1',
    'rows' => '1',
    'description' => '',
    'default_value_widget' => 
    array (
      'field_photographer_first' => 
      array (
        0 => 
        array (
          'value' => '',
        ),
      ),
    ),
    'default_value_php' => '',
    'required' => '0',
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => '',
    'allowed_values_php' => '',
    'field_name' => 'field_photographer_first',
    'field_type' => 'text',
    'module' => 'text',
  ),
  3 => 
  array (
    'widget_type' => 'text',
    'label' => 'Photographer Last Name',
    'weight' => '2',
    'rows' => '1',
    'description' => '',
    'default_value_widget' => 
    array (
      'field_photographer_last' => 
      array (
        0 => 
        array (
          'value' => '',
        ),
      ),
    ),
    'default_value_php' => '',
    'required' => '0',
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => '',
    'allowed_values_php' => '',
    'field_name' => 'field_photographer_last',
    'field_type' => 'text',
    'module' => 'text',
  ),
);

After (works):

$content[type]  = array (
  'name' => 'Official photo',
  'type' => 'official_photo',
  'description' => 'Upload official pictures.',
  'title_label' => 'Title',
  'body_label' => 'Caption',
  'min_word_count' => '0',
  'help' => '',
  'node_options' => 
  array (
    'status' => true,
    'promote' => false,
    'sticky' => false,
    'revision' => false,
    'moderate' => false,
  ),
  'fivestar' => 0,
  'fivestar_unvote' => 0,
  'fivestar_stars' => 5,
  'fivestar_style' => 'default',
  'fivestar_position_teaser' => 'hidden',
  'fivestar_position' => 'below',
  'comment' => 2,
  'comment_type' => 'comment',
  'comment_view' => 'node_comments',
  'privatemsg_link' => 
  array (
    'node' => false,
    'teaser' => false,
    'comment' => false,
  ),
  'community_tags_display' => 1,
  'old_type' => 'official_photo',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
);
$content[fields]  = array (
0 => 
array (
  'widget_type' => 'text',
  'label' => 'Photographer First Name',
  'weight' => '1',
  'rows' => '1',
  'description' => '',
  'default_value_widget' => 
  array (
    'field_photographer_first' => 
    array (
      0 => 
      array (
        'value' => '',
      ),
    ),
  ),
  'default_value_php' => '',
  'required' => '0',
  'multiple' => '0',
  'text_processing' => '0',
  'max_length' => '',
  'allowed_values' => '',
  'allowed_values_php' => '',
  'field_name' => 'field_photographer_first',
  'field_type' => 'text',
  'module' => 'text',
),
1 => 
array (
  'widget_type' => 'text',
  'label' => 'Photographer Last Name',
  'weight' => '2',
  'rows' => '1',
  'description' => '',
  'default_value_widget' => 
  array (
    'field_photographer_last' => 
    array (
      0 => 
      array (
        'value' => '',
      ),
    ),
  ),
  'default_value_php' => '',
  'required' => '0',
  'multiple' => '0',
  'text_processing' => '0',
  'max_length' => '',
  'allowed_values' => '',
  'allowed_values_php' => '',
  'field_name' => 'field_photographer_last',
  'field_type' => 'text',
  'module' => 'text',
),
  2 => 
  array (
    'widget_type' => 'nodereference_autocomplete',
    'label' => 'Artist',
    'weight' => '-4',
    'description' => '',
    'default_value_widget' => 
    array (
      'field_artist' => 
      array (
        0 => 
        array (
          'node_name' => '',
        ),
        1 => 
        array (
          'node_name' => '',
        ),
        2 => 
        array (
          'node_name' => '',
        ),
      ),
    ),
    'default_value_php' => '',
    'required' => '1',
    'multiple' => '1',
    'referenceable_types' => 
    array (
      'artist' => true,
      0 => 1,
      'blog' => false,
      'comment' => false,
      'forum' => false,
      'official_photo' => false,
      'page' => false,
      'photo' => false,
      'poll' => false,
      'forum_reply' => false,
      'story' => false,
      'fan' => false,
      'album' => false,
      'label' => false,
      'landing_page' => false,
      'review' => false,
      'track' => false,
      'video' => false,
      'video_mashup' => false,
    ),
    'advanced_view' => '--',
    'advanced_view_args' => '',
    'field_name' => 'field_artist',
    'field_type' => 'nodereference',
    'module' => 'nodereference',
    'default_value' => 
    array (
      0 => 
      array (
      ),
    ),
  ),
  3 => 
  array (
    'widget_type' => 'image',
    'label' => 'Photo',
    'weight' => '0',
    'max_resolution' => '1600x1600',
    'image_path' => 'offcial_photos',
    'custom_alt' => 0,
    'custom_title' => 0,
    'description' => 'Your photo size cannot be larger than 1 MB.  If your photo is larger than 1 MB, you will receive a "photo is required" error message.  If this happens, please resize your photo and resubmit.',
    'required' => '1',
    'multiple' => '0',
    'field_name' => 'field_photo',
    'field_type' => 'image',
    'module' => 'imagefield',
  ),


);
sirkitree’s picture

Btw, I just marked http://drupal.org/node/134921 a duplicate of this, but that one mentions this error also caused by fields as '' that should be 0.

webchick’s picture

subscribing.

dkruglyak’s picture

Component: content.module » General
Status: Active » Needs work

I have been doing quite extensive testing on content_copy.module and tracked down the root cause of these problems.

Import/export ops rely on drupal_execute to find and run the required forms. However in many cases the programmatic execution of forms is broken. Why so? Because many forms rely on PHP includes that happen somewhere else in the modules, starting with Node and CCK. BUT, this could apply to ANY module that provides any component to node forms...

So this is an endemic problem... It can be fixed by looking at your watchdog log to see which forms fail and adding the missing includes somewhere in your own code. At the very least here is what I do in my custom app:

include_once ('./'. drupal_get_path('module', 'node'    ) . '/content_types.inc';
include_once ('./'. drupal_get_path('module', 'content') . '/content_admin.inc');
include_once ('./'. drupal_get_path('module', 'views'    ) . '/views_cache.inc');

 ... includes for other modules, per watchdog errors ...

If anyone can suggest a good way to fix programmatic form execution, maybe this could still make it into D6.

kevin.mcnamee@mailbox.org’s picture

I ran into this problem myself. Your workaround is actually part of the documented usage from the author. Check out:
http://groups.drupal.org/node/5272

As a helper I can recommend replacing

$values['macro'] = /** YOUR CCK EXPORT DUMP HERE **/

with

$filename = /** YOUR PATH GOES HERE **/
$values['macro'] = file_get_contents($filename);

This keeps your imports nice and clean in a separate file. Filename convention? Perhaps my_content_type.content

captainp’s picture

I have been experiencing this "The default value is invalid" on the export of a module rather then importing them. I have been able to manually generate the export file, and then apply the fix to the import process. I was wondering if anyone knew of a way to fix the problem in the export process because it has been quite annoying having to manually generate the export files.

gdd’s picture

subscribe

kenorb’s picture

dkruglyak’s picture

Version: 5.x-1.5 » 5.x-1.x-dev

Reposting my comment from another Import/Export issue that was marked as fixed:
http://drupal.org/node/168526#comment-764486

liquidcms’s picture

just trying to import a pile of types using latest cck 5.x-1.7 and i am still getting these errors on some of my imports:

# The field Retailer (field_retailer) was added to the content type Publisher Retailer, but an error has occured updating the field settings.
Please check the errors displayed for more details.
# An error has occured adding the field Affiliate (field_affiliate).
Please check the errors displayed for more details.
# An error has occured adding the field Rank (field_rank).
Please check the errors displayed for more details.
.
.
.

i guess there is no solution yet?

liquidcms’s picture

as mentioned here i tried simply re-submitting - that doesn't work.

i also tried re-arranging fields: moved noderefs to after text fields (index in $content[fields] array was left untouched however) and this DOES work. I am sure it is not the correct fix; but possibly just having export order fields differently would help??

liquidcms’s picture

Version: 5.x-1.x-dev » 5.x-1.7
Status: Needs work » Active

changed status since i don't see any patch posted here

dkruglyak’s picture

Version: 5.x-1.7 » 5.x-1.x-dev
Status: Active » Needs work

The patch is here: http://drupal.org/node/128038#comment-527467

Unfortunately it is hard to turn it into a .patch file, since we could have different includes depending on what contrib modules are used. If you could think of a way to package a patch to take care of this issue, feel free.

liquidcms’s picture

ok, thanks..but that isn't a patch.. it is just a statement of an understanding of the issue.

not sure why you would set this as being a patch - then people will think the issue is solved and won't be as likely to look for a solution.

dkruglyak’s picture

It is a patch because it is solution recipe. Even if not packaged into a single file.

liquidcms’s picture

Since i am pretty sure this issue has not been addressed yet here is a work around for importing CCK types. As far as i can tell the main issue is with nodereference fields and specifically their ordering in the export file (they need to come last, after other fields). This is mentioned above in #3 and post is correct except that they mention they also re-indexed the field array - this isn't necessary.

I used the following code partially pulled from the group posting listed in #7 above and added code to re-arrange the fields in the export field array. I then re-assembled the $content['macro'] and used that as my new import. The following is code from a module install file which ran on a folder of 17 cck export files (one file for each type) - 4 of these would not import correctly due to noderef fields. Using this install update routine they all imported correctly.

hope this helps and i hope someone can come up with a ptch to fix the content_copy export routine.

/**
* Programmatically create CCK fields and types using the content copy module
* @param $type string
* content type to create, defaults to new type, if type exists, only fields will be added
* @param $macro array
* exported array from content types -> export. If file is not specified, macro will be used
* @param $file string
* path to file containing content copy exported macro data structure. no escaping needed.
*/
function base_create_content($type = '<create>', $macro = '', $file = '') {
  if(!module_exists("content_copy")){
    drupal_set_message('Programmatically creating CCK fields requires the Content Copy module. Exiting.');
    return;
  }
  $values = array();
  $values['type_name'] = $type;
  //get macro import data, prefer file first
  if($file){
    if(file_exists($file)){
      $values['macro'] = file_get_contents($file);
    }
    else{
      drupal_set_message('Unable to read input file for import. Exiting.');
      return;
    }
  }
  elseif($macro){
    $values['macro'] = $macro;
  }
  
  // convert macro to real PHP array and then check if type already exists
  eval($values['macro']);
  if (db_table_exists('content_type_'. $content['type']['type'])) return;
  
  //include required files
  include_once './'. drupal_get_path('module', 'node') .'/content_types.inc';
  include_once('./'. drupal_get_path('module', 'content') .'/content_admin.inc');
  
  // reorder fields so that noderefs are last
  foreach ($content['fields'] as $key => $field) {
    if ($field['widget_type'] == "nodereference_select") {
      unset ($content['fields'][$key]);
      $content['fields'][] = $field;
    }
  }
  
  $typestr  = var_export($content['type'], true);
  $groupsstr = var_export($content['groups'], true);
  $fieldsstr = var_export($content['fields'], true); 
  
  // convert back to string representation of macro
  $values['macro'] = <<<CONTENT
  \$content['type'] = $typestr;     
  \$content['groups'] = $groupsstr;   
  \$content['fields'] = $fieldsstr;
CONTENT;
  
  //import content by executing content copy import form and passing macro
  drupal_execute("content_copy_import_form", $values);
}

// just so that i can force build of CCK Types without uninstalling/re-installing
function csearch_tweaks_update_1() {
  $ret = array();

   // add CCK types
  $path = drupal_get_path('module', 'csearch_tweaks') . "/cck_types";
  $cck_types = glob($path . "/*.txt");
  foreach ($cck_types as $type) {
    base_create_content('<create>', '', $type);
  }

  return $ret;
} 

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

KingMoore’s picture

liquidcms, thanks for that code. that is awesome.

I am having another strange problem though... not sure why but I have one specific option_select field that causes the same errors node reference fields were causing if not at bottom of array. moving the optoin_select to the bottom just before the noderef fields fixes the problem... perhaps this means the problem is not specifically isolated to noderef fields... do we know what is CAUSING this problem in the first place?

liquidcms’s picture

I haven't looked into the field code enough to what the root problem is here - i think the post referenced in #7 discusses it a bit.

i guess shouldn't be too hard to modify my code to move select lists to the bottom as well.

KingMoore’s picture

quick note liquidcms, in your foreach loop above where you are reordering noderef fields, it should include nodereference_autocomplete fields this:

   if ($field['widget_type'] == "nodereference_select" || $field['widget_type'] == "nodereference_autocomplete") {

I couldn't figure out why the code wasn't working for me, and that was why, because I use autocomplete noderef fields! You wouldn't have noticed this had you been using just the _select variety.

Also, if anyone is having FURTHER issues, you could try also adding || $field['widget_type'] == "options_select" after the autocomplete in the line above, as this seems to occasionally fail imports as well *scratch head*

ibragim’s picture

so, i don't understant, we have patch or not?

ibragim’s picture

i also have error with importing content type.
next code don't work:

$content['type'] = array(
 // i have a type, but it's not important  
);
$content['groups'] = array(
 // i have a group, but it's not important  
);
// next, vary important
$content['fields']  = array (
  0 => 
  array (
    'widget_type' => 'text',
    'label' => 'Issues',
    'weight' => '0',
    'rows' => '7',
    'description' => 'Input the Issues concerning the Change Request',
    'field_issues' => 
    array (
      0 => 
      array (
        'value' => '',
      ),
    ),
    'default_value_php' => '',
    'group' => 'group_more',
    'required' => '0',
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => '',
    'allowed_values_php' => '',
    'field_name' => 'field_issues',
    'field_type' => 'text',
    'module' => 'text',
    'default_value' => 
    array (
      0 => 
      array (
        'value' => '',
      ),
    ),
  ),

  1 => 
  array (
    'widget_type' => 'options_buttons',
    'label' => 'Status',
    'weight' => '0',
    'description' => 'Status reflects progress in time of the Change Request development',
    'field_status_3' => 
    array (
      'key' => false,
    ),
    'default_value_php' => '',
    'group' => false,
    'required' => '1',
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => 'In Work 
Frozen for Reviews 
Frozen and Approved ',
    'allowed_values_php' => '',
    'field_name' => 'field_status_3',
    'field_type' => 'text',
    'module' => 'text, optionwidgets',
  ),

  2 => 
  array (
    'widget_type' => 'text',
    'label' => 'DescriptionText ',
    'weight' => '1',
    'rows' => '7',
    'description' => 'Enter the general description of the Change Request',
    'field_descriptiontext' => 
    array (
      0 => 
      array (
        'value' => '',
      ),
    ),
    'default_value_php' => '',
    'group' => false,
    'required' => '1',
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => '',
    'allowed_values_php' => '',
    'field_name' => 'field_descriptiontext',
    'field_type' => 'text',
    'module' => 'text',
  ),
);

But, if i set array $content['fields'][1] (where 'widget_type' => 'options_buttons') to top array $content['fields'] - it's work.
I use next code:

foreach($content as $key1 => $fields) {
	foreach($fields as $key2 => $value) {
	  if ($value['widget_type'] == "options_buttons" && $key2 != 0) {
               $temp = array();
               $temp = $content[$key1][$key2];
               unset ($content[$key1][$key2]);
               array_unshift($content[$key1], $temp);
	  }
	}
	print "<pre>";
	print_r ($content['fields']);
	print "<pre />";
}

KingMoore’s picture

there's no patch atm. just an alternative wrapper method (above) that works.

KarenS’s picture

Status: Needs work » Active

There is no patch, so fix that first. I started digging into this.

There are a slew of problems here, some related to the fact that programmatically submitting forms does not create exactly the same form arrays and structures that you get when you do them normally.

1) One problem is the same one I ran into in D6 #283985: Content copy destroys field settings -- something really funky happens to arrays somewhere and numeric values become boolean values and then break.

2) One problem is that the program is trying to do validation on the default value widget, which is a form (with its own sub-validation) within a form, and it is just too complex to work right in all cases. If that validation fails, all further processing stops, and all later fields get skipped.

3) One problem may be missing include files, as noted somewhere above, but I didn't actually see that problem.

So lots of problems, needing lots of fixes. I think one take-away is that drupal_execute() still has lots of potential problems because of the complexity of the way forms can work.

I fixed #1 in the D6 version by force-feeding the field values to the form, so we may need a similar fix in D5.

The 'illegal choice' and 'That post cannot be referenced' errors seem to be coming from #2, the validation of the default value widget, and we can get around those by skipping that validation on programmatic forms. I'm trying to decide if that's a safe decision to make, but if we're doing this via Content Copy it is definitely safe because the original value was validated when the field was originally created -- we're just copying those values into the export.

As I said, I haven't actually run into a place where #3 was a problem, so I'm not going to worry about that yet.

Anyway, still digging...

KarenS’s picture

Status: Active » Needs work
KarenS’s picture

KarenS’s picture

KarenS’s picture

KarenS’s picture

KarenS’s picture

Status: Needs work » Active
KarenS’s picture

KarenS’s picture

KarenS’s picture

KarenS’s picture

Title: Illegal choice has been detected on Export - Import » Critical failures using drupal_execute() on nodes with CCK fields

Renaming this to reflect the big issue, Content Copy is just one of the implementations of drupal_execute() that is having trouble.

KarenS’s picture

Another issue caused by the default value widget processing is #232425: Help nodereference work with node_import.

KarenS’s picture

I tracked down the problem where array values get switched from numeric to boolean, and it is in the expand_checkboxes() function, which sets the value to isset($value[$key]) . That makes the value true/false instead of 1/0. That true/false value then ends up in the exported results for any node or field values that are set with checkboxes. You can't turn around and do a drupal_execute() in the import on those exported true/false values because the import needs them to be numeric, so things kind of crash and burn at that point.

It looks like this doesn't happen if #value is already set, only if we're letting the the form builder retrieve the values, so I think pre-setting the values with $field and $node values will avoid that.

So, it looks like a couple fixes will take care of most or all of the problems:

1) Skip default value widget processing in the field settings form if the form is #programmed so the form doesn't try to validate the default value element.

2) Force-feed form values to drupal_execute() anytime there are checkboxes in the form (which is probably most of the time).

The last problem has come up a lot in the above issues, and that is when an unexpected value gets sent to nodereference module as a reference -- an array is sent instead of a number or the array has the wrong structure, or whatever. We're going to fix what we're sending in Content Copy but it's complicated and it's easy to see why custom code might get it wrong, so I think we could add a little error-trapping to nodereference to bail out without so much noise (and without stopping all further processing of the form). And userreference could use a similar fix.

dkruglyak’s picture

Wow, that's a lot of duplicates. So what could be the best approach to a fix that would cover them all?

Is there anything else to fix, besides adding the proper includes, per #6?

KarenS’s picture

I'm committing a series of fixes to help the problems with drupal_execute.

1) Backport content_field_instance_collapse() and content_field_instance_expand() into content_crud.inc to make it easier to send (collapsed) field values to drupal_execute(). (Only applies to D5)

2) Use content_field_instance_collapse() to send form values in the Content Copy export to be sure we get the original field values for checkboxes instead of the true/false values we will get otherwise. (Done in both D5 and D6)

3) Alter _content_admin_form() to provide the raw widget default values as well as the default value widget so programmed forms will have those values available. You can't tell when you construct the form if it's a programmed form or not, so we will always have to create the default value widget, but we don't always have to use it. This will also get the default values into the Content Copy export in a way that Content Copy import can pick them up (Done in both D5 and D6)

4) Alter the _content_admin_form() validation to unset the default value widget and skip the default value widget processing if it's a programmed form. Since we are now provided the actual default value (not just the default value widget) in the export, we can safely pick it up in the import. (Done in both D5 and D6)

5) Go back to nodereference and userreference validation and check for $form['#programmed'] and silently fix or ignore some problems.

These changes will get Content Copy working correctly -- it will export and import all values, including default values, and will do so without encountering any errors from the default value widget processing.

These changes should also take care of most problems trying to programmatically create fields, including trying to do so from profiles. That part is not tested, but should work right now.

Anyone trying to use drupal_execute() in other places should try to provide values rather than hope that they will be successfully discovered, using a method similar to what is used in Content Copy -- retrieve the $field value and collapse it into a form_values array using content_field_instance_collapse(), then make whatever changes are needed and send that array to drupal_execute. Someone should write up some instructions on that sometime.

KarenS’s picture

More notes:

The odd behavior noted before where you won't get nodereference errors if you re-arrange the fields is because of a core bug, #260934: Static caching: when drupal_execute()ing multiple forms with same $form_id in a page request, only the first one is validated, which is still unfixed in D7. That bug causes all validation to be skipped for all fields except the first one you export/import. So when you push the nodereference field down the list, it never gets validated at all.

When that bug gets fixed, the original problems would have come back no matter what order you put things in, except that I think I've gotten them mostly worked out of the system.

I've still not run into any places where includes are needed, though. I need an example of when that became an issue.

KingMoore’s picture

Wow great work and explanations KarenS.

joegml’s picture

Anybody have references/links to CCK export/import in D6? Sorry if this is wrong place to post, but I've googled around and haven't found much for D6.

Thanks for any guidance.

yched’s picture

Status: Active » Fixed

Looks like this is fixed now ?

KarenS’s picture

All done except for trying to see if nodereference validation could be more forgiving, which I was going to try to go back and do. But we don't seem to be getting error reports now, so hopefully, yes, this is fixed :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

adamo’s picture

I had all kinds of problems trying to programatically create nodes containing autocomplete nodereference fields via drupal_execute. I was looping through a table in an external DB, then building a node and executing drupal_execute for each record. The CCK fields would only get validated during the first call to drupal_execute. Wrapping everything in the Batch API solved the problem for me.

miiimooo’s picture

Version: 5.x-1.x-dev » 6.x-2.5
Status: Closed (fixed) » Active

I think it's breaking nod reference imports. I have an import script that worked some months ago - god knows why but is broken using latest drupal /cck - this is what I pass to drupal_execute:

  ["field_updateon"]=>
  array(2) {
    [0]=>
    array(1) {
      ["nid"]=>
      array(1) {
        ["nid"]=>
        string(8) "[nid:63]"
      }
    }
    ["nid"]=>
    array(1) {
      ["nid"]=>
      string(2) "63"
    }
  }

It gives a log error

Illegal choice 63 in Update on element.

miiimooo’s picture

Well I found a way of disabling all form validation. Here it is:

function _drupal_execute($form_id, &$form_state) {
  $args = func_get_args();
  $form = call_user_func_array('drupal_retrieve_form', $args);
  $form['#post'] = $form_state['values'];
  form_set_error(NULL, '', TRUE);  // reset all form errors

  drupal_prepare_form($form_id, $form, $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);
  // Only process the form if it is programmed or the form_id coming
  // from the POST data is set and matches the current form_id.
  if ((!empty($form['#programmed'])) || (!empty($form['#post']) && (isset($form['#post']['form_id']) && ($form['#post']['form_id'] == $form_id)))) {
    _drupal_validate_form($form_id, $form, $form_state);

    // form_clean_id() maintains a cache of element IDs it has seen,
    // so it can prevent duplicates. We want to be sure we reset that
    // cache when a form is processed, so scenerios that result in
    // the form being built behind the scenes and again for the
    // browser don't increment all the element IDs needlessly.
    form_clean_id(NULL, TRUE);

    if ((!empty($form_state['submitted'])) && !form_get_errors() && empty($form_state['rebuild'])) {
      $form_state['redirect'] = NULL;
      form_execute_handlers('submit', $form, $form_state);

      // We'll clear out the cached copies of the form and its stored data
      // here, as we've finished with them. The in-memory copies are still
      // here, though.
      if (variable_get('cache', CACHE_DISABLED) == CACHE_DISABLED && !empty($form_state['values']['form_build_id'])) {
        cache_clear_all('form_'. $form_state['values']['form_build_id'], 'cache_form');
        cache_clear_all('storage_'. $form_state['values']['form_build_id'], 'cache_form');
      }

      // If batches were set in the submit handlers, we process them now,
      // possibly ending execution. We make sure we do not react to the batch
      // that is already being processed (if a batch operation performs a
      // drupal_execute).
      if ($batch =& batch_get() && !isset($batch['current_set'])) {
        // The batch uses its own copies of $form and $form_state for
        // late execution of submit handers and post-batch redirection.
        $batch['form'] = $form;
        $batch['form_state'] = $form_state;
        $batch['progressive'] = !$form['#programmed'];
        batch_process();
        // Execution continues only for programmatic forms.
        // For 'regular' forms, we get redirected to the batch processing
        // page. Form redirection will be handled in _batch_finished(),
        // after the batch is processed.
      }

      // If no submit handlers have populated the $form_state['storage']
      // bundle, and the $form_state['rebuild'] flag has not been set,
      // we're finished and should redirect to a new destination page
      // if one has been set (and a fresh, unpopulated copy of the form
      // if one hasn't). If the form was called by drupal_execute(),
      // however, we'll skip this and let the calling function examine
      // the resulting $form_state bundle itself.
      if (!$form['#programmed'] && empty($form_state['rebuild']) && empty($form_state['storage'])) {
        drupal_redirect_form($form, $form_state['redirect']);
      }
    }
  }
}
function _drupal_validate_form($form_id, $form, &$form_state) {
  // If the session token was set by drupal_prepare_form(), ensure that it
  // matches the current user's session.
  if (isset($form['#token'])) {
    if (!drupal_valid_token($form_state['values']['form_token'], $form['#token'])) {
      // Setting this error will cause the form to fail validation.
      form_set_error('form_token', t('Validation error, please try again. If this error persists, please contact the site administrator.'));
    }
  }

//   _form_validate($form, $form_state, $form_id);
}

Now calling _drupal_execute instead of drupal_execute skips any validation. Wonder what problems that may bring though.

miiimooo’s picture

Status: Active » Closed (fixed)

For reference - I found the problem in the end: 18n rewrites messed up the import in my case. Hope it helps someone else.

dpatte’s picture

I upgraded views today, and this problem suddenly occurred for me. I am using a views generated select list in one of my content types and it is unexpectedly broken, and trying to edit it generates the same 'this post can't be referenced.' error.

mitchell’s picture

Status: Closed (fixed) » Active

Re-opening.

KarenS’s picture

Version: 6.x-2.5 » 5.x-1.x-dev
Status: Active » Closed (fixed)

Someone switched this from a D5 to a D6 issue and we don't do that. The D5 and D6 code is different, they get different issues.

The problem in #50 is a totally different problem than what this thread is about. This thread is about using drupal_execute(), especially where it is used in Content Copy and #50 has nothing to do with drupal_execute() or Content Copy.

There is a core problem with the way drupal_execute() works that causes our problems but we don't fix it by hacking core, as in #48. I do not recommend doing that.

The array you are passing in #47 is incorrectly formed, it doesn't match what the widget uses.

craig_’s picture

Version: 5.x-1.x-dev » 6.x-2.6
Category: bug » task
Priority: Critical » Minor

Adding some more debugging help for people who might still be getting stuck on using drupal_execute to import CCK types that they have exported to a file. The recommendation above is to use file_get_contents($file), but there are some gotchas to watch out for.

When getting error message 'Illegal choice (yourtype) in Content type element.'
1. The import is expecting the string '' (case-sensitive) in $values['type_name'], not your type name

When getting error message 'The import data is not valid import text.'
1. Copy/paste the file data into the form at Content Management->Content Types->Add Content Types
2. Submit and look for messages about missing dependencies (number, nodereference, etc)
3. If all seems OK up to this point, check your file encoding. I have been creating some files on a win32 system, and using UTF-8 encoding. The UNIX server has been handling the files for almost all cases. But, when using file_get_contents($file), the encoding must be UNIX (not DOS), and not unicode or UTF-8