Support

June 16, 2020 at 3:06 pm

Hi Matt,

The short answer is we recommend using a transactional email service such as the one listed here:

https://eventespresso.com/wiki/postmark-app-mandrill-transactional-email-handling-services/

99% of the time these issues are caused by the mail server in user and the mail either being dropped, or marked as spam.

When EE sends an email it builds out all of the content etc and then passes it to wp_mail() to do whatever your server is set up to do with the emails.

You mentioned the messages show as being sent, so they have a green ‘status bar’ (the coloured bar to the left of the messages) in Event Espresso -> Messages -> Message activity?

If so then as far as EE is concerned everything worked as expected. The email was triggered, generated, packaged up and passed to wp_mail(), none of which returned any errors.

Think of that as a physical letter which was written, folded, sealed in an envelope and then placed in a post box without it being lost, shredded or incinerated and your now waiting for it to arrive.

The fact that it isn’t arriving in the mailbox generally means the email is being flagged as spam somewhere along the way and being dropped after it sent.

Are you using a mail service/SMTP plugin on the site currently or just sending mail through your hosts phpmailer?

June 16, 2020 at 3:22 pm

understood and generally agree. However- I have tested on multiple email platforms and NONE receive it in inbox or spam.

Problem is, it depends on the mail server and what is actually happening with the email as to whether or not it’ll land in the spam folder. For example, let’s say it’s flagged as spam with a risk rating of 4 but the server deletes any with a value of 4+, the email won’t land in your spam folder the sending mail server just dropped it (admins set this up to try and prevent the server being blacklisted).

To be honest, the quickest way to test it is to sign up to one of the free tiers on the services mentioned and see if the email arrives with no other changes other than using that service. If it does, it was the mail server used prior, if not then there’s more troubleshooting you can do but it’ll involve getting the host involved to check what the emails are doing.

However, when a form is filled out on site the form notification gets to my inboxes no problem. I know its a different application BUT it probably sends it the same way EE does.

I wish it were that simple.

The form may (or may not be) sending as plain text, if not and it’s actually sending a HTML email, then it can often depend on the content of that email. We use a HTML template which (by default) contains multiple links and plenty of HTML/CSS so if the form email is simply some P tags and a bit of text it passes through fine, a bunch of HTML, links, tables and CSS isn’t the same thing. Now obviously I have no idea what content is included in the other form’s email but they usually don’t contain the same amount of HTML EE emails do.

June 16, 2020 at 3:43 pm

Right – except if its a mail provider problem then you guys need to have a way to make them adjusted to be received better by email platforms. The application has a serious issue if notifications by default aren’t easily received by any platform. I have many other application like WooCommerce, Gravity forms etc… which all use the default method of sending notifications and hit customer and the common email provider accounts no problem.

It’s not just about the receiving mail server but also the one sending. We could switch to plain text emails like some of the above, but then most will complain about the lack of styling but as mentioned, it’s not something you want to debate over and that’s fine.

I dont want to get into a back and forth debate about email provider spam filters and security settings and who to point the finger at since that doesn’t help us move towards a solution.

I’ve already given you a solution, use a different mail server.

Is there a way to troubleshoot and determine if notifications are leaving before integrating a 3rd party solution as the only answer and placing blame on email providers or hosting?

If the email was passed to wp_mail(), and wp_mail() didn’t return false, then as far as WP and EE is concerned (and has control over) the email sent without an issue.

You can install something like WP Mail logging to view the content/errors for every email sent from the site, although again that relies on wp_mail() returning something other than true to indicate a problem.

June 17, 2020 at 4:54 am

” will complain about the lack of styling” – nothing to do with it. I have ecomm receipts with much more heavy inline CSS stying than your notifications and have zero issues on shared hosting using the wp(mail) function.

May I ask which ones? I’ll take a look and compare to see what the difference is.

I simply would expect more from premium support to troubleshoot and help identify problems (if they exist) before simply pointing fingers. If it isn’t with EE thats fair but we should be capable of confirming that fact first and point fingers second. This is a premium app that we pay a lot for and for multiple projects.

I’m sorry you feel I haven’t dug deep enough into this. However, as mentioned above everything EE did to send the email has come back with an ‘ok’ and shown no issues. So within EE (which is what we support) and up until the point that the email has been passed to your server to do whatever it is set up to do, everything works.

The email triggered within EE as expected.

EE generated the email with the various data needed without issue.

EE passed it over to wp_mail() which does it’s own processing and then does whatever your server does.

None of those steps returned any errors, that all worked as expected.

So to use my letter analogy from| earlier, you’re asking me to figure out why the delivery van/truck/plane/jetski broke down in transit after it was picked up and it’s simply outside of what we have control over.

The ‘official’ response would be it’s outside of our control/support and to contact your host to have them troubleshoot why mail sent from their server is not returning any errors yet apparently never arrives. The usual response (yes we’ve recommended users do exactly the in the past) is that they don’t have any control over the email after it’s left there servers and so is generally a waste of time, although not always. Even troubleshooting the issue with your host and if they specify the exact line/block of code causing the issue (very very unlikely they will) doesn’t get you up and running quicker than using a transactional email service does.

I did not simply point the finger and leave you to deal it but explained what the likely cause was an offered a solution. We recommend using a known good transactional email service, which I understand you don’t agree with, but is our current recommendation. If it doesn’t work after that then at least those servers have additional information to troubleshoot further, which right now, you don’t have.