expects an array, not a scalar - Fatal error: Cannot create references to/from string offsets

Fatal error: Cannot create references to/from string offsets nor overloaded objects in ..../includes/common.inc on line 6726

Hello

I did apply the patch in Drupal 7.41, but I'm still getting the same error above.

do you have any idea of what I am getting the same error again.

Thanks

I've applied the patch and it correctly solved the issue.

I can provide a little more information about the issue. I've also solved it with a workaround implementing the next hook_form_alter:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function custom_form_views_exposed_form_alter(&$form, &$form_state) {
  if ($form['#id'] == 'views-exposed-form-view-id') {
    $form['field_date']['value']['#default_value'] = FALSE;
    $form_state['input']['field_date']['value'] = FALSE;
  }
}

The error comes from somewhere where the input is assigned an empty string instead of a FALSE. This causes this if to be used:

if ($input !== FALSE) {
  $return = $input;
  $date = date_select_input_date($element, $input);
}

Found here: https://cgit.drupalcode.org/date/tree/date_api/date_api_elements.inc#n449

And as the $return variable is overridden there, this causes the next code to try to use a string as an array, generating the reported error:

foreach ($granularity as $field) {
  if ($field != 'timezone') {
    $return[$field] = date_is_date($date) ? $date->format($formats[$field]) : '';
  }
}

Found here: https://cgit.drupalcode.org/date/tree/date_api/date_api_elements.inc#n465

The above patch is part of the solution to this problem, but it goes deeper. This issue is still happening after I apply the patch, and I think I've tracked down where it is occurring. In views/includes/view.inc, in view::get_exposed_input(), we see this snippet:

// Fetch exposed input values from $_GET. Overwrite if clashing.
foreach ($_GET as $key => $value) {
   if (!in_array($key, array('page', 'q'))) {
      $this->exposed_input[$key] = $value;
   }
}

$this->exposed_input is then directly assigned to $form_state['input'] in the form constructor for views_exposed_form (this is done so that GET requests force Drupal to process form submission). (See views.module, views_exposed_form() function.)

When parsing a form element's input, Drupal assumes that the input structure matches the structure defined in the form element (i.e. assumes it got an array where an array was expected, or a scalar where a scalar was expected). When an array (or nested array) is expected, and a scalar (or an insufficiently-nested array) is received, Drupal chokes, and in the case of PHP 7.1, dies in a most undignified fashion.

Example: Let's say I have a view with an exposed date filter whose URL is as follows:
http://example.com/myview?field_date[value][year]=2018
But if I manually change the URL as follows, I generate a fatal error, at least under PHP 7.1:
http://example.com/myview?field_date[value]=2018
This is because Drupal expected $form_state['input']['field_date']['value'] to be an array, and it is in fact a scalar.

In the view::get_exposed_intput() method, views need some way of comparing the incoming data structure with the form's expected data structure, and either massaging it into shape or discarding it. Possibly this could be done via callbacks or hooks? Anyway, I don't think this is directly the fault of the date_views module; it's just that this is the most prominent contrib module that exposes form input data as an array.

My guess is that any resolution to this issue will require the views team and the date team to be working in tandem.

This patch prevents the fatal error on views exposed filter forms by detecting when the expected input should be an array but the actual input is a scalar. This is by no means ready for production, but I thought this could be the start of a proper discussion how to handle this within the date module (and its submodules) without having to get the Views team involved.

This patch probably works optimally in conjunction with the patch from issue 2889759.

This patch catches more cases that generated fatal errors.

update title because too many titles similar to original title.

Function create_function() is deprecated in php 7.2

actually, that function create_function probably not related to the patch.

#8 worked for me.

#8 works well, thank you!

According to this PHP RFC, uniqid() may be deprecated in future versions of PHP, so I have re-rolled the patch from #8 to eliminate it.

I reviewed the differences between the two patches, and while an interdiff would have been appreciated, the difference is negligible.

Committed. Thank you.

This broke the Search API Views integration with a fatal error, patch in #3132404: Support Date module version 2.11-beta3.

The approach in number 5 might be better?

Hm, but this has now been released (although just as beta), so I think we cannot change this to not break existing sites that rely on it. Should we still do the approach in #5? Probably best if you create a new issue and describe what the remaining fix should be and why.