Description: ------------ Mail::send() supports an Array as recipient to be able to send CC and BCC emails (see http://pear.php.net/manual/en/package.mail.mail.send.php). I have modified Mail_Queue to support this. See 'Test Script' below for the appropriate patches. Hereafter you can use an array like array('To'=>'user@address.com', 'Cc'=>'user2@domain.com,user3@domain.uk') as the $to parameter of Queue::put() NB: the field "recipient" in the database needs to be changed to type "text" instead of "varchar": ALTER TABLE `mail_queue` CHANGE `recipient` `recipient` TEXT NOT NULL; Test script: --------------- diff of Mail/Queue.php: 409a410,411 > if (is_array($to)) > $to = serialize($to); --------------------------------------------------------- diff of Mail/Queue/Body.php: 92c92 < * @var string --- > * @var mixed 134c134 < * @param string $recipient Reciepient e-mail --- > * @param mixed $recipient Reciepient e-mail 146a147,149 > $rcpt_array = @unserialize($recipient); > if ($rcpt_array!==FALSE) > $recipient=$rcpt_array; 260c263,266 < return stripslashes($this->recipient); --- > if (!is_array($this->recipient)) > return stripslashes($this->recipient); > else > return $this->recipient;

This is a known limit of Mail_Queue [1], and I already have a patch in my local repository, but I can't apply it because it breaks BC. Altering the table and serializing the recipients is not acceptable if the table isn't empty, you'd have inconsistent data in the db (some serialized values, some not serialized). BC-breaking changes aren't allowed in stable packages. [1] http://pear.php.net/bugs/5707

Well, that would mean no package can ever update if it involves a database patch like this. IMO this is just as valid as a source patch. But I see your point. However, in the case of Mail_Queue it's a db table that functions as stack ... meaning it is supposed to and will be empty on a regular basis. So the breaking of existing data is almost a non-existant issue. Third I believe this is a critical bug for Mail_Queue. Any serious use of this package will want to have the functionality. That is why this should be implemented asap and that is also why I put this patch online for the general public. This is Open Source - people need this fixed and this way they can fix it if they want. Concluding; I really like this package and it's potential... but it's quite unuseable without cc/bcc. So even if it involves going a major version higher or something to be 'allowed' to release this BC breaking patch... I would urge you to do so :) Thanks for all your work!

> Well, that would mean no package can ever update if it involves a > database patch like this. IMO this is just as valid as a source patch. > But I see your point. the problem is not the db field type change, it's the format of the data that's stored in it: before: not serialized; after: serialized. You can't mix the two. > However, in the case of Mail_Queue it's a db table that functions as > stack ... meaning it is supposed to and will be empty on a regular > basis. So the breaking of existing data is almost a non-existant > issue. not if you upgrade while your table is still not empty. Since the send_mails_in_queue script is supposed to run as a cron task, you may forget about checking the real table. > Third I believe this is a critical bug for Mail_Queue. Any serious use > of this package will want to have the functionality. That is why this > should be implemented asap and that is also why I put this patch online > for the general public. This is Open Source - people need this fixed and > this way they can fix it if they want. > Concluding; I really like this package and it's potential... but it's > quite unuseable without cc/bcc. So even if it involves going a major > version higher or something to be 'allowed' to release this BC breaking > patch... I would urge you to do so :) The open source argument is not really appropriate here. I'm not questioning the usefulness of the Bcc support, in fact I had written a patch well before you posted yours, but there are some PEAR QA rules I can't ignore. One of them is that BC breaks are not allowed in stable packages. This is neither a critical bug, since you can store one mail per recipient, as it was designed to do, instead of one mail for many recipients. About a new major version, while I see the shortcomings of the current one (and I've already written a lot of patches for it, but I can't apply those fixes for the same BC reason), I don't have the time resources to rewrite the package and maintain both, right now. So far I've tried to keep the current package in shape and I believe it's still very useful as-is, even if it's not optimal. Radek hasn't worked on the package since Feb 2003, so I guess he's not active animore. Anyway, I'll submit this issue to the PEAR QA team, if I have their approval, I will commit a fix.

can you try the latest CVS version?

I've tested the CVS version with MySQL backend. Used the mysql.sql from CVS (v1.2) Tested both ways like: $to = array ( 'To'=>'user1@server1.com,user2@server2.com', 'Cc'=>'user3@server3.com' ); and $to = 'oneuser@server.com'; The recipient gets saved to the database OK (serialized) and sending the mail functions properly. I may conclude the CVS version properly implements the multiple recipients functionality. Great job! I only have one remark; it's kind of odd to see the mail delivered at the recipient without 'To' or 'Cc' fields visible to the client. Apparently these have to get set explicitly in the headers by the coder before mailqueue->put(). Not a bad thing IMO, experienced programmers will have no trouble. But with the multiple recipients it's easy to forget to put for example the Cc recipient into the headers. Therefor it would be nice if Mail_Queue also had some friendlier wrapper function(s) to relieve the coder from the Mail::Mime stuff to get headers and body. For example: function put ($from, $to, $subject, $body, $bodytype='text') {} or something similar. Mail_Queue itself would then use the Mail::Mime functions to produce the proper headers and body like in the tutorial. Just a thought :) Thanx.

I'm glad the code in CVS works as expected. About the new request, it won't be implemented in Mail_Queue v.1.x. We're working at a new v.2.x release that should fix most of the current issues. Please submit a feature request when a beta version of the new package is released, if it doesn't do what you need.