Unsupported operand types

I'm getting the same problem -- emails aren't going through. . . any help? I'm downgrading for now until this issue is fixed.

Unfortunately not a typo, the += allows the new array to set any previously unset values to the necessary defaults. Most probably something unusable is being passed into the $info array, probably a NULL default. This array depends largely on the send method and message type being used. Do you only get this with certain send methods and not others? If it is systemically wrong it will take some work to track down and any details you can provide on what causes this would be very helpful. Try printing out the arguments to _messaging_info when it is called, maybe starting on line 686 with:

<?PHP
print_r(array('info'=>$info,'method'=>$method,'property'=>$property,'default'=>$default));
?>

Anyone else having this issue? Is it still occurring in latest revisions? Is it only with messages caused by notifications, and what type of notifications? I am unable to reproduce it so far, but obviously extensively testing all contingencies for this module is not that doable. Please describe as precisely as possible the situation precipitating this issue.

Also, try just adding add a check

<?PHP
if(!$info) {
 $info = array();
}
?>

and see if all your messages get sent out properly without the info array properly set.

Thanks,
David

I just had the same problem. I don't exactly know the reason, but it seems it has now vanished. So I just want to share what I did:

1. First I inserted the check proposed by David:

<?PHP
if(!$info) {
$info = array();
}
?>

That really fixed it for the time being. Emails came through.

2. After that I realized there was some misconfiguration in my website. Some users had phpmailer as sending method, some had E-Mail. But I had deactivated the phpmailer Module. So these subscriptions were made before this deactivation. So now I changed all subscriptions to sending method: E-Mail. After that I changed the messaging.module file to its earlier state (without David's check) and it still worked.

I don't know if this will help anybody but I would be happy if it did.
Thanks for this thread, which made me start tackling this problem in the first place.
~<><~~~~~~~ presencia

The check fixed my problem as well.

I ran this query SELECT DISTINCT send_method FROM notifications and found that there are a number of subscriptions in the database using older depreciated sending methods. I ran a query to change all those subscription's sending_method to the default.

Perhaps when disabling sending_methods, all subscriptions created using that method should be changed to the default?

It might be more to the point just to set a default value for $info so line 700 reads:

function messaging_message_render($message, $info = array()) {

[Update: Sorry, never mind that -- I see that something is getting passed in there, it's just not an array. So you do have to check it like you specified above.]

Im getting this error after upgrading to drupal 6. People used to get messages via mime mail but now use phpmailer.

do I just add that code in the module somewhere?

well uninstalling and reinstalling notifications and messaging fixes it of course. Kinda lame that I lost all those subscriptions but better than the alternative.

you did not make a patch?

subscribe.. Happening to me, too.

Started happening after I removed private messaging.

Why is this closed? The issue still occurs in some cases.

How about the simple attached patch? It ensures that $info is an array.

+1. I just had this issue, and I haven't changed anything.

Please fix!

I also had the issue after an upgrade from Drupal 5 as well as a failure to send notifications.

I forced all outmoded send methods to a working default 'mail' (PHPMailer) which sent those notifications set to immediate, but the cron issue persisted.

The cast in the patch has things running zen-like again.

i encountered this error when upgrading from D6 to Pressflow. fixed it by modifying the messaging.module line 711.
would like to see this get checked-in to the source, or any opinions. thanks.

from:
$info += array('glue' => '', 'subject_glue' => '', 'filter' => NULL);

to:
$info = array_merge($info, array('glue' => '', 'subject_glue' => '', 'filter' => NULL));

keen to hear if there is an agreed resolution for this - in my case the problem looks like it was fact that some subscriptions were set to a non-existent send method (namely debug which I hadn't re-enabled) so I just went to ../messaging/subscriptions/admin and set all those subs to an existing send method - and sweet - fixed.

#19 worked for me.

When I tried this modification (in #19) and post something I get this error:

warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/username/public_html/sites/all/modules/messaging/messaging.module on line 711

So, not a universal fix obviously.

subscribe

had the same issue as #20 (debug was being used as a send method but i didn't re-enable it). this appeared to work but then the error showed up again.

solution in #19 seems to have fixed things. i'll report back if i'm still having issues.

thanks for all the help! :)

#16 resolved issue for me

Same issue as described before. #19 solved (so far) for me.

Thanks!

This issue popped resurfaced on a test site I had running and unlike #18 where I applied the patch, I found setting values in the notifications_queue to see my cron and queue processing run patchlessly.

(I hadn't retrained ALL illegally specified send_methods in my enthusiasm to apply the patch)

Still having this problem. Causing WSOD.

Was using Messaging in conjunction with Notifications, but disabled them for a while. I encountered the above error message after enabling the modules. After further testing, it turns out I had not yet enabled the messaging module that was required here. Once enabled, I was off to the races.

Moral of the story: Make sure the appropriate messaging module is enabled.

Thanks... #30 solved my problem.. I enabled "Simple Mail" module from Messaging Modules.

Hi,

I've solved the problem by adding typecasting operator to #19's code.

The code works for PHP 4.x and 5.x versions:

from:
$info += array('glue' => '', 'subject_glue' => '', 'filter' => NULL);

to:
$info = array_merge((array)$info, array('glue' => '', 'subject_glue' => '', 'filter' => NULL));

The cause of this error seems to be when you've enabled a messaging module type, allowed users to set it as their default message type, and then you disable the module. At that point the following hook call no longer returns the messaging module type:

module_invoke_all('messaging', 'send methods');

This ultimately causes the following to set $info to NULL:

    $info = messaging_method_info($method);

Then in messaging_message_render() the following becomes invalid because you can't += NULL:

  $info += array('glue' => '', 'subject_glue' => '', 'filter' => NULL);

Changing the call to messaging_method_info() to set the default $info to array() solves this problem:

    $info = messaging_method_info($method, NULL, array());

A patch is attached.

Guys, in my case, this had nothing to do with the messaging module it self.

I started with the phpmailer module for sending the notifications trough messaging with phpmailer. Because of my host i had to quit with phpmailer. So i uninstalled the module, from then on i got the error. What i did was go to phpmyadmin and delete all the data that has set the send_method for phpmailer.

Bug fixed.

Yeah, I think perhaps we should instead make disabling a send method reset all notifications that use it to the new default, with the appropriate warnings given on the admin interfaces. Anyone up for that?

David

totally agreed

Added some checks so missing sending methods wont cause errors, just a watchdog messge.

I just recreated and fixed this.

My config was as follows:
Pre-upgrade i had messaging debug module enabled but did not enable it post upgrade.
Even though there was no setting to send a debug message when mailing, this was causing the error. Enabling it again solved the error message problem.
----
wireless router reviews

I am experiencing this problem. Very Frustrating! The posts suggest that the problem seems to stem from a variety of configuration problems and I appreciate that it may be hard to trace. However, it seems to me that the module should detect the problem and log an error somewhere rather than breaking the CRON process. This is a bug of its own. Code that runs in cron need to do better exception handling.

Why does this issue keep getting closed with no resolution?

Turned out that my problem was a disabled module, as suggested in a couple of the posts above. But it took me hours to figure it out. So I hope you will forgive my grumpiness. Please consider introducing code that would catch this condition (attempting to use a disabled module to send mail) and log the problem.

I'm not sure if this is fixed in the latest development version, but I ran into this tonight. The problem seemed to be that "messaging" was enabled to go along with Organic Groups, but no message sending methods were enabled. This resulted in several items being added to the queue with "no" sending method defined, which seemed to be triggering these errors.

I also had a problem with disabling the Messaging Debug module however had some users with "Debug" still used as the send method.

Fix:
on /admin/messaging/subscriptions/admin: Changed the user's send method who had "debug" set
FROM phpMyAdmin ran the sql query: DELETE FROM `notifications_queue` where send_method='debug'

I imagine this would also happen with another "send_method" that was previously used but not cleared from the database tables.

Hmm, this doesn't seem fixed to me. At admin/messaging/subscriptions on a site I'm working on I see thousands of subscriptions that are still using mimemail even though MIME Mail has been disabled and uninstalled.

I'm getting this error too. This bug doesn't want to die!

I have hundreds of lines of just this:

[18-Jun-2010 11:30:01] PHP Fatal error: Unsupported operand types in /var/www/drupal/sites/all/modules/messaging/messaging.module on line 71

We fixed this by running UPDATE notifications SET send_method='mail' WHERE send_method='mimemail' on our database. It would be good to be able to run this query on a new admin/messaging/subscriptions/tools page.

This seems to happen when trying to send messages for disabled methods. This should be fixed in latest version (-dev), messages are not attempted to be sent anymore and a log is produced.

I hadthe same problem with this version. The cron problem was solved by issuing the update command.

Okay, we've got a workaround, but a patch is still needed to prevent the issue.