I have a Drupal 6.4 installation that is configured for multisite. I've incorporated a few Drupal sites into it as well as rolling in a few WordPress sites. This multisite install currently has about a dozen domains running off of it.

So I decided to migrate my primary Drupal install into this - this is my site that I've maintained since 1997 and has gone through one CMS to another before settling on Drupal years ago. It also has the most tricks and modules installed into it. I've upgraded it to 5.10 without any issues.

I have been copying the database ("drupal_q to drupal_qdp") and using the new database to perform the upgrade on as a test site. I'm glad I did that. Each time I try to upgrade this site, I get the following error:

Fatal error: Unsupported operand types in /httpdocs/drupal-6.4/includes/common.inc on line 1445

I've done everything I can think of to ease the upgrade - killing all modules, setting the site to Maintenance (even though it's inaccessible from the Internet at the moment), uninstalling modules that I can reinstall without data loss, setting the theme to BlueMarine - nothing works. I goes through the entire upgrade process with few to no errors (a few rogue modules, such as smileys, is full of typos and performs its upgrade whether or not it's enabled), but once I try to load the site: Unsupported operand. This occurs in the l() function right at the top:

function l($text, $path, $options = array()) {
  // Merge in defaults.
  $options += array(
      'attributes' => array(),
      'html' => FALSE,
    );

The kicker for me is that when I tried to hack out the code there to force it past, the scripts would bomb again at another $variable += array( ..... command. Research on this error has a lot of people pointing to modules that I don't have installed, and I'm running PHP 4.3.9 which should be fully handled.

So - can anyone help me with this?

Comments

BakerQ’s picture

Just an FYI for anyone who's encountered this issue, the culprit here was that the upgrade from D5 to D6 removed the function "db_num_rows", and I had a few blocks of custom PHP code that would call that function.

This didn't fix the original issue, which is from common.inc. The header for the l() function (quoted above) specifies that it receives a parameter named $options which defaults to an empty array. However, that doesn't appear to be assigned in the actual function. I added the line:
if (!$options) { $options = array(); }
above the conditional, and everything is smooth sailing.

So, new question: why doesn't it get initialized in the functions parameter definition?

BloodyNO’s picture

I encountered the same problem and the fix BakerQ proposed worked. I'd like to add that it doesn't seem to be PHP-version dependent: My webhost is running PHP Version 5.2.0-8+etch11.

Craig-Edmonds’s picture

Hi Guys,

I am just wondering on which line in common.inc to place the fix.

I am not sure exactly.

elianm’s picture

Had the same issue with the same PHP version here 5.2.0-8+etch11.
Special thanks to BakerQ for fixing it.

fumbling’s picture

For a php newbie, could you let me know where exactly in the code to insert your fix?

I tried inserting where I thought "above the conditional" would be, knowing very little about php, but I got an error, so must be missing the boat.

fumbling’s picture

Ah, nevermind my other reply, I got it working by adding it directly to the line following the comment " // Merge in defaults." Thanks again, this is a life saver fix.

Anonymous’s picture

I encountered the same problem with Drupal 6.9 and Node Comments 6.x-1.2-rc2. Thank you for your working solution.

Your solution is possible without patching core-code is a change in node-comment.tpl.php

Line 6 states:

print l($node->title, $_GET['q'], NULL, NULL, "comment-$node->nid") . ' ' . theme('mark', $node->new);

Change it in:

$helperparray = array(); print l($node->title, $_GET['q'], $helperparray, NULL, "notitie-$node->nid") . ' ' . theme('mark', $node->new);
ariedels’s picture

Sorry for being daft, but I have cut and paste the line (without the
bits) and it still does not to have solved the problem. Could someone who patched possibly post what that section of common.inc looks like now?