When I use a date field, I get errors:

Warning: Illegal string offset 'month' in form_process_date() (line 2975 of /srv/www/drupal/includes/form.inc).
    Warning: Illegal string offset 'day' in form_process_date() (line 2975 of /srv/www/drupal/includes/form.inc).
    Warning: Illegal string offset 'year' in form_process_date() (line 2975 of /srv/www/drupal/includes/form.inc).

The date component has nothing unusual. I used today as the default date.

Comments

tjtj’s picture

Removing today fixes this, but I am supposed to be able to use GNU date designators.

quicksketch’s picture

Status: Active » Postponed (maintainer needs more info)

I can't confirm this problem. A new release came out today, could you check if it still exists in beta2? I set up a new date component using "today" as the default value and it works as expected, with no warnings or notices.

sfcamil’s picture

Webform 7.x-3.20+9-dev

Same problem using

$form['submitted']['person_fieldset']['birth_date_person']['#default_value'] = date('d-m-Y', (drupal_substr($viewDetailPerson[0] -> PERS_BIRTH_DATE, 6)) / 1000);

Warning: Illegal string offset 'day' in form_process_date() (line 2975 of xampp\htdocs\asmt\includes\form.inc).
Warning: Illegal string offset 'month' in form_process_date() (line 2975 of xampp\htdocs\asmt\includes\form.inc).
Warning: Illegal string offset 'year' in form_process_date() (line 2975 of xampp\htdocs\asmt\includes\form.inc).

But the date is correctly inserted in form !
all the fields date in config was changed to d-m-Y

quicksketch’s picture

@sfcamil: When setting a #default_value, it needs to be specified as an array:

$form['submitted']['person_fieldset']['birth_date_person']['#default_value'] = array(
  'year' => 2014,
  'month' => 3,
  'day' => 25,
);

Webform does the conversion from a string for you from the UI options. If you're form altering the form, you have to use the more explicit array-based format.

quicksketch’s picture

Category: Bug report » Support request
Status: Postponed (maintainer needs more info) » Closed (fixed)

Seems like this is fixed. It was a custom coding problem anyway, which is outside our issue queue scope.