Unsupported Operand Type
| Project: | Drupal |
| Version: | 6.6 |
| Component: | base system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
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.
#1
Hm, what's your PHP version?
#2
It 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.
#3
PHP 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.
#4
Gábor is $options supposed to be set to the result of the union of the two arrays? I think it should be:
<?php$options[] = array(
'attributes' => array(),
'html' => FALSE,
);
?>
#5
Earnie: 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.
#6
Checked. All modules are said to be 6.0beta1. Checked for updates, none available.
#7
Hm, this means you are using Drupal 6 beta 1 without any additonally downloaded or custom developed modules?
#8
Correct. Stock 6.0beta1 without any additions in modules or even themes.
#9
Can't reproduce. Using RC 2, PHP 5.2.4
#10
Zotnix: is this still an issue? We cannot reproduce.
#11
I'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.
#12
On what page? With what module? Any special settings? Menu items?
#13
The 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.
#14
Rob, 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.
#15
So 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.<?phpif (!is_array($options)) {
throw new Exception(t('The $option parameter is not an array: <pre>@option</pre>', array('@option' => print_r($option, TRUE))));
}
?>
#16
I 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.
#17
The backport needs to wait for the D7 fix first.
#18
Subscribe. 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.
#19
How 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:
#20
Are there other places we could stick Type Hinting into Drupal 7?
#21
Yet - a lot of places! Almost any function that takes an array or object as argument could use type hinting.
#22
Committed to CVS HEAD. Thanks!
#23
question: 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
#24
Nope, 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.
#25
do 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..
#26
I 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.
#27
#318016: Add type hinting parameters
#28
Automatically closed -- issue fixed for two weeks with no activity.
#29
I applied the fixes to Drupal 6.6 + bunch of modules installed.
It worked like a charm :)