Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.10.11

Request #2952 Mail_mime::headers() saves extra headers
Submitted: 2004-12-12 14:14 UTC
From: alpha at rrs dot at Assigned: cipri
Status: Closed Package: Mail_Mime
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: 1.4.0, 1.4.0a1    
Comments Add Comment Add patch

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 22 - 17 = ?

 [2004-12-12 14:14 UTC] alpha at rrs dot at
Description: ------------ After calling Mail_mime::headers() the first time with some extra headers they cannot be overwritten with a second call. I'd need this to send mails to different recipients with their email address (and maybe their name) in To. Mail_smtp doesn't put the recipients in a To header itself. IMHO $xtra_headers should not be put into which would solve my problem. Reproduce code: --------------- <?php // include ... $mime = new Mail_mime(); $mime->setTXTBody(/* get some text */); $headers = array('To' => '', 'From' => '', 'Subject' => 'foo and bar'); $body = $mime->get(); $headers = $mime->headers($headers); // Mail::factory() ....->send('', $headers, $body) $headers = array('To' => '', 'From' => '', 'Subject' => 'foo and bar'); $body = $mime->get(); $headers = $mime->headers($headers); // Mail::factory() ....->send('', $headers, $body) ?> Expected result: ---------------- // First mail To: From: Subject: foo and bar the text . // Second mail To: From: Subject: foo and bar the text . Actual result: -------------- // First mail To: From: Subject: foo and bar the text . // Second mail To: From: Subject: foo and bar the text .


 [2004-12-15 19:32 UTC] sean
Thank you for taking the time to write to us, but this is not a bug. This is normal. Headers currently in the Mime object override new headers. To change this behaviour would break Backwards Compatibility. S
 [2004-12-15 22:19 UTC] alpha at rrs dot at
I know this might be just a feature request, but it would be quite easy to implement it. Maybe you could include an option like in: function &headers($xtra_headers = null, $save_xtra_headers = true) { $headers['MIME-Version'] = '1.0'; if (isset($xtra_headers)) { $headers = array_merge($headers, $xtra_headers); } $headers = array_merge($headers, $this->_headers); if($save_xtra_headers) { $this->_headers = $headers; } return $this->_encodeHeaders($headers); } It wouldn't break anything, but would do what I (and maybe others need). The only way to do this now is $old_headers = $mime->_headers; $headers = $mime->headers($my_headers); $mime->_headers = $old_headers; The new function header(...) would allow a simple $headers = $mime->headers($my_headers, false); which is shorter and much cleaner. b4n
 [2005-03-06 23:20 UTC] fmunoz at digitalagencygroup dot com
After trying to implement a newsletter engine using Mail_mime I came accross this limitation. Is there any practical workaround to make the TO: in each email to be representing the actual instance in the Database instead of the address in the first row? Understanding that keeping backwards compatibility is an issue, it would be fantastic to have some implementation that would allow the use of Mail_mime to send succesive emails (changing the recipient address in the headers) using some class notation instead of "unclean" code.
 [2005-08-10 20:47 UTC] pearBOGUSWORDemail at polyBOGUSTOOsense dot com
I came across this bug and it took me hours to drill down and finally discover the culprit: in the headers() method I replaced the first line with the second. basically, swap the array_merge() parameter order so that your custom headers overwrite the internal array. ------------------- //$this->_headers = array_merge($headers, $this- >_headers); $this->_headers = array_merge($this->_headers, $headers); ------------------- IMHO, this is a bug because when a function says that you can set headers and it silently drops them in favor of the first ones it got, the function is implmented poorly. Either that or it is named poorly. I cannot think of any reason why this rewrite would break Backwards Compatibility... who relies on a function that overwrites parameters that you explicitly send it? Please fix this and save some other soul some lunch time. DC
 [2005-09-04 15:28 UTC] hoermann at simal dot de
This nasty thing took me too much time. The default behavior is not what one would expect from the function headers(). If you argue this is for backward compatibility i'm wondering why the setHTMLBody() and setTXTBody() functions are working like expected? For what reason would s.o. change the mail-body but keep the headers? Please change this behavior.
 [2005-09-04 18:29 UTC] alpha-REMOVETHIS at rrs dot at
The function I wrote here in the comments allows the (other) expected behavior and is backward compatible. Adding it would also document the current behavior and save some WTFs. If the developers of Mail_mime would prefer a patch I'll get HEAD and add that.
 [2005-09-06 19:46 UTC] pearBOGUSWORDemail at polyBOGUSTOOsense dot com
Yes, developers, please accept a patch from this generous soul above... Save future generations from the misery with which we have dealt.
 [2005-09-14 09:51 UTC] ota
Yes, please. Accept the patch from alpha. I lost several hours to find that "bug".
 [2005-12-20 16:37 UTC] cst at ecw dot de
I ran in to the same problem and came to the same bugfix. Please accept the patch. The patch leads to the "expected" behavior!
 [2005-12-20 16:49 UTC] cst at ecw dot de
Ugly but working workaround: unset($mime->_headers['To']); $headers = $mime->headers($headers);
 [2006-04-09 15:04 UTC] cipri (Cipriano Groenendal)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. I added a $overwrite parameter to the &headers function, that allows you to overwrite previously set headers.
 [2007-05-05 15:05 UTC] cipri (Cipriano Groenendal)
Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at Fixed in 1.4.0