|
TEEGAdmin
|
April 17, 2019 at 8:27 pm
Greetings,
We recently set up Cloudflare to speed up our site. Since then all emails generated for event registrations are arriving to registrants as unformatted HTML (code).
Emails sent from within the admin are arriving properly formatted. This problem is only is occurring from the public facing site submitted froms.
This problem is only happening with Event Espresso email and none of the other plugins such as Contact Form 7.
Any help would be greatly appreciated. I have searched threads here but not found anything that solved this.
TEEG admin
|
|
Tony
|
April 18, 2019 at 7:33 am
Hi there,
If you go to Event Espresso -> Messages -> Message activity
Are the emails shown correctly or do they show the HTML version?
Generally, when emails are shown as plain text it’s because they are being marked as spam as some point along the way, to prevent that we recommend using a transactional email service and have some listed here:
https://eventespresso.com/wiki/postmark-app-mandrill-transactional-email-handling-services/
|
|
TEEGAdmin
|
April 18, 2019 at 10:54 am
Hi Tony,
Thank you for your input.
The messages in activity show up properly formatted. Also templates test sends arrive properly formatted.
The messages are not being flagged as spam. Messages / notifications to both registrant and admin arrive un-formatted.
So to reiterate, the messages are only sent un-formatted when triggered by a registration. No problem with anything sent from within WordPress admin.
We are using Rackspace third party hosted email service MX. It’s my opinion we should not need to install yet another plugin and service to get this solved.
Our Cloudflare is the free variety and we have W3 Total Cache installed with the correct page exclusions set up as per Event Espresso instructions. Web hosting is Gator shared.
Anything else we could look at?
Thanks again,
TEEG Admin
|
|
Tony
|
April 18, 2019 at 2:24 pm
The messages are not being flagged as spam. Messages / notifications to both registrant and admin arrive un-formatted.
Meaning they are likely being set to plain text, which can happen if the mail server suspects its spam. The formatting for the email is inline, so if the email arrives and the Content-Type has been set to text/plain some email clients try to parse HTML if they detected it (usually doesn’t work to well though), others simply display the content as is.
Is there an event I can run test registrations on to trigger the emails and view this?
So to reiterate, the messages are only sent un-formatted when triggered by a registration. No problem with anything sent from within WordPress admin.
I understand that, but as far as EE is concerned, there’s no difference between those.
We are using Rackspace third party hosted email service MX. It’s my opinion we should not need to install yet another plugin and service to get this solved.
EE doesn’t send email itself, it passes them to wp_mail to do whatever your server is set up to do with them. So if EE emails worked before Cloudflare was installed, but now don’t because Cloudflare has been installed, then logically something within Cloudflare is causing an issue, but there’s nothing within EE that changes with/without Cloudflare installed so I can’t think of anything other than a mail server issue.
As the emails show correctly in the mail activity log they aren’t being mangled by EE before being sent, that output is captured just before sending over to wp_mail, but you can also confirm that using WP Mail logging plugin should you prefer, that captures the content of the email right before its passed over to the server by hooking into wp_mail and is completely outside of Event Espresso.
|
|
TEEGAdmin
|
April 19, 2019 at 5:41 pm
Hi Tony,
Thank you for your detailed reply. Unfortunately I don’t have something for you to test. Stripe is in live mode. Due to the need for the registration emails to be working right away, the website owner has elected to turn off Cloudflare so I’m not able to troubleshoot this to a conclusion at this time.
Before continuing I wanted to mention it would handy to be able to have sandbox mode per event. I have an add-on for Contact Form 7 Stripe add-on that I can do this with. I set up Stripe globally but can override test mode per form.
Anyway, I am doing some tests on another account. My plan is to use EE Decaf with W3 Total Cache and Cloudflare. I’ve also installed Mailjet so I can test with that turned on too. The only missing part of the equation will be the Rackspace server. Email formatting from Decaf should be the same as from our premium EE so perhaps I can get this figured out from this secondary site. Many moving parts and dealing with Cloudflare forum for help is a last resort.
Additionally, with Cloudflare turned off on the problem account, there’s still the possibility something else may turn out to be the culprit, like W3 Total cache for example. If possible I’d like to keep the thread open for some time while I tinker. Whatever my findings could be helpful to others.
Thanks again for your help,
TEEG Admin
|
|
TEEGAdmin
|
April 21, 2019 at 4:28 pm
Hello again,
So I did my testing from another account. I used EE Decaf, W3 Total Cache and Cloudflare but used a free event and no Rackspace email server.
I had the same problem with emails.
Using MailJet does solve the problem.
It would be nice if another plugin and service was not needed but at least there is a way to get it working with Cloudflare.
Thanks for your help Tony,
TEEG Admin
|
|
Tony
|
April 23, 2019 at 3:27 am
Before continuing I wanted to mention it would handy to be able to have sandbox mode per event. I have an add-on for Contact Form 7 Stripe add-on that I can do this with. I set up Stripe globally but can override test mode per form.
You could do this with the Payment Methods Pro add-on which basically allows you to create ‘instances’ of a payment method and then select the instance on the event.
So you could create a Stripe debug instance and have that enabled on test events.
Additionally, with Cloudflare turned off on the problem account, there’s still the possibility something else may turn out to be the culprit, like W3 Total cache for example.
Just to note for future users, whilst it’s possible for W3TC to cause issues, we’ve seen many sites using W3TC without this issue, so unless you changed something specific to emails that isn’t normally set (which iirc W3TC doesn’t have options for) I think this would be unlikely.
So I did my testing from another account. I used EE Decaf, W3 Total Cache and Cloudflare but used a free event and no Rackspace email server.
I had the same problem with emails.
Using MailJet does solve the problem.
Is this on the same server? Just a different/staging domain?
It would be nice if another plugin and service was not needed but at least there is a way to get it working with Cloudflare.
You could work through and find the issue with the mail server if you prefer not to use another service.
|
|
TEEGAdmin
|
April 23, 2019 at 3:26 pm
Hi Tony,
We installed ‘Payment Methods Pro’ and it looks like it will be useful for debugging but I should have stated our case more clearly. We have a Stripe account for our business and a different one for joint venture events. So, we need to able to connect to different Stripe accounts for different events. I don’t see anywhere in ‘Payment Methods Pro’ to add different keys for a different account which I can do with the Contact Form 7 plugin.
Ideally, we’d be setting up 4 Stripe accounts. One live account for each of our two Stripe accounts and one testing / debugging account for each of our two Stripe accounts. With the Contact Form 7 add-on, we can enter a Global account then override each account with live and sandbox settings then toggle whether we are live or testing per form. Very useful. Am I missing something in ‘Payment Methods Pro’? There appears to be only place you can enter keys for ‘live’ payment processing in the first set up. Addition ones have a connect button but that’s it.
Re: W3 Total Cache – It doesn’t seem to be related in any way.
My tests were done on a different website of ours on the same hosting account (add-on domain) at Gator.
Thanks again for your help,
TEEG Admin
|
|
Tony
|
April 24, 2019 at 2:43 am
There appears to be only place you can enter keys for ‘live’ payment processing in the first set up. Addition ones have a connect button but that’s it.
We switched to use Stripe connect a little while ago to make it easier for users to link their Stripe accounts so your current Stripe payment method used the ‘older’ method using the API keys and now new instances are using the ‘new’ method.
However, you can force the Stripe add-on to display the key fields using this snippet:
add_filter('FHEE__EE_PMT_Stripe_Onsite__generate_new_settings_form__hide_key_fields', '__return_false');
That should allow you new Stripe payment methods to use keys.
|
|
TEEGAdmin
|
April 24, 2019 at 10:48 am
Hi Tony,
As long as they connect to the correct account, it doesn’t matter whether we can see the keys. Smart move removing this burden on the staff. I do more heavy lifting type things for them because my tech knowledge is wider. They do the connections and I wasn’t aware of this change.
So we can do what I described. We now have a live connector for each account and I set up two new ones in debug mode so we do testing for both Stripe accounts.
Finally we can test the email formatting with MailJet.
Thanks again for your help. I’ve learned some great stuff through your help.
Regards,
TEEG Admin
|
|
Tony
|
April 24, 2019 at 3:47 pm
You’re most welcome, happy to help 🙂
If you’d like for me to run a test registration at all just post up a link to an event I can use an I’ll see if anything stands out (You can post the link in a private reply if preferred).
|
