I've just noticed that I get this error:
Fatal error: Cannot create references to/from string offsets nor overloaded objects in ..../includes/form.inc on line 312
on my user edit page (user/1/edit for example).
PHP version is 4.3.10. The version of form.inc in question is 1.72. The line is:
$form['#ref'] = &$ref;
in form_builder().
I tried replacing that line with:
$tmp = &$ref;
$form['#ref'] = &$tmp;
and the error was on the second of those two lines, if that's interesting at all.
Comments
Comment #1
chx commentedWhat modules you have on (which add or try to add info) to the edit page? I suspect non-4.7 modules.
Comment #2
Wesley Tanaka commentedHere's a repro case:
Create a menu callback with this as the callback function's code:
and then go visit that menu callback.
Comment #3
Wesley Tanaka commentedIn response to #1, I believe tinymce, profile, locale, privatemsg, and comment. I'm looking into where my "0" indexed item is coming from at the moment.
Comment #4
chx commentedSo, now we are supposed to babysit coders so that even bad code falls gracefully? NO WAY.
Comment #5
Wesley Tanaka commentedComment #6
Wesley Tanaka commentedIt looks like the recent change from array_merge to array_merge_recursive might be involved here.
Comment #7
Wesley Tanaka commentednope, red herring.
Comment #8
guckie commentedOh, please please... Is there a specific *typical* example of this "bad code" you refer to? And if so, could you please suggest how to correct said example of bad code?
The reason I ask is because I'm trying to port a couple of non-4.7 modules, and after I update to correct formAPI syntax, I'm left with this same error message. I'm worse off than a beginning coder... but if there's one or two specific examples that cause the failure, please suggest what they are and how to fix them. (I'm a pro at 'cut & paste'!) Am willing to do what I can with a little direction.
Comment #9
chx commentedOne of the most typical errors are leaving out of # from an attribute name. If you do that, then it becomes a children instead of a property and a children is supposed to be an array but it's a string... for example $form['foo'] = array('#type' => 'textfield', 'default_value' => 'wrong form element'); here you have defined $form['foo']['default_value'] = 'wrong form element'; which does not work and most likely you will end up with tthat error.
Comment #10
Wesley Tanaka commentedKároly, the idea of "babysitting bad code" is common in software development tools. Imagine if PHP got rid of all of its descriptive error messages and instead reported "something went wrong" for all of its errors. I bet you'd have a smaller and faster php binary, but it would certainly be useless in the eyes of most people that tried to use it.
The idea of an error message being descriptive enough to quickly pinpoint the underlying problem isn't, in my opinion, babysitting -- it's the mark of a mature and well-built system.
Another way to look at this is that a fatal error in PHP (or an uncaught runtime exception in som interpreted languages) is analagous to a compiled program crashing. It's not usually considered acceptable for a program to crash as part of its user interface. I think this situation is analogous.
Comment #11
killes@www.drop.org commentedDrupal isn't a code development tool, but a more usefull error message would have saved me some headaches, too.
Comment #12
Wesley Tanaka commentedPerhaps my view is in a minority (minority of 1?), but I see drupal as a library of useful functions for building a community-oriented website. And I see software libraries as development tools.