I get a PHP error "unsupported operand" when entering the store configuration menu:
Fatal error: Unsupported operand types in /home/content/r/d/k/rdksoft/html/perfumes/modules/system/system.module on line 627

I only get this error when I try to configure the live version of the store and not in the XAMPP I use for development. While there is a mistake in the Drupal core, it is only triggered when Ubercart store is enabled.

The core (system.module) is failing when the MLID is not set. It seems the core is trying to look-up a menu item by name and adding the MLID an element to the $item array:

if (!isset($item['mlid'])) {
    $item += db_fetch_array(db_query("SELECT mlid, menu_name FROM {menu_links} ml WHERE ml.router_path = '%s' AND module = 'system'", $item['path']));
}

Unfortunately, you can't "add" two arrays like this. Why this isn't the case on XAMPP is still a puzzle since the installations appear identical (same modules, core, PHP version, MySQL version) code is errant in XAMPP also.

I just got a couple of ideas to chase down, but maybe the solution is more obvious to others than it is to me.

Comments

dkeays’s picture

dkeays commented
Project: Ubercart » Drupal core
Version: 6.x-2.1 » 6.14
Component: Code » system.module
Category: support » bug

I found a simple work around: use PHP's arraymerge() instead of "+=".

This bug manifested itself on a fresh 6.14 install and an upgrade to 6.15.

Other people have reported it in various modules, I am changing my posting from an Ubercart issue to a System module bug report.

I assume this has to do with the fact that PHP5 handles arrays differently.

dkeays’s picture

dkeays commented
Title: ubercart and "unsupported operand" in store configuration menu » "unsupported operand" in system.module line 627 (seen in administrative menus)
damien tournoud’s picture

damien tournoud commented

Duplicate of #647064: Fatal error: Unsupported operand types when menu_links query returns no results in system_admin_menu_block(). This is not a core bug.

damien tournoud’s picture

damien tournoud commented
Status: Active » Closed (duplicate)
dkeays’s picture

dkeays commented

Yes, not setting mlid correctly is an error that contributing modules need to watch out for, but I think that this code may also require the attention of the maintainer of the core module.

The statement in question is feeding a PHP operation data that, by definition, it can't handle. If that is not a "bug", then what is it?

I hate to disagree with someone who has contributed so much to the community, but forcing a fatal error on users with no PHP knowledge is not the Drupal way as I understand it. Especially since that kind of error may result in an information leakage.

dkeays’s picture

dkeays commented

Comments on your posts in #647064

You say:
"If the mlid cannot be determined, this function *has to fail* one way or the other (the mlid is used just a few lines below). Failing with a fatal error is not such a bad way to fail."

The code in question is trying to handle this situation but it has an error (aka a bug) in it. Why not call it what it is?

Failing with a fatal error is a bad way to fail when there are other options. I detailed my reasoning in the previous comment.

Looking back, I didn't use the ArrayMerge() as I stated. The changes I made allows the code to work as apparently intended. The mlid will then be ready to be used "a few lines below".

before:

if (!isset($item['mlid'])) {
    $item += db_fetch_array(db_query("SELECT mlid, menu_name FROM {menu_links} ml WHERE ml.router_path = '%s' AND module = 'system'", $item['path']));
}

after:

if (!isset($item['mlid'])) {
    $item['mlid'] = db_fetch_array(db_query("SELECT mlid, menu_name FROM {menu_links} ml WHERE ml.router_path = '%s' AND module = 'system'", $item['path']));
}