I'm getting the following runtime error in my PHP's error_log:

[Thu Jul 31 20:54:59 2014] [error] [client 98.176.242.59] PHP Fatal error: Cannot create references to/from string offsets nor overloaded objects in /var/www/drupal-7.27/includes/common.inc on line 6606, referer: http://myserver/mypath/summary?field_log_time_value%5Bvalue%5D%5Byear%5D...

and that URL results in a blank (white) screen.

I searched for this PHP error and saw a posting where someone said they upgraded their PHP and it fixed their problem. So I upgraded from 5.3.3 to 5.5.14 but the error and problem persist.

Please help!

(Note, I tried to search for the above title in the 7.27 core issues but got a blank page instead so please excuse this posting if it is duplicate or answered elsewhere. If it is answered elsewhere, I would appreciate a link to that page, thanks!)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

monaw’s picture

Issue summary: View changes
dcam’s picture

Status: Active » Postponed (maintainer needs more info)

Hello! I'm sorry you're experiencing this problem. Unfortunately, there's probably not enough information here to debug it.

The only reason I qualified that statement with "probably" is because of the URL you included in your post. I see a field name in it, field_log_time_value. Are you familiar with this field? Is it part of a contributed module? If so, has that module been updated? Have you tried uninstalling it and reinstalling it?

Otherwise, a good starting point would be to tell us how to reproduce the issue with a clean install of Drupal 7. If you can't, let us know what contributed modules you have installed. Enable them on a clean test site one-by-one until you can reproduce the error.

It sounds to me like there is a bug in a contrib module that you're using, so that is where I would check.

monaw’s picture

Thank you for your reply dcam.

"field_log_time_value" is a field in a View. The field comes from one of my content types so it does NOT come from a contributed module.

Perhaps I should post the problem in the Views module? There error message pointed to core's common.inc so that's why I'm posting it here...please let me know if you feel I should post the problem in the Views issue queue or work on reproducing the problem with a clean install of 7...thanks!

dcam’s picture

Ok, that's helpful to know. I should have guessed that it's a view. I did notice that it looked like a search query string.

I doubt that this is a core issue. Something is mis-using the core API function drupal_array_set_nested_value(), calling it with an incorrect parameter. Line 6606 is the function declaration. Views may be doing it, but I can't know for certain. Ultimately, I think you'll have to report this in a contrib issue queue.

Although you may be having trouble with Views, it may not be Views' fault. You didn't mention what module is creating this date field. I'll assume it's the Date module. Like most other contributed modules that provide fields, Date has to tell Views how to interact with its field. So it's possible (I would dare to say that it's likely) that the field-providing module is the one at fault. So check that module's issue queue for other reports of this problem.

Before that, however, I would check some other things. I notice that this particular URL has two query parameters for the same field. Of course, I can see that this is a multi-valued date field, but I wonder if it works correctly in the fallback case. What happens if there is no month parameter and then if there are no parameters? Does it work in either of those cases? It might be useful information for the contrib maintainers to know.

dcam’s picture

I forgot to say that this may be unrelated to the date field. It could be caused by some other field that the view is using. Have you tried removing components (fields/filters/sorts) from the view one-by-one until the problem stops? That could help you narrow down the problem.

monaw’s picture

> You didn't mention what module is creating this date field. I'll assume it's the Date module.

Yes, the date field is using the Date module. I've reported the problem to that module's issue queue (https://www.drupal.org/node/2315365). There is a new runtime error about the Date module now that appears before the common.inc error so you are probably right about the Date module causing the problem.

> What happens if there is no month parameter and then if there are no parameters? Does it work in either of those cases?

If there is no month parameter in the URL, then a warning is displayed that says "Please choose a month". If there is no parameters at all, then that's when I get the white screen and the PHP fatal error message posted at the start of this issue.

jelo’s picture

I had this with an exposed date field. Details posted at https://www.drupal.org/node/1995056

vaza18’s picture

Version: 7.27 » 7.32
Component: comment.module » forms system
Status: Postponed (maintainer needs more info) » Needs work
FileSize
50.09 KB
15.44 KB
7.59 KB
195.5 KB

Steps to reproduce:

  1. Create node with date field (date module)
  2. Create views with this node type and with exposed filter by date field with select widget. Limit to 10 the number of nodes on one page, leave pagination enabled
    views exposed filter by date.png
  3. Create more than 10 nodes of this type
  4. Open the view with list of nodes and exposed filter
  5. In the pagination right mouse click on 2nd page -> open in new tab
    open second page in new tab.png
  6. You will see that exposed options became arguments in the URL:
    exposed_options_are_arguments_in_the_url.png
  7. And here is where a magic starts. Date format expects arrays in arguments but let's change it to string:
    manually_input_arguments_in_url.png
vaza18’s picture

vaza18’s picture

Status: Needs work » Needs review
vaza18’s picture

This solution looks better than previous one.

vaza18’s picture

Version: 7.32 » 7.35

Status: Needs review » Needs work

jcarrothers’s picture

The patch from comment #12 solved my issue. Tested under Dupal core 7.36

dcam’s picture

Status: Needs review » Closed (duplicate)

#1995056: Exposed grouped filter gives WSOD+error "Cannot create references to/from string offsets nor overloaded objects" confirms that this is an issue with Views. For those of you who are experiencing the problem, try the patch in #1995056-6: Exposed grouped filter gives WSOD+error "Cannot create references to/from string offsets nor overloaded objects". If it solves your problem please report back to that issue and consider setting it to RTBC. I'm closing this issue as a duplicate.

@vaza18
We appreciate your attempt to patch the issue, but unfortunately it's no good. While it might stop the problem, it's not a solution. It's just a workaround that's masking problems with forms.

vaza18’s picture

OK, but original problem has not been solved so far. That's why the patch from comment #12 is only way to workaround an error at the moment.

dready2011’s picture

ameyj’s picture

Patch #25 in https://www.drupal.org/node/1995056#comment-10768266 didn't fix the issue for me. However Patch from Comment #12 in this thread fixed it for me. Is this patch ever going to make it to core or is this still thought of as a duplicate?

SocialNicheGuru’s picture

Status: Closed (duplicate) » Reviewed & tested by the community

Number #12 from this queue fixed it. the other issue does not. https://www.drupal.org/node/1995056

Fabianx’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs issue summary update

Could someone please update the issue summary?

This is a really hard to understand bug and I don't get neither how it happens nor why the patch would fix it.

attiks’s picture

Version: 7.35 » 7.52

Ran into the same error after updating to 7.52 (including lots of contrib updates), requested page is /node/add

in drupal_array_set_nested_value called at /srv/www/html/includes/common.inc (6769)
in drupal_array_set_nested_value called at /srv/www/html/includes/form.inc (2098)
in _form_builder_handle_input_element called at /srv/www/html/includes/form.inc (1865)
in form_builder called at /srv/www/html/includes/form.inc (1927)
in form_builder called at /srv/www/html/includes/form.inc (1927)
in form_builder called at /srv/www/html/includes/form.inc (886)
in drupal_process_form called at /srv/www/html/includes/form.inc (386)
in drupal_build_form called at /srv/www/html/includes/form.inc (131)
in drupal_get_form called at /srv/www/html/modules/node/node.pages.inc (78)
in node_add called at ? (?)
in call_user_func_array called at /srv/www/html/includes/menu.inc (527)
in menu_execute_active_handler called at /srv/www/html/index.php (21)
attiks’s picture

#23 I've used the patch in #1995056-25: Exposed grouped filter gives WSOD+error "Cannot create references to/from string offsets nor overloaded objects" and it fixed most of the errors we got, but I also needed the patch #12 from this issue. Both patches were applied 7 days ago, errors are gone and no side effects.

RTBC for me, but will leave it as NR

Fabianx’s picture

#25: Could you explain a little more when and why this error happens, please?

And especially: Do you have steps to reproduce this on a core vanilla Drupal?

oturpin’s picture

Hi All,

Applied patch #12 AND the patch in #1995056-25: Exposed grouped filter gives WSOD+error "Cannot create references to/from string offsets nor overloaded objects" : No more error...

What is the release of drupal that will contain this patch ?

Thx

jozzy_a’s picture

Version: 7.52 » 7.53

:BUMP: for this patch to be merged into core. This issue exists on 7.53 as well and becomes an issue when migrating from PHP 5.4 to PHP 7.1

gifad’s picture

FWIW, I had this error in any node/add/%type or node/%node/edit if I click "Save" after "Preview".

Drupal 7.54, php 7.0.14, nothing fancy, except "book" module is active…

Patch at #12 fixes the issue !

Fabianx’s picture

Issue tags: +PHP 7.1, +PHP 7.0 (duplicate)

Tagging with PHP 7

bendev’s picture

patch #12 successfully solved the issue in my case as well

jurgenhaas’s picture

I have also tested #12 successfully.

smustgrave’s picture

#12 worked for me but I got a "Hunk #1 succeeded at 2095 (offset 46 lines)" warning. Rerolled the patch just in case anyone else was getting the same.

Marc DeLay’s picture

If anyone is getting this error when working with custom forms:
I had this error because I had multiple submit buttons on a form and there was a #name collision between some of them.

eg:

 $form['byaddress']['submit'] = array(
    '#type' => 'submit',
    '#name' => 'search-byaddress',
    '#value' => 'Submit',
  );

  $form['search']['submit'] = array(
    '#type' => 'submit',
    '#name' => 'search',
    '#value' => 'Go',
  );

Once I changed the name of the second submit button the error was gone.

attiks’s picture

Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

Ran into the same problem using PHP 7 #33 fixes it

xCode77’s picture

When will the patch from #33 merged to core?

ikphilip’s picture

Encountered this issue using Drupal 7.56 on node form save which snagged on a select option which was A.) #type = hidden and B.) left empty (no selection), server running C.) PHP 7.1.x

Changing A, B, or C (to 7.0.x) resolved errors. Applying #33 resolved errors successfully.

David_Rothstein’s picture

Version: 7.53 » 7.x-dev
Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

Please see comments from @dcam and @Fabianx above - this issue needs clear steps to reproduce and an explanation of why this is a bug in core rather than something triggered by incorrect contrib/custom code.

At first glance this patch does not look like something we would want to do because it could clobber other things in $form_state['input'] that are supposed to be there.

Also, if this is something that needs to be fixed in core, it needs to be evaluated for Drupal 8 as well.

mbatterton’s picture

Patch #33 has worked perfectly for me trying to fix the invite module form.

dgtlmoon’s picture

Issue tags: +PHP 5.6

I can confirm this is an issue with PHP 5.6.33 also, so I don't believe it's PHP5/PHP7 specific

Patch #33 worked for me but I don't yet fully understand why.

What broke my site was after installing the [elements] module, then I performed a hook_form_alter and changed a type..

$form['customer_phone_number'][LANGUAGE_NONE][0]['#type'] = 'telfield';

after this, kaboom..

dgtlmoon’s picture

#763376: Not validated form values appear in $form_state seems to be related this

commit 83c52c3b1a39a10d3f0624ea640f7e211c2061a2
Author: Angie Byron <webchick@24967.no-reply.drupal.org>
Date:   Fri Aug 27 11:54:32 2010 +0000

    #763376 by fago, sun, noahb, effulgentsia, ksenzee, jhodgdon: Fixed Not validated form values appear in ().
DamienMcKenna’s picture

I'll second the notion that this comes up because the form structure is broken. In my case I changed the '#type' of a term reference field to "hidden", which caused the form to blow up on form save, changing my custom override code to use a different method to hide that field solved the problem for me.

Also, I've committed that Views fix, so the next release won't show the problem anymore.

wesleymusgrove’s picture

#2955023: Error: Cannot create references to/from string offsets in drupal_array_set_nested_value() seems to be related. I'm switching from PHP 5.6 to PHP 7.1 and encountered this error on a Drupal Commerce checkout review page. I have a hidden fieldset around the default payment method radio buttons that required me to also specify ['#access'] = FALSE or ['#disabled'] = TRUE. Either one worked and allowed me to continue to the checkout payment page.

<?php
function example_commerce_form_alter(&$form, &$form_state, $form_id) {
  //If we're altering a commerce checkout form that has the payment method radio buttons, hide it because we are implementing our own payment method and don't need to see the radio buttons.
  if (strpos($form_id, 'commerce_checkout_form_') === 0 && !empty($form['commerce_payment']['payment_method'])) {
    $form['commerce_payment']['#type'] = 'hidden';
    
    //Adding this fixes it
    $form['commerce_payment']['#access'] = FALSE;

    //Or this
    $form['commerce_payment']['#disabled'] = TRUE;
  }
?>
DuneBL’s picture

I confirm #33 solve my issue.
This could be related to a switch to php 7.1
I also had to resave the view which was producing the problem...

ladybug_3777’s picture

I can confirm that #33 also fixed the issue for me on php 7.1

bendygirl’s picture

On my move to php 7.1 I had this error also come up. I'm on Drupal 7 and the most current version of drupal core. I started with patch 12 and that worked for me. Going to go with #33 now since it's the more recommended fix.

vikramy’s picture

I can also confirm that #33 also fixed the issue for me on php 7.2

vikramy’s picture

Issue tags: +PHP 7.2
ben.hamelin’s picture

Diddo! I can also confirm that #33 also fixed the issue for me on php 7.2

javi-er’s picture

Not sure if my comment is helpful at this point but I was having the same issue and #33 fixed it for me on PHP 7.2

Amir Simantov’s picture

#33 also works for me.

Should go to release.

jrearick’s picture

Patch #33 worked for me, but I didn't really test it for any other consequences. However, I was able to avoid the patch by changing my custom module code.

In our case in our hook_form_FORMID_alter() we looped through the $form array making all the $form_ items hidden

if ($key !== "field_uri" && $key_prefix === 'field_') {
  $form[$key]['#type'] = 'hidden';
}

Changing $form[$key]['#type'] = 'hidden'; to $form[$key]['#access'] = FALSE; solved the issue for us. It was getting hung up on a field that had a #type of 'container' before, so I think changing the #type to 'hidden' probably messed up some logic somewhere down the line.

I hope this helps anyone else trying to figure out this problem.

james.williams’s picture

Thanks @jrearick - that was exactly our situation! Drupal's form processing happily recurses on input elements (including elements with the 'hidden' type) that contain further input elements. Field structure elements are an example of this, if the top level (normally just a container type element) is changed to be hidden, as down under the language & delta levels, there's usually a normal input element.

Under PHP 5.3, form_builder() would initially set the top-level hidden element value in $form_state['input'] to an empty string, then replace that with an array structure (containing NULL in the child input element). So that suggests that the patch in #2313517-33: Cannot create references to/from string offsets nor overloaded objects that uses the force parameter would put the 'original' behaviour back, of replacing the empty string from the higher-level input element with the array structure for the lower-level input element.

Whether that original behaviour is a good thing or not is probably a different question, but I imagine any change to it would be considered backwards-incompatible anyway really.

Pancho’s picture

I didn't research this much, however it kind of fixed an ajax trigger on a custom entity edit form which previously kept responding with following AJAX HTTP error message:

ResponseText: Warning: Illegal string offset 'value' in Drupal\Component\Utility\NestedArray::setValue() (line 155 of /var/www/html/testing/web/core/lib/Drupal/Component/Utility/NestedArray.php). => Array

Note in this context that for a textfield to take an AJAX callback I also had to set the #type again manually.
As the following screenshot shows, #type came set in ['field']['widget']['0']['value']['#type'] rather than in ['field']['widget']['0']['#type'].
Screenshot

So unless I set the #type again, the AJAX callback wouldn't get attached at all. The following in buildForm() worked, though the first line shouldn't be necessary:

   $form['iban']['widget']['0']['#type'] = 'textfield';
   $form['iban']['widget']['0']['#ajax'] = [...]

The deeper cause of the NestedArray issue may however go back to that other issue, so possibly this one here is a "Works as designed" while the underlying issue(s) need to be fixed.

Anway, as David Rothstein said in #38, this will have to be fixed in Drupal 8 before it would be backported to Drupal 7. So here's a patch against Drupal 8.6-dev. Waiting for the test results and your feedback.

suparnaa.dey’s picture

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

jerrac’s picture

Judging from the fact the patch in #54 basically does what I did when I edited NestedArray.php, I'm running into this bug as well with a custom field widget.

I just manually edited FormBuilder.php line 1247 to test what the patch in #54 does, and got the same result as when I edited NestedArray.php.

Both methods get me past the "Cannot create references to/from string offsets" error when clicking "Add another item". And when saving, that error does not show up, but I do get a white screen and my logs say php ran out of allowed memory.

If it helps, I made gists of my custom field files and linked them in this forum topic: https://www.drupal.org/forum/support/module-development-and-code-questio...

nelsongrin’s picture

The patch #33 worked for me.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

AaronBauman’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

Patch #33 works for me as well.
Needs a test to demonstrate the bug and prove solved.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

sharonho’s picture

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

alansaviolobo’s picture

+1 for patch #62

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

tondeuse’s picture

#52 fixed my issue in a D7.94 php 7.4 site with media-7.x-2.30. Thank you!
The culprit was in a hook_form_alter() using ['#type'] = 'hidden';

apaderno’s picture

Issue tags: -PHP 7.0 (duplicate)

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.