Email notifications not working

I have also seen this, especially with Paypal IPN functions. I find customers have paid for things and I don't get notified. I don't know if this contributes to the solution, but I wanted to get this thread on my watchlist nonetheless. If anyone in the know wants to look at my set up then I'll be happy to lend out server access for a diagnosis.

I discovered that the mailouts happen at cron time, not immediately the order is placed.
So we have to ensure cron runs regularly.
This may not be your problem, but it was a gotcha for me.

Are other emails sent from your system OK?

The customer does not receive notification if I install COD and set it as payment received at the purchase.
The custumer receive notification if I uninstall COD but the item list states [items] not the actual list of products.
The shipper does not receive email unless I run the cron, but the email is almost unreadbale filled with html.

Similar issue for me.

Notifications works (at cron run), even with COD, but Store transaction notices does not work at all, with any sistem activated.

There are some more related issues open, but no solution. Why this is not considered as important? For an owner, receiving a mail that alerts that a sale is happened is very important, I think...

Happens to me too with paypal, as a workaround I use the debug email until it is fixed,

how do you use the debug email?

There was an issue with transaction notices that gave errors on my system, but may have prevented yours working at all

http://drupal.org/node/166099

Incorrect email headers were being used. In my case, the PHP defaults were enough to still get the mail through.

Another issue that was showing HTML code in the email has also been fixed.

http://drupal.org/node/165756

none of the fix solved my issue...

Can you provide any more information? What are you seeing in your logs when the Cron job runs? Do you have access to the server logs to see if any email errors are occuring?

Hi,
no errors are reported at cron's run, none in the server log.
Notification to the customers are regulary sent without need of cron.

Nothing to add....
Last drupal, last ecommerce dev, php 5.1.5, mysql 4.1.20

So to summarize, email notification to customers (buyer) does work, but NOT the Store transaction notice by email, hence no info is emailed to the seller alerting about the purchase? But the order (transaction) is registered in Drupal?

Can you give some more details about what product type etc. you are using? Sandbox? I use 5.x-4.x-dev myself, so I like to test to see if I can reproduce it there.

I was thinking, could this issue possibly have anything to do with http://drupal.org/node/168767 ?

Have you downloaded the latest 3.x-dev of today and retested?

well yettyn,
the situation is as you summarize. I'm working with the last 5.x-3.x-dev with no result.

I'm working with live subproducts and tangible products.

The only way i've found to receive a copy of the mail sent to the customer is this module http://drupal.org/node/80032 (that works only with the standard mail stored in the site info....)

I am working with ecommerce-5.x-3.x-dev, Apparel Products, Shippable Product, Shipcalc, AuthorizeNet. From the workflow selecting 'shipping notify' The shipping email does not go out nor does the workflow state change. There are no errors in my logs. The customer receives thier initial purchase invoice and if I use the 'ask a customer' from the workflow the email DOES goes out but the workflow state does NOT change.

Still not sure if you guys are using PayPal Sandbox or not? In such case it can have something to do with it. PP Sandbox just uses internal emails and I am not sure yet how this possibly effect things here. Also, I found out an url apparently have changed at PP, were the PP Live has kept the old for backward compatibility, but the Sandbox not but I am still investigating into this.

Hi,
I'm not using paypal, I'm using COD

Guys,

email notifications are getting many trouble to us. there are dozen issues about it. i ll do a sprint on eC4 to fix all these issues ok? on eC3, its a Gordon territory (but i i fix on eC4, i will contact him to port the solutions)! hehe

regards,

massa

Working with ecommerce-5.x-3.4 here. Same problem.

has anyone worked out how to fix this? I notice the ecommerce dev. team aren't touching the older versions now and concentrating on the new alpha.

Any help or tips appreciated.

Phil

Similar problem.

Admin gets email on occasion.
Customer never gets an email unless a question is forwarded from the admin manually.

I'm using paypal with downloadable product, so the mail is very important for anonymous users.

Workflow sticks... won't transition to shipped. Won't transition from waiting on customer response.

Cancel and question states of workflow work.

Disabling lm_paypal seemed to make admins get email on completed payment.

I'm wondering if there are mods that don't play well with e-commerce.

Need help, would really like to use this mod.

How does 4 look from a stability standpoint?

Cheers,
Ron

re: workflow sticking.

Try running cron (http://www.example.com/cron.php) to see if that shifts the workflows forward.

re: email notifications.

I had the same problems as others. I wasn't able to work out why it wasn't working, but, I did find a patch for store.module and cart.module (for eCommerce 5.x-3.x) here:

http://drupal.org/node/193086

That patch sends an admin email on each sale automatically. It also allows you to switch single order notices on/off in the store settings page, which is useful.

See also: http://drupal.org/node/126523

I ran into this problem about emails not being sent.

I corrected it by uninstalling and re-installing the ec_mail module.

Please try doing that in your test environment and let us know your results.

Thanks,
DaveA

I have done a lot of troubleshooting with this issue. It seems to me that it isn't exactly a bug, it's more of a setup problem as a result of (in my case) not knowing that it is crucial to install the e-commerce core modules in the correct order, by ONLY enabling the Store module at first (I just checked all of them). I'm not 100% sure that was the cause, but it's my best guess, and if your email notifications aren't going out then it doesn't really matter what the original cause was, you just want to fix it.

I tried davea's fix above, several times in several different ways but it didn't work for me. So I delved into the code, and it took quite a lot of research for me to figure out what was wrong with my e-commerce configuration. For me, there were three things that were causing the emails not to work:

1. Not all of the necessary default emails had been created in the ec_mail database table.
2. The 'numrefs' for each email type was set to zero.
3. The mail id's (mid) for the emails were not correctly set in the variable database table.

So if you are having this issue, I am about to save you from having to go through the same five days of tearing your hair out that I just did. But you are going to need to directly edit your database so please, please, please BACKUP YOUR DATABASE before trying any of this!!! I can't guarantee that it will work for you, and it could conceivably damage your site. This is just what worked for me.

1.  OK, so the first thing you need to do is make sure that you have all of the necessary default emails. You can check them in Administer >> E-Commerce Configuration >> Mail. You'll want to keep that page open for Step 3 as well. If you are just using the core e-commerce modules, there should be four default emails in there:

store customer invoice (ECMAIL_TYPE_CUSTOMER_INVOICE)
store processing error (ECMAIL_TYPE_PROCESSING_ERROR)
store cancel transaction (ECMAIL_TYPE_CANCEL_TXN)
store ask customer (ECMAIL_TYPE_ASK_CUSTOMER)

You won't see the all-caps part in the mail page, I'm just including that for the fix in case you need to create those emails. Some other modules, such as Shipping or Coupon, should also have a corresponding default email listed:

shipping_notification (ECMAIL_TYPE_SHIP_NOTICE)
coupon (ECMAIL_TYPE_COUPON)

If there is another e-commerce module that you are using that should be sending an email out at any point, make sure that its default email is on this page as well. If not, you'll need to open the module file (eg shipping.module) and near the top you'll see a line that looks like this:

define('ECMAIL_TYPE_SHIP_NOTICE', 'shipping_notification'); (this one is for the shipping module).

You'll need the all-caps part for the fix. So here it is:

The Fix
Create a new page, and set the Input format to 'PHP code'. Make sure it won't be published or promoted to your front page, like I did on my live site. Give the page a title, like "reset default email" and paste this into the body:

<?php
ec_mail_reset_to_defaults(ECMAIL_TYPE_SHIP_NOTICE);
?>

That is the code you would use if you were missing the default shipping notification email. If you are missing a different one, change the all-caps part to the appropriate type for the email you want to reset. Now Preview the page. You remembered to set the Input format to 'PHP code', right?

One of two things can happen here: either it works, which is good, or you get a screen full of scary-looking error text that starts out: "SERIOUS ERROR! Your system is not functioning properly. Consult your system administrator and DO NOT, repeat DO NOT, modify any mail settings." and gives you a huge amount of error text as well. Believe it or not, this is ok, we'll fix the cause of this in the next step.

Now, if you have more than one default email missing, you'll need to press the Back button in your browser and repeat. I suggest using the Preview button rather than Submit because you don't want this function lurking around in your system because it could break things again if you ever access the page later on.

OK? Now on to step 2, which is where you need to get directly into your database. For most people this means using phpMyAdmin.

2.  This step is easy, assuming you're familiar with phpMyAdmin. You need to open your ec_mail database table, and for each entry in the table, set the numrefs to 1.

3.  Now open the variable table, and look for any entries in the name column that start with 'ec_mail', such as 'ec_mail_customer_invoice' and 'ec_mail_processing_error'. Next to each one, in the value column, there will be an entry like s:1:"6"; or i:2;. The first type means a string of 1-character length with value "6"; the second means an integer with a value of 2. You want to convert them all to the second type, and make sure the numbers are all correct.

So for each of these entries, what you want to do is find the correct value to have in the value column. You can do this from the Mail page from Step 1 -- just hover over the 'view' or 'edit' links, and the URL in your browser's status bar will include a number. For example, http://domain.com/admin/ecsettings/ec_mail/6/view -- the number 6 is what we want.

If you added extra default emails in Step 1, you will also have to refresh your Mail page to show all of the current emails in the system.

So let's say you are looking at the 'ec_mail_processing_error' in the variable database table, and let's say the "Processing error notification" email on your Mail page gives you the number 2 in the view or edit links. You now need to change the value in that database entry to i:2;. If it was a 6, you would make it i:6;.

Repeat that for each of the email types you have on your Mail page.

OK, you're done -- but BEFORE you do ANYTHING with your emails, or any other e-commerce settings for that matter, you first need to CLEAR YOUR CACHE. Otherwise you run the risk of undoing all of the fix-up you just did.

My preferred method to clear the cache is to install the Devel module and just click on the 'Empty cache' link in the Devel block. But there are other methods as well: http://drupal.org/node/17620#comment-856035

That's it! Now run some test purchases and hopefully it all works. Let me know if this helps you!

Arvana

subscribe