why wasn't it fixed in v1.3.7?
why wasn't it fixed in v1.3.7?
Not sure I understand the question Dizzie.
I've been looking at this intermittently for several months, but a couple of days ago I got sufficiently annoyed with the anomalous behaviour to sit down and trace through what was happening.
Since actually getting the admin set to use 8bit on my mail server, mail and newsletters from admin all arrive at the 'problem' accounts in glorious html. It's quite possible that some sections were picking up the shop setting, but newsletters certainly wasn't.
Chuck
Dizzie, did the suggestion fix the problem for you ?
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
How would I test it? Send a fake newsletter out..if it doesn't work, then I look like an idiot AGAIN...if it does work then I still look like an idiot for the fake newsletter...??
Dizzie,
A caveat, I run my own servers so I have control over the setup, what is used or usable etc etc.
That said, the setup that produced the desired html newsletters is as follows:
Server - Ubuntu Linux 6.06 - 2.6.15-27
PHP 5.1.2
MySQL 5.0.22
Mail - Postfix, 8bit Mime enabled.
Zen Cart 1.3.7
In Admin, mail transport set to PHP, email linefeeds LF, use mime, send email, use archiving and friendly errors all set to true, as well as 'must send from known domain. Admin format set to HTML.
Editor used is FCKEditor.
What prompted my investigation was that the newsletters were always received as 7bit mime, despite it being set to 8bit, and that my mail server is also set to 8bit, and only reformats to 7 if the destination server cannot handle 8.
Since I was getting the mail off the same server Zen Cart was using, this seemed strange, and led to the discovery that newsletters were not picking up the transport method setting.
I have tested it with both Newsletter only subscriptions mod installed and without, and it seems to work fine, and tested to Gmail, Hotmail and some fairly strictly setup Outlook clients. All work.
With regard to how to test it, I've attached a functions_email.php which has been modified to force html on the admin user. i.e. if you select the administrator from the newsletter audience select, it will send the html newsletter, not the text version.
It is a brute force hack, just the 2 following pieces of dreadful code added:
$adm = 0;
$fndadm = 'ADMIN';
$adm = strpos($to_name,$fndadm);
if ($adm===false) $adm=0;
else $adm=1;
if ($adm > 0){
$customers_email_format = 'HTML';
}
if ($adm > 0) {
$mail->IsHTML(true);
$mail->Body = $email_html;
$mail->AltBody = '';
but it at least allows you to send test newsletters to admin.
I honestly don't remember whether I wrote this, or found it somewhere, so if I have appropriated someone elses code, I apologise, please let me know, and I will gladly give acknowledgement.
If you use the newsletter subs mod, shout and I'll send the file.
Rgds,
Chuck
Thanks Chuck.
That works for me.
Sorry - I spoke too soon. The administation newsletter arrives OK, but I just set up two test accounts - one to Yahoo and one to my ISP address.
The Yahoo account received plain text - and all messed up too because it was converted from HTML.
Back to the drawing board...
This is unfortunate - I've converted an existing site over to Zen Cart and was hoping to have everything (including the newsletter) integrated.
Paul,
Glad you had at least some success! I don't use Yahoo mail at all, so I can't comment, but all web based email is touchy at best. Have you played around with the email preferences with you Yahoo mail?
Best practice guidelines seem to be to use tables, not CSS, and keep it simple. I also have a suspicion that HTMLArea tends to leave dangling HTML tags all over the place when you do a lot of editing, which is why I changed to FCKEditor, which seems cleaner. Purely subjective personal preference, and might be totally untrue.
The changes I mentioned in this thread do two things, enable 8bit mime from admin, which the web based mail services seem to prefer, and allow Admin html mail. When sending, the code checks the subscriber and customer tables for an email format. Since the admin user is a special case, nothing is found, and the code defaults to text based. The hack above detects the admin user and forces html mail.
My test emails consisted of several 2 or 3 column 1 row tables, with all images and text, and therefore divs, formatting etc in the tables.
Final thoughts, since you are getting what is obviously html as text, I would guess that it is yahoo mail that is stripping out the formatting. Also, were you sending to that Yahoo mail address as admin at all, or as a dummy customer?
Chuck
Chuck,
Instead of the hacks you suggested, does this work correctly?
/includes/functions/functions_email.php
find this code:add this directly below it:Code:if (ADMIN_EXTRA_EMAIL_FORMAT == 'TEXT' && substr($module,-6)=='_extra') { $email_html=''; // just blank out the html portion if admin has selected text-only }Code:// if no customer email record found, and admin email format is set to HTML, and sending newsletter, and admin is logged in, use HTML: if ($customers_email_format_read->RecordCount() == 0 && ADMIN_EXTRA_EMAIL_FORMAT == 'HTML' && in_array($module, array('newsletters', 'product_notification')) && isset($_SESSION['admin_id'])) { $customers_email_format = 'HTML'; }
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Bookmarks