We love webform and have used it a lot in D6 websites. However, in our first D7+PHP 5.4 site we have run into this very annoying PHP warning when we define a default value for a date field.

Some default vaules we have tested include '-7 years' and '+3 days'.

The issue appears to be similar to this one, http://drupal.org/node/1463678, and several others in that the default date has array indexes of 'day', 'month', or 'year' which PHP 5.3 would cast to an int 0 and thereby avoid the warning...Apparently PHP 5.4 leaves it as a string causing the warning.

My problem is I am not sure where a fix needs to be applied, in the webform code that calls form_process_date or in Drupal 7 includes/form.inc. My apology if this is more appropriate for a D7 core bug report.

I will keep looking at the code and see if I can come up with an appropriate fix, but I would prefer someone more familiar with webform and/or Drupal's form.inc code think about this as well.

Comments

Andy Dorman’s picture

uh, the line number in the original report is from Drupal 7.14.

Looking at the git repo I see form.inc has been revised and the problem line number is now 2982. I looked at the commit logs since 7.14 and did not see anything that might have resolved this issue in 7.15

Andy Dorman’s picture

Well, I am not suggesting this is the smartest fix for this issue. This may just be a bandaid.

What I did was add a line below to webform/components/date.inc that sets $element['#value'] if a default is defined before passing $element to form_process_date. This gives $element['#value'] appropriate array indexes for when Drupal includes/form.inc tries to set them so PHP 5.4 does not complain.

function webform_expand_date($element) {
  // Accept a string or array value for #default_value.
  if (!empty($element['#default_value']) && is_string($element['#default_value'])) {
    $timezone = $element['#timezone'] != 'user' ? NULL : 'user';
    $timestring = webform_strtodate('c', $element['#default_value'], $timezone);
    $element['#default_value'] = webform_date_array($timestring, 'date');
+    $element['#value'] = $element['#default_value'];
  }

  // Set defaults according to existing #default_value (set by Form API)
  if (isset($element['#default_value']['month']) || isset($element['#default_value']['day']) || isset($element['#default_value']['year'])) {
    $default_values = array(
      'month' => $element['#default_value']['month'],
      'day' => $element['#default_value']['day'],
      'year' => $element['#default_value']['year'],
    );
  }
  else {
    $default_values = array(
      'day' => NULL,
      'month' => NULL,
      'year' => NULL,
    );
  }

  // Let Drupal do it's normal expansion.
  $element = form_process_date($element);
...
peacog’s picture

Status: Active » Needs review
StatusFileSize
new556 bytes

Thanks for the fix. I've rolled Andy's fix into a patch. As he says, this might not be the best way to resolve the issue, so hopefully a maintainer will cast an eye over it and improve it if necessary.

quicksketch’s picture

I'm not sure we can set the #value property. I think that will cause the value to be unchangeable by the end-user. No matter what value they set, if you have a #value on a field it will override the user's input upon save. I haven't tried out this particular patch yet to see if it has that effect, but I'm wary of setting #value directly like this; it seems like it's likely to have an unexpected effect.

jjmackow’s picture

I'm running into this same issue;
I 'm using webform with dates, the issue only manifests itself when a default "relative" date is entered in the webform. ie +1 months;

Peacog's patch worked fine for me. Thank you!

jjmackow’s picture

The issue is back again in webform 7.x-4.0-alpha4 ; for the time being, Even with the patch;

I rolled back to PHP version 5.3.26 (drupal 7.22) and things worked OK again.

quicksketch’s picture

Status: Needs review » Postponed (maintainer needs more info)

Thanks @jjmackow. I don't have any PHP 5.4 servers accessible currently, so any additional input on this issue would be appreciated. #1923192: PHP 5.4: Webform and Date components: Illegal string offset in form_process_date() on line 2961 in includes\form.inc was marked a duplicate of this one.

Anonymous’s picture

I also have this issue with the latest version (alpha 4) + drupal 7.23.

My server is running with PHP 5.4.16.

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

I cleared my cache, and tried to delete / recreate the field without success.

I only have these warning when I use "today" or "now" as default values for the date field.

Thank you for your help,

Philippe

TBarina’s picture

Same error here.

TBarina’s picture

What about adding this in module webform/components/date.inc:

function webform_expand_date($element) {
// Accept a string or array value for #default_value.
if (!empty($element['#default_value']) && is_string($element['#default_value'])) {
$timezone = $element['#timezone'] != 'user' ? NULL : 'user';
$timestring = webform_strtodate('c', $element['#default_value'], $timezone);
$element['#default_value'] = webform_date_array($timestring, 'date');
}
+ if (!empty($element['#value']) && is_string($element['#value'])) {
+ $timestringvalue = webform_strtodate('c', $element['#value'], $timezone);
+ $element['#value'] = webform_date_array($timestringvalue, 'date');
+ }

?
Do you think it can solve the issue?

quicksketch’s picture

There's a patch at #2079665: Patch fixes undefined index warning on date fields (PHP 5.4) that might also solve this problem.

sonicthoughts’s picture

#11 is good.

quicksketch’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

Cool, let's use the less-dangerous version at #11 then. Thanks for your feedback @sonicthoughts.

jorisx’s picture

Issue summary: View changes

was this already committed in a dev release ??
I still have the issue and the patch from from #11 seemed to solve this.
using:
webform; 7.x-3.20
drupal; 7.27
php; 5.4.29

danchadwick’s picture

was this already committed in a dev release ??

It was committed to the 7.x-4.x branch. I suggest you update since the 3.x branch is not seeing development with the impending stable release of 7.x-4.x.