| Project: | Ubercart |
| Version: | 6.x-2.0-rc2 |
| Component: | Website |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
So after upgrading to rc1 I noticed the email sent after an order is completed is no longer all pretty. lol.
It use to include the site's logo and all the info inside a table. Now it seems to just be basic text with some paragraph tags.
At first I thought it was something I did. I checked the CA trigger and it is sending the correct invoice template.
I did notice if you goto admin/store/orders/view and click on an order and then send the invoice via mail it sends the correct html email.
About to go live with a site and just ran into this issue. Hopefully its an easy fix.
if you want to try it out.. http://snoutsdirect.com
The site is still set up to use paypal's sandbox. So if you want to put in an order for a part you will notice the email is mostly plain text.
Thanks in advance.
Comments
#1
I can confirm that the e-mail HTML and content has changed as described, somewhere between beta5 and rc1. (I upgraded from beta5, where things were working, to beta6, then to rc1, where the problem showed up. I didn't test it in beta6.)
In beta5, start of e-mails looks something like this (site-specific stuff removed, replaced with text in []):
<x-html><table width="95%" border="0" cellspacing="0" cellpadding="1" align="center" bgcolor="#006699" style="font-family: verdana, arial, helvetica; font-size: small;">
<tr>
<td>
<table width="100%" border="0" cellspacing="0" cellpadding="5" align="center" bgcolor="#FFFFFF" style="font-family: verdana, arial, helvetica; font-size: small;">
<tr valign="top">
<td>
<table width="100%" style="font-family: verdana, arial, helvetica; font-size: small;">
<tr>
<td>
<img src="[store logo]" />
</td>
<td width="98%">
<div style="padding-left: 1em;">
<span style="font-size: large;">[store name]</span><br/>
</br/></div>
</td>
<td nowrap="nowrap">
[store name]<br />[store city, postal code]<br />[store zone, country]
</td>
</tr>
</table>
</td>
</tr>
<tr valign="top">
<td>
<p><b>Thanks for your order, [customer name]!</b></p>
In rc1, start of e-mails looks something like this:
<x-html><p>[store name]</p>
<p> [store address]</p>
<p> Thanks for your order, [customer name]!</p>
#2
Thanks TR for elaborating. I've been working on an UC site for the past month constantly upgrading as soon as a new release was green. beta 6 was right before this and i was using it. I was testing the orders to make sure the tax thing was fixed. Which it is. If i remember correctly the html email worked fine in beta6. I can check my emails when i get back to work tomorrow.
Thanks again
#3
This occurs because input format filtering is applied to the invoice templates. While I'm not sure this is strictly necessary because the template files are stored in the filesystem and should not be editable by any user, the fix is to change the input format selection at /admin/store/ca/uc_checkout_customer_notification/edit/actions from "Filtered HTML" to "Full HTML".
A patch is attached that changes the default input filter for the customer invoice predicate to Full HTML. The patch also corrects a typo in uc_order_action_email_invoice() which meant that an incorrect "from" address was used when sending the invoice emails.
#4
Hmm.
Not sure the default input filter should be set to Full HTML.
I can see the advantage of putting the order e-mail through an input filter, because snazzier filters than just a restricted HTML set can be used. But I wonder if the disadvantages outweigh the advantages. Not sure.
If the code is to stay as it is, the documentation should probably be changed to make more explicit the fact that the template file won't just be left as it is. The same template folder is used for e-mails as for customer on-screen invoices (for which no filters are applied), so if the behaviour is to be different that should be made clear.
#5
I don't have a problem making it Full HTML by default. Regular users will never see these settings.
What I don't understand is why we're passing HTML generated by invoice templates through check_markup() at all. It's even confusing on the action form for e-mailing an order invoice why the "Input format" element is there... it looks like it's there for your e-mail subject. : P
So, I'm going to remove that element and default it to Full HTML (format 2) for now unless someone has a good reason not to... fwiw, that's the way e-mailing an order invoice through the admin order invoice form works now anyways. It doesn't use check_markup().
Can someone verify the fix in the attached patch?
@longwave, fwiw, you might make sure you're on the latest version of UC. I don't see that $settings['form'] typo anywhere.
#6
I guess this could have undesired results if a store owner changes their input filter settings so input format #2 is no longer just Full HTML and has other filters applied; there should be no need to filter the invoice as if it were user-supplied content at all.
As for the typo, it's definitely still in CVS - I have no idea why this was committed:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ubercart/uc...
#7
lol, no clue. I'll ping Lyle to make sure it's fixed before he tags the RC 2.
#8
Thanks for taking time to figure this out for me. I thought i was going crazy lol. Freaked me out b/c it worked before I upgraded and I thought I changed a setting. I didn't apply the patch since my site email is the same as my ubercart email so it doesn't really matter. It was sending it from the correct one. Thanks again longwave for taking time to help me in the ubercart chan. Hopefully that $20 can buy you some beers lol.
#9
I agree that we don't need to use filters on the invoice, especially since it is parsed as PHP when it is loaded. Since check_markup() is used in uc_order_mail(), I've changed it to not do that if a format is passed in to it. uc_file and uc_roles also use that mail function, so they should be unchanged.
However, some sites may have changed these predicates, so the formats might be saved in the database. The updated patch cleans those out so they won't continue to be filtered inappropriately.
#10
Committed the patch with a minor tweak to ensure a message body was added when a format was not set.
#11
The 'form' typo is still present in rc2, see line 1109:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ubercart/uc...
#12
May this issue be dead an buried forever.
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ubercart/uc...
#13
^_^
#14
Thanks a lot everyone :)
#15
Automatically closed -- issue fixed for 2 weeks with no activity.