judgej Posted June 24, 2003 Posted June 24, 2003 I have a problem that seems to happen only with certain mail clients, IE5 being one. Some users appear to receive e-mails (registration confirmation, order process etc) that shows the text part of the e-mail followed immediately by the HTML, but displayed as text. Is this a common problem? Is there a fix? Is it down to my PHP version (4.2.1)? Is it a specific bug in IE5.x? I've tried changing the format of the e-mail, wrapping it in <html><body> tags, but nothing I do makes a difference. It works fine for me on IE5.5. Any ideas? -- Jason
JH Posted August 7, 2003 Posted August 7, 2003 Hi Judge: I am having the same problem and I have IE5. I do not have an answer yet but it is really bothering me. I have looked at the e-mail properties(in outlook express) and osC is generating: Content-type: multipart/alternatative then it actually produces two copies of the actual e-mail text in the message source. One is labeled as text/plain and the other as text/html. There is a "boundary" set which is apparently separates the two copies of the e-mail in the actual message source. Only the one marked as text/plain shows up in the actual e-mail inbox and the link is not clickable (ie. it is just plain text). I just cannot seem to track donw why this is hapening, because in Administration I set it to send mime type html for e-mails. If you get an answer, let me know. If I get on I will let you know as well.
judgej Posted August 7, 2003 Author Posted August 7, 2003 I am having the same problem and I have IE5. I do not have an answer yet but it is really bothering me. Upgrade to IE5.5. I've seen the problem in IE5.5, but upgrading or reinstalling seems to help. The HTML OSC generates in the e-mail is not very good, but most e-mail clients make a good job at interpreting it. Some versions of IE just seem to handle it wrong though. No matter how much tweaking I do (html tags etc), I've never been able to solve the problem for those mail clients, so I just tell the users to upgrade. Strangley, an e-mail sent to both myself and one of the 'problem' e-mail clients will display okay for me, but not for them. If I then forward my copy on to that recipient, it will display correctly for them - as HTML. I think many people here are blissfuly unaware of the problem, because they do not always see what the buyers see. -- JJ
starapple Posted August 8, 2003 Posted August 8, 2003 Seen the problem too. Thought it was because I'd selected the HTML option as Jeff did. Sounds more like a program prob than browser but I'm not a programmer. I send similar messages from other apps and the HTML displays fine. All the Web's a stage.
JH Posted August 8, 2003 Posted August 8, 2003 Well... I think I have found the problem. And starapple, you are right, I think it is a programming error in osC (and I always reserve the right to be wrong). The fix is very dirty right now and I may try to clean it up so I can share it in code form. It may take just a little time and I am going to be pressed to get it done. Ok, here "seems" to be the problem in Admin>email where the selections are made: When you select E-mail Linefeeds - CR/LF or LF: In the email.php and mime.php scripts, this conditional is respected. i.e. the scripts check for the choice in admin and set either rn or just n in a variable named $this->lf (current email or mime object linefeed variable). This is all well and good, but in the checkout_process.php the line terminators (linefeeds) are hard coded to n at the end of each line. It gets deeper - If you have chosen to Use MIME HTML When Sending Emails as set to "true", then there are actually 2 copies of the order notification generated in the e-mail and the Content-Type is set to "multipart/alternative". Each part of the multipart is a copy of the order notification. One copy of the order is marked as Content-Type: "text/plain" and the other copy is marked as Content-Type: "text/html". These parts are separated by a "boundary" which is an md5 generated number. Anyway, I believe that this is meant to support e-mail clients that can or cannot handle html. If they can't you get the text/plain if they can you get the text/html. That is good. But, the only problem is, there is NO generated html tags in the html part except the use of nl2br to change newlines to br tags. So, the link back to the catalog for the order number just shows as text and it is not "clickable", because text/html depends on tags in the message (whereas text/plain will parse http and show a link). Ok... Now let's say you decide NOT to send html in Admin. Then there is only one copy of the e-mail sent as Content-Type: text/plain. This content-type will parse a URL (http://blah) and show as a clickable link, but the hard coded newlines ('n') in the checkout_process.php makes the rest of the message unreadable (in Windows). It just looks like a bad mess on the screen. There is more stuff but I think these are the essential problems. While writing this, I have come up with an idea they may be a usable short-term fix. What I really want to be able to do is construct a way to send a nice looking html order notification with images etc. The scripts seem to have some of the code in place to do this, but there is not a way to administer the use of it. If I get the useable fix to work (plain text with a click point to get back to order history), I will share it here. whew.. I hope this made sense!
judgej Posted August 8, 2003 Author Posted August 8, 2003 Yeah - I spotted that lot, fixed up the NL/CRs to be consistent, added proper links for the order link in th HTML part, put <html> and <body> tags in - but still some users get both parts of the e-mail. The problem is, an e-mail client is supposed to see the text part or the html part, not both. Both (as text) is what some e-mail clients seem to display. The best consistency I have managed to get from the NL/CR is to replace all NLs with the NL/CR pair right at the end. It means some lines in the text version are double-spaced, but at least it is consistent. What OSC should do is deal entirely in NLs internally. If an e-mail needs CR/NL pairs, then convert the NLs before e-mailing the message - but not before that, because it just gets inconsistent. I suspect that maybe there is something in the md5 boundary string that some clients can't cope with. I'm not sure though, as I've not been able to whittle it down to the specific line that causes the problem (it works on my e-mail client, that's the problem, so I need to get someone else to place an order to test any changes I make, and they will only do that so many times;) -- JJ
starapple Posted August 8, 2003 Posted August 8, 2003 Guys, I was looking for a bugs report section to see whether this issue had been reported but I missed it. Could have sworn I saw a bugs section. I believe Jeff is isolating the problem well ... but I'm not a programmer. All the Web's a stage.
JH Posted August 8, 2003 Posted August 8, 2003 Hello again: judgej- you are correct- even though there are two copies of the email embedded in the e-mail message, the email client will show the one it can. If it can parse plain text only it will show the "text/plain" copy. If it can handle both, it will show the "text/html" copy. If I implied that I was seeing both in my e-mails, I did not mean to do that. I have inspected the e-mails through the properties of the e-mail and saw the two copies there. But for my quick fix for now, this is important. More in a minute... Ok. I have a fix but because there are differences in the different snapshots of osC, I cannot post an entire php script. Some of you would have a different version (although I have downloaded 2.2ms2 I am using an older version still) and I have compared the scripts and there are differences due to the snapshot itself. But the fix is relatively painless so here you go. In /catalog/checkout_process.php: Just below the line: include('includes/application_top.php'); Insert this code: // Make sure we use the correct linefeed sequence if (EMAIL_LINEFEED == 'CRLF') { $lfeed = "rn"; } else { $lfeed = "n"; } Then carefully using your editors find and replace, search through each line of the code in checkout_process.php and replace all the hard coded linefeeds "n" with the "$lfeed" variable just established. (I suggest not using global search and replace because you will need to put a space between a couple of them. There is not that many so it does not take long, plus, you can make sure your replace does not affect surrounding code). You will see a "nt" and it will end up looking like "$lfeedt". You will see "nn" those should end up looking like "$lfeed $lfeed" (You supply the space) Mostly you will see just "n" and that will look like "$lfeed". This will fix plain text confirmations only (MIME HTML set to "false" in Admin), because osC is still not generating the other HTML tags needed to make the HTML copy work yet. The fix to get a rudimentary HTML version will follow. What I mean by rudimentary is that the HTML confirmation e-mail will look just like the text version(no embellishments), but it will show the link properly. If you go with the fix above, Then in Admin->email, make sure you set the MIME HTML to "false" and for windows set the linefeed to "CRLF". I will post the HTML fix a little later, just got a phone call and I have to take care of it. Later
judgej Posted August 8, 2003 Author Posted August 8, 2003 What I do is send the link as a proper HTML anchor to the e-mail function, and allow the e-mail function to strip out the anchor tag (leaving the URL only) for the text version. Also - I haven't posted a fix, as everyone is running a different customised/hacked version of OSC. Ideally, the achor: <a href="url">url</a> should be converted to this in the text version: <url> rather than just 'url'. I believe the angle-brackets are picked up by some e-mail clients to indicate this is a URL. Other e-mail clients see the 'http:/...' and that is enough for them, but the angle-brackets are the ones to use (I don't know which RFC that's in, this is just from memory). So, the best way OSC could handle this is to create a valid HTML e-mail using newlines only, then convert a version of that to text and change the NLs as needed right at the end, just before sending the e-mail. -- JJ
judgej Posted August 8, 2003 Author Posted August 8, 2003 PS There are e-mail client versions that really do see both the text and the HTML in the e-mail they receive. They should not do that - it is a bug somewhere, and I suspect something in the e-mail that certain just clients can't cope with. It wish I knew how often it happens, but it's the kind of feedback I don't get often. -- JJ
starapple Posted August 8, 2003 Posted August 8, 2003 If you guys are interested , I got both text and html in a nessage I sent from the contact page (message - "This is Tuesday August 5, 2003"): DATA To: "Lee Media Associates" <[email protected]> Subject: Enquiry from CoronationMarket.com From: "Mark Lee" <[email protected]> MIME-Version: 1.0 X-Mailer: osCommerce Mailer Content-Type: multipart/alternative; boundary="=_51c8b8186cba5c012e0a9dbe9f81d4d8" Message-ID: <[email protected]> Date: Tue, 05 Aug 2003 09:17:57 -0500 --=_51c8b8186cba5c012e0a9dbe9f81d4d8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This is Tuesday, August 5, 2003 --=_51c8b8186cba5c012e0a9dbe9f81d4d8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is Tuesday, August 5, 2003 --=_51c8b8186cba5c012e0a9dbe9f81d4d8-- All the Web's a stage.
JH Posted August 8, 2003 Posted August 8, 2003 Hi starapple: In the data you sent just above.. did both versions show up when you view the e-mail regularly? If that data was taken from the "properties" then that is ok. It is what shows up in the regular view of the e-mail is the thing. Is the user seeing both versions? also, I almost have an html fix for the html, but I am running into a strange little error that seems to be generated in the tep_href_link function. It is taking the account_history_info.php in the URL and stripping out the '.' just before php and is showing up as account_history_infophp?order_id=blah in the actual link. But the strange thing is I use the same tep_href_link call to fill-in what the user sees on the screen as the link, and it works fine. Can't seem to find what is stripping the '.' out. By hand, if I pass account_history_info..php (two dots) then it works fine.. but that is not acceptable. But for this one little problem, I have a fix that seems to work very well for text and html.
JH Posted August 8, 2003 Posted August 8, 2003 One note about the version differences. In two different snapshots and the 2.2ms2 release, all have the hard coded "n" in the checkout_process.php script and the fix I offered above with the $lfeed treatment should work in each of them. It just needs to be done by hand instead of a script replacement. $lfeed was chosen by me just for clarity... you can use any variable name you want just be careful not to duplicate another one already in use. Bear in mind that the fix I posted should still work for folks that have LF set in Admin, as well. Back to looking at the '.' problem.
JH Posted August 9, 2003 Posted August 9, 2003 Here are the fixes that will allow you to use MIME HTML in Admin: The scripts that are affected are email.php and checkout_process.php (both in the catalog directory... not the language directory) In email.php located in the /catalog directory near line 218 (may be a little different based on osC version) you will find this function: function add_html_part(&$obj) { $params['content_type'] = 'text/html'; $params['encoding'] = $this->build_params['html_encoding']; $params['charset'] = $this->build_params['html_charset']; if (is_object($obj)) { return $obj->addSubpart($this->html, $params); } else { return new mime($this->html, $params); } } Add 2 lines of code starting at the variable named $htmlstring. Sorry, but these code lines wrap pretty ugly here on the BB but you should be able to get it. The $htmlstring is actually one line. function add_html_part(&$obj) { $params['content_type'] = 'text/html'; $params['encoding'] = $this->build_params['html_encoding']; $params['charset'] = $this->build_params['html_charset']; if (is_object($obj)) { $htmlstring = '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">' . '<html>' . $this->lf . '<head>' . '<title>' . STORE_NAME . '</title>' . '</head>' . $this->lf . '<body>' . $this->lf . $this->html . '</body>' . $this->lf . '</html>'; $this->html = $htmlstring; return $obj->addSubpart($this->html, $params); } else { return new mime($this->html, $params); } } You can even add a few things to the body tag and maybe even put in an image tag to place an image on your order confirmation. In the checkout_process.php script found in the /catalog directory on or about line 196. You will find this code: Sorry that it wraps so ugly here. // lets start with the email confirmation $email_order = STORE_NAME . "n" . EMAIL_SEPARATOR . "n" . EMAIL_TEXT_ORDER_NUMBER . ' ' . $insert_id . "n" . EMAIL_TEXT_INVOICE_URL . ' ' . tep_href_link(FILENAME_ACCOUNT_HISTORY_INFO, 'order_id=' . $insert_id, 'SSL', false) . "n" . EMAIL_TEXT_DATE_ORDERED . ' ' . strftime(DATE_FORMAT_LONG) . "nn"; if ($order->info['comments']) { $email_order .= $order->info['comments'] . "nn"; } Replace it with: // lets start with the email confirmation $email_text_invoice_url = tep_href_link(FILENAME_ACCOUNT_HISTORY_INFO, 'order_id=' . $insert_id, 'SSL', false) . "$lfeed"; if(EMAIL_USE_HTML == "true") { $email_invoice_url = '<a href="' . $email_text_invoice_url . '">' . $email_text_invoice_url . '</a>' . ' ' . "$lfeed"; $email_text_invoice_url = $email_invoice_url; } $email_order = STORE_NAME . "$lfeed" . EMAIL_SEPARATOR . "$lfeed" . EMAIL_TEXT_ORDER_NUMBER . ' ' . $insert_id . ' ' . "$lfeed" . //EMAIL_TEXT_INVOICE_URL . ' ' . tep_href_link(FILENAME_ACCOUNT_HISTORY_INFO, 'order_id=' . $insert_id, 'SSL', false) . "$lfeed" . EMAIL_TEXT_INVOICE_URL . ' ' . $email_text_invoice_url . EMAIL_TEXT_DATE_ORDERED . ' ' . strftime(DATE_FORMAT_LONG) . "$lfeed $lfeed"; if ($order->info['comments']) { $email_order .= $order->info['comments'] . "$lfeed $lfeed"; } Actually you are inserting a code block above the existing code and then commenting out one line of existing code and replacing it with a new line of code. This has worked for me with about 20 or 30 test orders. Hope this helps. Also, I tried to be careful while I was cutting and pasting this stuff, but don't shoot me if I made any small errors.
JH Posted August 9, 2003 Posted August 9, 2003 THIS IS THE SAME POST AS ABOVE--- I just tried to clean up the line wraps but they are still a little ugly... hey I tried 8) Here are the fixes that will allow you to use MIME HTML in Admin: The scripts that are affected are email.php and checkout_process.php (both in the catalog directory... not the language directory) In email.php located in the /catalog directory near line 218 (may be a little different based on osC version) you will find this function: function add_html_part(&$obj) { $params['content_type'] = 'text/html'; $params['encoding'] = $this->build_params['html_encoding']; $params['charset'] = $this->build_params['html_charset']; if (is_object($obj)) { return $obj->addSubpart($this->html, $params); } else { return new mime($this->html, $params); } } Add 2 lines of code starting at the variable named $htmlstring. function add_html_part(&$obj) { $params['content_type'] = 'text/html'; $params['encoding'] = $this->build_params['html_encoding']; $params['charset'] = $this->build_params['html_charset']; if (is_object($obj)) { $htmlstring = '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">' . '<html>' . $this->lf . '<head>' . '<title>' . STORE_NAME . '</title>' . '</head>' . $this->lf . '<body leftmargin=0 topmargin=0 >' . $this->lf . $this->lf . $this->html . '</body>' . $this->lf . '</html>'; $this->html = $htmlstring; return $obj->addSubpart($this->html, $params); } else { return new mime($this->html, $params); } } You can even add a few things to the body tag and maybe even put in an image tag to place an image on your order confirmation. In the checkout_process.php script found in the /catalog directory on or about line 196. You will find this code; // lets start with the email confirmation $email_order = STORE_NAME . "n" . EMAIL_SEPARATOR . "n" . EMAIL_TEXT_ORDER_NUMBER . ' ' . $insert_id . "n" . EMAIL_TEXT_INVOICE_URL . ' ' . tep_href_link(FILENAME_ACCOUNT_HISTORY_INFO, 'order_id=' . $insert_id, 'SSL', false) . "n" . EMAIL_TEXT_DATE_ORDERED . ' ' . strftime(DATE_FORMAT_LONG) . "nn"; if ($order->info['comments']) { $email_order .= $order->info['comments'] . "nn"; } Replace it with: // lets start with the email confirmation $email_text_invoice_url = tep_href_link(FILENAME_ACCOUNT_HISTORY_INFO, 'order_id=' . $insert_id, 'SSL', false) . "$lfeed"; if(EMAIL_USE_HTML == "true") { $email_invoice_url = '<a href="' . $email_text_invoice_url . '">' . $email_text_invoice_url . '</a>' . ' ' . "$lfeed"; $email_text_invoice_url = $email_invoice_url; } $email_order = STORE_NAME . "$lfeed" . EMAIL_SEPARATOR . "$lfeed" . EMAIL_TEXT_ORDER_NUMBER . ' ' . $insert_id . ' ' . "$lfeed" . //EMAIL_TEXT_INVOICE_URL . ' ' . tep_href_link(FILENAME_ACCOUNT_HISTORY_INFO, 'order_id=' . $insert_id, 'SSL', false) . "$lfeed" . EMAIL_TEXT_INVOICE_URL . ' ' . $email_text_invoice_url . EMAIL_TEXT_DATE_ORDERED . ' ' . strftime(DATE_FORMAT_LONG) . "$lfeed $lfeed"; if ($order->info['comments']) { $email_order .= $order->info['comments'] . "$lfeed $lfeed"; } Actually you are inserting a code block above the existing code and then commenting out one line of existing code and replacing it with a new line of code. This has worked for me with about 20 or 30 test orders. Hope this helps. Also, I tried to be careful while I was cutting and pasting this stuff, but don't shoot me if I made any small errors. Good selling and e-mailing. 8)
starapple Posted August 10, 2003 Posted August 10, 2003 Hi Jeff, That's the actual body of the email send; not taken from the properties. All the Web's a stage.
starapple Posted August 10, 2003 Posted August 10, 2003 That should have been "the actual body of the email which was sent/received." All the Web's a stage.
JH Posted August 10, 2003 Posted August 10, 2003 Hi starapple: In your example: To: "Lee Media Associates" <[email protected]> Subject: Enquiry from CoronationMarket.com From: "Mark Lee" <[email protected]> MIME-Version: 1.0 X-Mailer: osCommerce Mailer Content-Type: multipart/alternative; boundary="=_51c8b8186cba5c012e0a9dbe9f81d4d8" Message-ID: <[email protected]> Date: Tue, 05 Aug 2003 09:17:57 -0500 --=_51c8b8186cba5c012e0a9dbe9f81d4d8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This is Tuesday, August 5, 2003 --=_51c8b8186cba5c012e0a9dbe9f81d4d8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is Tuesday, August 5, 2003 --=_51c8b8186cba5c012e0a9dbe9f81d4d8-- If the browser is showing both, I agree with judgej that either there is a problem with the browser, or the browser is somehow set up to look at both text/plain and text/html at the same time. But notice the text/html part of the message - there are no html tags - it is only plain text. If it is true html, it should at least have the basic <html><head></head><body></body></html> tags. That is what the hack I posted does is put the html tags into a regular e-mail for the html part of the order notification. If you use that hack, you can actually amend the body tag with background colors or images etc. just by inserting them like this<body bgcolor=xxx or background=imagename>. You can even put other html stuff there as well, such as an image banner by putting in the appropriate <img src=blah /> tags and make sure you include them in the $htmlstring with appropriate quotes and '.'(dots), and a $this->lf if needed to extend the $htmlstring. By the way, I noticed in my code posts that the "."(dots) at the end of the lines do not show up well on the BB, and if they are not included in the building of the $htmlstring, then it won't work (so make sure you see and use the . (dots) if you use the hack). However, it looked as though the email.php script was designed, and actually coded in some cases, to do more than is currently apparent in normal osC use. Maybe there is some documentation out there describing some of those uses. The point is though, you could really hack this thing to generate more elaborate html notification pages, but when a new revision comes along, you will have to re-hack the code to continue to use it. SOOoooo.. my suggestion is to keep the hacks to a minimum and life may be easier in the future. --note-- In the email.php script, there is actually a get_file function (method) to read in a file to be included with the e-mail. But for order notification, the data is generated dynamically and combining a file read from disk with the generated data is more than just putting in the html tags the way I did. In the email.php there is a comment section just above the function get_file. /** * This function will read a file in * from a supplied filename and return * it. This can then be given as the first * argument of the the functions * add_html_image() or add_attachment(). */ The add_html_image() and add_attachment() functions are in the email.php script, so you could try this out for images and attachments. I am sure their may be other hacks... but the one I posted seems to work pretty well to generate the standard order notification in html and have the link to the order actually work. one more hint: In the code of the checkout_process.php hack that I posted earlier there is a line of code that looks like this: $email_invoice_url = '<a href="' . $email_text_invoice_url . '">' . $email_text_invoice_url . '</a>' . ' ' . "$lfeed"; The $email_text_invoice_url string is used twice. Once to build the href and the other as the visible text for the link. I did it this way just to stay consistent with the standard look of osC. if you wanted, you could replace the second occurance of the $email_text_invoice_url with something like "Click here to see your order". It would look like this: $email_invoice_url = '<a href="' . $email_text_invoice_url . '">' . 'Click here to see your order' . '</a>' . ' ' . "$lfeed"; I do hope that this will end the frustration for others that I had with the order notification. I think that Harold Ponce de Leon and all the developers of osCommerce have done a great job and have helped a lot of people. My appreciation and thanks goes out to them!
emetani Posted August 10, 2003 Posted August 10, 2003 I did the modifications , it is working fine . Only when I modify the checkout_process I get email alighment problem , so I replace $lfeed with n , then it become OK . What is the meaning of n ? One more issue , in admin under tools , when I select Send Email , it does not send html only text , any advise ??
starapple Posted August 10, 2003 Posted August 10, 2003 My concern is that it's a general email problem. As the post by emetani and myself shows, emails from various segments of the program throw up probs: In contact, in admins, in orders. Hope the main programmes will catch on and maybe post the fix you created. All the Web's a stage.
JH Posted August 10, 2003 Posted August 10, 2003 Thanks starapple. I hope the fixes solved your problem. emetani The "n" is a newline character. On Linux the newline character is the n, and this single character performs a carriage return and a linefeed. On Windows a newline is two characters, a carriage return followed by a linefeed, rn, (referred to as CRLF). That is where some of the problem came from in this series of fixes. In this series of fixes I dealt with two different problems. One was the way that the checkout_process.php handles the newline character in general, which affected the way that e-mails appeared on Windows machines. The other problem was the way html was being handled when MIME HTML was selected in Admin->Configuration->Email Options. You may have missed a very important part of one of the posts and you should not have had to go back to the hard coded n originally found in the checkout_process.php script. In Admin->Configuration->E-mail Options the user has a choice for selecting E-Mail Linefeeds (LF) or (CRLF). The (LF) option represents the n and the (CRLF) represents the rn. There are three scripts that affect how the e-mail is actually sent for order confirmations. They are the checkout_process.php, email.php, and mime.php. In email.php and mime.php there is code that looks at the setup variable from the admin configuration and uses the one chosen by the user for their processing. In checkout_process.php, there was no code to handle the users choice. In one of the posts I made earlier I had a section of code that would allow checkout_process.php to process the users choice. In the script /catalog/checkout_process.php: Just below the line: include('includes/application_top.php'); Insert this code: // Make sure we use the correct linefeed sequence if (EMAIL_LINEFEED == 'CRLF') { $lfeed = "rn"; } else { $lfeed = "n"; } emetani - if you go back to your checkout_process.php and insert the code above, then change your n back to the $lfeed, then your linefeeds should be handled properly. JUST REMEMBER - In ADMIN->CONFIGURATION->E-mail Options->E-mail Linefeeds to set the correct option for your servers operating system. On Linux set it to (LF) and on Windows set it to (CRLF). Everything should appear fine after you do these steps. Also, you stated: One more issue , in admin under tools , when I select Send Email , it does not send html only text , any advise ?? In this particular case the e-mail process is handled by processing from the /admin/includes/classes/email.php script which is different from the one in the /catalog/includes/classes/email.php. Just a note here. The developers made a good choice to separate the Admin from the Catalog processing in my opinion. This allows for a Administration to be handled from a different location than the actual catalog if need be. Hope this helps.
JH Posted August 10, 2003 Posted August 10, 2003 One correction emetani. The mail being sent under Admin/Tools/Send Mail is handled by the /admin/mail.php script. If you want, there is a line of code in that script that you can change and your email will be sent in text/html Content-Type. BUT... what this means is that the if you want nice looking html with images and all that in the message that you send, you must write your message in html. You could use any html editor to make your html page (message) first and then cut and past it into the message you are sending. If you don't write it in html it will just show up in text format. the line of code is in /admin/mail.php on or about line 40. It looks like this: $mimemessage->add_text($message); You can change it to: $mimemessage->add_html($message); // Note: Changed add_text to add_html This should work for you. Note your change with a comment and if you ever find anywhere that this creates a problem, you can go back and change it. But I don't think you will see a problem. good emailing!
emetani Posted August 10, 2003 Posted August 10, 2003 I have this code already at line 40 admin/mails.php : $mimemessage->add_html($message); Anyway thank you for the help , the main issue is solved , with this small bug I can live also I am using some other software for the email campaign . Thanks again.
New 
Recommended Posts
Archived
This topic is now archived and is closed to further replies.