Headers being replaced (can't define From:)
timtrinidad - November 25, 2008 - 04:13
| Project: | HTML Mail |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
In line 20 of the code, hook_mail_alter is replacing then entire $message['headers'] variable with the content type:
<?php
$message['headers'] = array(
'Content-Type' => 'text/html; charset=UTF-8;',
);
?>Any previously assigned headers are now lost, especially the "from:" address specified by the sixth argument of the drupal_mail function. I'm not sure if that's by design, but would simply redifining the "Content-Type" key of the $message['headers'] array do the same trick? For example:
<?php
$message['headers']['Content-Type'] = 'text/html; charset=UTF-8';
?>That way other headers are still left intact.
#1
Committed to HEAD, thanks ttrinidad.
Please test.
#2
Works for my setup! Thanks, Chris.
Tim
#3
Automatically closed -- issue fixed for two weeks with no activity.
#4
It seems as if this commit was overwritten by an older version and is no longer in the latest release (official or dev).
#5
Yeah, would be nice if you updated, this was a pain in the arse to find. :(
#6
Still a problem in the release.
#7
Here's a patch.
#8
Because Mime mail module still does not work for drupal 6, in the simplenews module we had to use HTML mail module. This patch solved the problem of "from:" address being changed into something like mydomain@box...bluehost.com. By the way, simplenews needed also a patch to be able to use the htlm module. See http://drupal.org/node/367488
Thanks a lot.
Piccola
#9
This still seems to cause problems with the mail envelope coming from the server address rather than that specified - so many mail servers decline the messages. Is there anything I can do to solve this?
Thanks,
Adam
#10
here is a patch that has been re-rolled from the current dev version
#11
I'd like to propose a change here that doesn't override the Content-Type header if it already exists. Other modules have the opportunity to create the Content-Type message header to match the actual message body, and, lets say, the module needed to change the charset aspect of the Content-Type header. Well, this module, as is even with the patches above, might conflict with some other modules' previously-specified Content-Type header, and there still exists the possibility that this module overrides it, causing problems lets say in the case of charset.
All this module really needs to do is ensure that someone has set the type to 'text/html', they don't care about charset. So I propose a solution like the following:
If the Content-Type header exists and already has 'text/html' then do nothing, otherwise add in the default value (text/html; charset=UTF-8;)
Circa line 20, htmlmail.module
<?phpif (!preg_match('/text\/html/', $message['headers']['Content-Type'])) {
$message['headers']['Content-Type'] = 'text/html; charset=UTF-8;';
}
?>
And further below... use the Content-Type value in the header array for the "HEAD" section of the message body...
Circa line 30, htmlmail.module
<?php// Insert the preformatted HTML so the end user only needs to enter what goes between the <body> tags.
// this of course can be overridden in the admin settings for this module.
if (variable_get('htmlmail_preformat', '1') == 1) {
$message['body'] = "<html>\n" .
"<head>\n" .
"<meta http-equiv=\"Content-Type\" content=\"{$message['headers']['Content-Type']}\" />\n" .
"</head>\n" .
"<body>\n". $message['body'] ."</body>\n" .
"</html>\n";
}
?>
I also vote that if not my suggestions, at least the above patches get rolled into a NEW RELEASE PLEASE. This seems to have affecting enough people (myself included) and has cause various people to have to track down the problem and fix it, such that a simple 6.x-1.1 release would be worthwhile. thanks!
#12
#11 jrguitar21, commited Circa line 20 header fix as per this comment. -- To 6.x dev and HEAD
Circa line 30, this is probably the 5.x code as theme function was added some time ago to 6.x
Although this is a good way to attack we're only theming the body a this time. this will be considered for a future release.
#13
#14
Automatically closed -- issue fixed for 2 weeks with no activity.