OS: Ubuntu Server
Webserver: lighttpd-1.4.13 (ssl) - a light and fast webserver
Not sure of the proper component that is erroring.
When clicking to read a comment I received the error:
Error: Unsupported Operand types on line 1365 in common.inc
I looked it up, the file is ROOT/includes
The offending code:
function l($text, $path, $options = array()) {
// Merge in defaults
$options += array(
'attributes' => array(),
'html' => FALSE,
);
It seems to not like "+=" of these arrays. So I looked up some PHP array functions and tried this:
$options = array_merge($options, array('attributes' => array(), 'html' => FALSE,));
It works. I'm not *entirely* sure if this is a proper fix. But it stops the error. I can give any extra information if needed.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | 180137-1.patch | 1.76 KB | c960657 |
| #13 | arraymerge.patch | 1.21 KB | robloach |
Comments
Comment #1
gábor hojtsyHm, what's your PHP version?
Comment #2
gábor hojtsyIt could also be that some module you use or write use l() improperly. l() was changed a lot since Drupal 5, so if you are not using a properly updated module, that could easily cause such problems.
Comment #3
Zotnix commentedPHP 5.2.1 (cgi-fcgi)
I'll also check as far as function calls but when I changed the code as per above the error went away completely and it effectively does the same thing.
Comment #4
Anonymous (not verified) commentedGábor is $options supposed to be set to the result of the union of the two arrays? I think it should be:
Comment #5
gábor hojtsyEarnie: yes. That's why we use += which does just that if both operands are arrays. As I pointed out, it is possible that Zotnix is using a module which has outdated l() usage.
Comment #6
Zotnix commentedChecked. All modules are said to be 6.0beta1. Checked for updates, none available.
Comment #7
gábor hojtsyHm, this means you are using Drupal 6 beta 1 without any additonally downloaded or custom developed modules?
Comment #8
Zotnix commentedCorrect. Stock 6.0beta1 without any additions in modules or even themes.
Comment #9
blakehall commentedCan't reproduce. Using RC 2, PHP 5.2.4
Comment #10
gábor hojtsyZotnix: is this still an issue? We cannot reproduce.
Comment #11
ckdake commentedI'm seeing this with Drupal 6.0 release on PHP 5.2.5-pl1-gentoo (cli) (built: Jan 10 2008 23:39:07) with:
$options += array(
'fragment' => '',
'query' => '',
'absolute' => FALSE,
'alias' => FALSE,
'prefix' => ''
);
in includes/common.inc
when attempting to create content.
Comment #12
gábor hojtsyOn what page? With what module? Any special settings? Menu items?
Comment #13
robloachThe problem is attempting to merge the options array with "+=". The problem is that the options array is sometimes not an options array (like a string maybe?), and you run into an operator/type conflict. This happens in both url and l. See Array Operators for more information.
This patch attempts to fix that by forcing a is_array check on the options before merging the arrays.
Comment #14
gábor hojtsyRob, options should be an array by definition, so if it is not an array, it is not allowed but is a sign of buggy code.
Comment #15
Anonymous (not verified) commentedSo rather than obliterating the parameter received into nothingness if it is not an array, how about throwing an Exception? Since D7 is PHP5 only we should be able to use such techniques, correct? This will give
asus a trace back for where the invalid use of the function resides.Comment #16
nelsonlee commentedI found the same problem "Fatal error: unsupported operand type += ...... in common.inc". It is due to the first parameter of $options is not an array.
I am using Drupal 6.4 with PHP 5. I used the above attachment (#13) to modify the source code of common.inc and it works.
Comment #17
Anonymous (not verified) commentedThe backport needs to wait for the D7 fix first.
Comment #18
axyjo commentedSubscribe. Same issue Ubuntu 8.04 PHP 5.2.4 AND Windows Vista PHP 5.2.5.
EDIT: Not Drupal's fault. I tried to combine a string and an array by accident.
Comment #19
c960657 commentedHow about using type hinting in the function definition like in this patch? This will make PHP automatically check that an array is passed, and in case of an error the filename and line number of the caller is displayed - like this:
Comment #20
robloachAre there other places we could stick Type Hinting into Drupal 7?
Comment #21
c960657 commentedYet - a lot of places! Almost any function that takes an array or object as argument could use type hinting.
Comment #22
dries commentedCommitted to CVS HEAD. Thanks!
Comment #23
pasquallequestion: why was this patch committed?
1. As I see there was nothing wrong with the original code.
2. Drupal does not try to fix what is broken.
3. type hinting? since when? and why only here? there are gazillion places ("Almost any function") where this could used in Drupal, but we do not use it..
this patch degrades the quality of Drupal codebase
Comment #24
robloachNope, nothing wrong with the original code at all. This just makes the code more strict and will force an exception error if used incorrectly.
Nope, but this does enforce the correct use of it.
Type hinting since Drupal 7 requires PHP 5. I agree that there are a gazillion places where we could use this and I'd like to see more PHP5isms in Drupal 7. I disagree, however, that it degrades the quality of the Drupal codebase as it just makes the code a bit more strict.
Comment #25
pasqualledo we want to add type hinting to all functions? otherwise this patch is just a quick & dirty fix which is not coherent with the rest of Drupal code..
Comment #26
Anonymous (not verified) commentedI think it makes sense to move to type hinting all params as can be done but not in one huge patch. So, this one remains fixed.
Comment #27
pasqualle#318016: Type hint array parameters
Comment #28
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #29
Elan Hasson commentedI applied the fixes to Drupal 6.6 + bunch of modules installed.
It worked like a charm :)