A new project had just came in so we needed to set up a staging instance. I gathered all the files needed and double checked that the store works. As I thought at the time- instance set up was done.
Client contacted us and said that he had received several emails about unfinished purchases in store. It was one of the first support projects for me, so it didn’t come to my mind that emails would be sent from the development instance.
I changed the default recipient to my own email so that if something would be sent about not completed purchases, it would be sent to me.
So that’s it, right?
I made one more test purchase in the staging instance- client received another email. (!!!)
As a first thing, System->Config->Store Emails were changed, but this did not gave the necessary result, we got a ping from the client, that e-mails were still sent.
It would not be safe to just change outgoing e-mail server, as Mandrill (and other 3rd party mail services) may be used via API calls. The best option is to understand what sort of e-mails were sent and how it is triggered, but sometimes it may consume more time than we have to fix it now.
After a consultation with other teammates we found the issue. Not to bore you with unnecessary details, here is the short version: taking into account that client received a notification about unfinished checkout — it may be done via some custom API call, so BOTH: e-mail channel and mandrill should be disabled.
What is the best solution then?
Just pay attention to the details: what type of e-mails were sent, were from these were sent — it will help you a lot to determine which extension should be disabled / functionality limited to achieve a necessary “ether silence”.
Author: Uvis Štrauss, Support developer
Article is a part of Support Stories series, new story every Tuesday and Thursday. Stay tuned.
We post regularly, don’t miss out: FB.com/Scandiweb