Fatal error: Unsupported operand types in /www/dsca/docroot/sites/all/modules/contrib/rules/rules/rules.module on line 348

Getting the same error which persists when I make the changes suggested in OP. However eliminating line 346 entirely fixes the issue. so:

foreach (element_children($element) as $key) {
    $element[$key] += array('#weight' => 0);
    $element[$key]['#weight'] += $count / 1000;
    $count++;
  }

becomes

foreach (element_children($element) as $key) {
    $element[$key]['#weight'] += $count / 1000;
    $count++;
  }

Not sure what that line is needed for anyway, as this $element[$key]['#weight'] += $count / 1000; will add #weight to the $element array if it doesn't already exist and will update it if it does.

Patch for #5 attached.

The test-bot is currently broken.

-    $element[$key] += array('#weight' => 0);

We need that line to initialize #weight if it's not set yet. If this is the source of the error message, most likely $element[$key] is not an array for you?

Type casting seems to be the right way to go about this.

I'm seeing this error when the value of my $element[$key]['#weight'] is a string. Perhaps I achieved these string weights by importing/exporting rules through features, or maybe my rules were created with a legacy version of Rules, who knows...

Point is that the suggestion of the OP resolves a fatal error that appeared without warning on a production site of mine without me changing any relevant code other than pushing/reverting Features.

Type casting the weight from a string to an integer should not cause any problems.

I am using Rules 6.x-1.4

#6: Unsupported-operand-types-1164220-5.patch queued for re-testing.

patch #1 re-rolled against 6.x-1.4 attached

trying to get test bot to work..

yay, test passed! that kind of took too many patches to get such a simple thing right >.<

ahem

Update on this which might help others resolve their errors:

I was having problems getting my rules included in Features to revert at all. I uninstalled rules, manually deleted all rules hooks from my Features then installed the latest dev version of Rules and exported all of my Rules from my production site manually through the UI then re-created the Features.

This caused the fatal errors to go away. Not sure exactly what to make of that, I was previously using Rules 1.4 but it is possible that when the site was first set up an older version of Rules was used and had since been upgraded to latest stable.

This issue persists in 6.x-1.x. Patch from #21 re-rolled for dev branch.

Update: our fatal errors came back in a later release when we re-exported Rules into Features. May have had something to do with git merging and the way that rules seems to "interleave" it's data in arrays rather than having one key-value pair per rule - this makes it very hard for humans to see what's actually getting committed each time Rules are re-exported. Entirely possible that the "bad" data that Rules is using in Features is partly due to us doing something silly in a commit or merge, but we'll probably never know.

Unfortunately we've spent more time debugging this issue than it took to pull Rules out of our system and re-implement everything the "old fashioned" way with simple hooks and API calls.

Drupal 6 is no longer supported, and the code in question is different in Drupal 7.