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.

CommentFileSizeAuthor
#19 180137-1.patch1.76 KBc960657
#13 arraymerge.patch1.21 KBrobloach

Comments

gábor hojtsy’s picture

Hm, what's your PHP version?

gábor hojtsy’s picture

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.

Zotnix’s picture

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.

Anonymous’s picture

Gábor is $options supposed to be set to the result of the union of the two arrays? I think it should be:

$options[] = array(
'attributes' => array(),
'html' => FALSE,
);
gábor hojtsy’s picture

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.

Zotnix’s picture

Checked. All modules are said to be 6.0beta1. Checked for updates, none available.

gábor hojtsy’s picture

Hm, this means you are using Drupal 6 beta 1 without any additonally downloaded or custom developed modules?

Zotnix’s picture

Correct. Stock 6.0beta1 without any additions in modules or even themes.

blakehall’s picture

Can't reproduce. Using RC 2, PHP 5.2.4

gábor hojtsy’s picture

Status: Active » Postponed (maintainer needs more info)

Zotnix: is this still an issue? We cannot reproduce.

ckdake’s picture

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.

gábor hojtsy’s picture

On what page? With what module? Any special settings? Menu items?

robloach’s picture

Version: 6.0-beta1 » 7.x-dev
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new1.21 KB

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.

gábor hojtsy’s picture

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.

Anonymous’s picture

Status: Needs review » Needs work

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 as us a trace back for where the invalid use of the function resides.

if (!is_array($options)) {
  throw new Exception(t('The $option parameter is not an array: <pre>@option</pre>', array('@option' => print_r($option, TRUE))));
}
nelsonlee’s picture

Version: 7.x-dev » 6.4
Status: Needs work » Patch (to be ported)

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.

Anonymous’s picture

Version: 6.4 » 7.x-dev
Status: Patch (to be ported) » Needs work

The backport needs to wait for the D7 fix first.

axyjo’s picture

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.

c960657’s picture

StatusFileSize
new1.76 KB

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:

recoverable fatal error: Argument 3 passed to l() must be an array, string given, called in /home/c960657/www/drupal/sites/all/modules/foo/foo.module on line 45 and defined in /home/c960657/www/drupal/includes/common.inc on line 1494.

robloach’s picture

Status: Needs work » Reviewed & tested by the community

Are there other places we could stick Type Hinting into Drupal 7?

c960657’s picture

Yet - a lot of places! Almost any function that takes an array or object as argument could use type hinting.

dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks!

pasqualle’s picture

Status: Fixed » Postponed (maintainer needs more info)

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

robloach’s picture

As I see there was nothing wrong with the original code.

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.

Drupal does not try to fix what is broken.

Nope, but this does enforce the correct use of it.

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

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.

pasqualle’s picture

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..

Anonymous’s picture

Status: Postponed (maintainer needs more info) » Fixed

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.

pasqualle’s picture

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

Elan Hasson’s picture

Version: 7.x-dev » 6.6

I applied the fixes to Drupal 6.6 + bunch of modules installed.

It worked like a charm :)