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!)
Comments
Comment #1
monaw CreditAttribution: monaw commentedComment #2
dcam CreditAttribution: dcam commentedHello! 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.
Comment #3
monaw CreditAttribution: monaw commentedThank 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!
Comment #4
dcam CreditAttribution: dcam commentedOk, 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.
Comment #5
dcam CreditAttribution: dcam commentedI 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.
Comment #6
monaw CreditAttribution: monaw commented> 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.
Comment #7
jelo CreditAttribution: jelo commentedI had this with an exposed date field. Details posted at https://www.drupal.org/node/1995056
Comment #8
vaza18 CreditAttribution: vaza18 commentedSteps to reproduce:
Comment #9
vaza18 CreditAttribution: vaza18 commentedComment #10
vaza18 CreditAttribution: vaza18 commentedThis patch fixes the issue for me
Cannot create references tofrom string offsets nor overloaded objects-2313517-9777319.patch
Comment #11
vaza18 CreditAttribution: vaza18 commentedComment #12
vaza18 CreditAttribution: vaza18 commentedThis solution looks better than previous one.
Comment #13
vaza18 CreditAttribution: vaza18 commentedComment #17
jcarrothers CreditAttribution: jcarrothers commentedThe patch from comment #12 solved my issue. Tested under Dupal core 7.36
Comment #18
dcam CreditAttribution: dcam commented#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.
Comment #19
vaza18 CreditAttribution: vaza18 commentedOK, 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.
Comment #20
dready2011 CreditAttribution: dready2011 commentedPatch 25 in https://www.drupal.org/node/1995056#comment-10768266 solved it for me.
Comment #21
ameyj CreditAttribution: ameyj commentedPatch #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?
Comment #22
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedNumber #12 from this queue fixed it. the other issue does not. https://www.drupal.org/node/1995056
Comment #23
Fabianx CreditAttribution: Fabianx as a volunteer commentedCould 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.
Comment #24
attiks CreditAttribution: attiks at Attiks commentedRan into the same error after updating to 7.52 (including lots of contrib updates), requested page is /node/add
Comment #25
attiks CreditAttribution: attiks at Attiks commented#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
Comment #26
Fabianx CreditAttribution: Fabianx as a volunteer commented#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?
Comment #27
oturpin CreditAttribution: oturpin commentedHi 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
Comment #28
jozzy_a CreditAttribution: jozzy_a commented: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
Comment #29
gifad CreditAttribution: gifad commentedFWIW, 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 !
Comment #30
Fabianx CreditAttribution: Fabianx as a volunteer commentedTagging with PHP 7
Comment #31
bendev CreditAttribution: bendev at WebstanZ commentedpatch #12 successfully solved the issue in my case as well
Comment #32
jurgenhaasI have also tested #12 successfully.
Comment #33
smustgrave CreditAttribution: smustgrave commented#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.
Comment #34
Marc DeLay CreditAttribution: Marc DeLay as a volunteer commentedIf 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:
Once I changed the name of the second submit button the error was gone.
Comment #35
attiks CreditAttribution: attiks at Attiks commentedRan into the same problem using PHP 7 #33 fixes it
Comment #36
xCode77 CreditAttribution: xCode77 commentedWhen will the patch from #33 merged to core?
Comment #37
ikphilipEncountered 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.
Comment #38
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedPlease 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.
Comment #39
mbatterton CreditAttribution: mbatterton commentedPatch #33 has worked perfectly for me trying to fix the invite module form.
Comment #40
dgtlmoon CreditAttribution: dgtlmoon commentedI 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..
Comment #41
dgtlmoon CreditAttribution: dgtlmoon commented#763376: Not validated form values appear in $form_state seems to be related this
Comment #42
DamienMcKennaI'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.
Comment #43
wesleymusgrove CreditAttribution: wesleymusgrove commented#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.
Comment #44
DuneBLI 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...
Comment #45
ladybug_3777 CreditAttribution: ladybug_3777 commentedI can confirm that #33 also fixed the issue for me on php 7.1
Comment #46
bendygirl CreditAttribution: bendygirl commentedOn 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.
Comment #47
vikramy CreditAttribution: vikramy as a volunteer commentedI can also confirm that #33 also fixed the issue for me on php 7.2
Comment #48
vikramy CreditAttribution: vikramy as a volunteer commentedComment #49
ben.hamelin CreditAttribution: ben.hamelin commentedDiddo! I can also confirm that #33 also fixed the issue for me on php 7.2
Comment #50
javi-er CreditAttribution: javi-er at Taoti Creative commentedNot 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
Comment #51
Amir Simantov CreditAttribution: Amir Simantov commented#33 also works for me.
Should go to release.
Comment #52
jrearickPatch #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
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.
Comment #53
james.williams CreditAttribution: james.williams at ComputerMinds commentedThanks @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 (containingNULL
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.
Comment #54
PanchoI 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:
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']
.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:
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.
Comment #55
suparnaa.dey CreditAttribution: suparnaa.dey as a volunteer commentedhttps://www.drupal.org/project/date/issues/2889759#comment-12162087 and https://www.drupal.org/project/drupal/issues/2313517#comment-9781123 both need to use to fix the issue.
Comment #57
jerrac CreditAttribution: jerrac commentedJudging 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...
Comment #58
nelsongrin CreditAttribution: nelsongrin at European Commission and European Union Institutions, Agencies and Bodies for European Commission and European Union Institutions, Agencies and Bodies commentedThe patch #33 worked for me.
Comment #60
AaronBaumanPatch #33 works for me as well.
Needs a test to demonstrate the bug and prove solved.
Comment #62
sharonho CreditAttribution: sharonho as a volunteer commentedRerolled patch #33 to Drupal 7.81
Comment #65
alansaviolobo CreditAttribution: alansaviolobo as a volunteer commented+1 for patch #62
Comment #67
tondeuse CreditAttribution: tondeuse as a volunteer commented#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';
Comment #68
apaderno