Home › Toolset Professional Support › [Resolved] CRED Post Form Emails Not Sending
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
- | - | 14:00 – 20:00 | 14:00 – 20:00 | 14:00 – 20:00 | 14:00 – 20:00 | 14:00 – 20:00 |
- | - | - | - | - | - | - |
Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)
Tagged: Content-submission forms, Toolset Forms
Related documentation:
This topic contains 63 replies, has 4 voices.
Last updated by Beda 5 years, 8 months ago.
Assisted by: Beda.
My test site is locked down using an IP ACL. Please provide IP addresses for those who need access then re-enable private field for access credentials.
Thank you
Hello JulieP,
This is Minesh here and I'll take care of this ticket and try to help you further.
It looks like this ticket is become story and to go through it, it will be really hard as this already ended up in three page story.
Would you mind to create a fresh ticket and we will be happy to give you support and debug your issue further to check if issue is within Toolset or somewhere else but I would recommend you to open a fresh new ticket where you can share all required details.
If you still want to continue with this ticket, let me know. I'm setting up next reply as private. Please share all required information.
In addition to this, have you update ALL Toolset plugins to it's latest official released version.
I have negotiated with my hosting provider setting up a temporary site for you to visit and access details have been provided in the private field.
All plugins are up to date using last night's release of Types & Access.
Please ensure you view the video I provided a link to in this private message https://toolset.com/forums/topic/cred-post-form-emails-not-sending/page/2/#post-1200853. This provides evidence that CRED is not always sending emails on form submission.
I have some additional information for you.
My hosting provider has been doing extensive testing themselves and has identified a potential issue with LiteSpeed's HTTP2: devices that use HTTP2 (h2) experience the issue reported but devices that use HTTP2 + QUIC (http/2+quic/43) appear to be unaffected (my device uses HTTP h2).
This potential issue is affecting Toolset forms but not other contact form plugins so would you please pass this information on to the developers so they can look into this (Luo said he had escalated this matter). Thank you.
Thank you for sharing this additional information.
However - the access details you shared with your last reply here is not working:
=> https://toolset.com/forums/topic/cred-post-form-emails-not-sending/page/3/#post-1202837
When I try to access the link - I see the following message with a while blank screen:
Sorry, your request cannot be accepted.
As you are able to locate the issue and issue is from the http2:
Is it possible for you to setup a simple test site with your server hosting where we can see the issue? It will be great if you can share simple test site where we can see the issue with Toolset forms and once you share that details I will share with our Devs to look at it as this requires specific server setting which you already have on your server.
I have set the next reply to private which means only you and I have access to it.
I did advise you that the site has country blocking enabled. I suspect you are located outside GB or US? Please provide your region code so I can whitelist it and then you'll have access.
I will ask my hosting provider what they can provide to demonstrate the http h2 issue. But you can actually demonstrate this yourself on my test site by submitting the form using a device that uses HTTP2 (h2) and then again with a device that uses HTTP2 + QUIC (http/2+quic/43). You will see then for yourself that emails are not sent when a CRED form is submitted using a device that uses HTTP2 (h2) protocol.
In the meantime, please ensure you watch the video I provided previously here https://toolset.com/forums/topic/cred-post-form-emails-not-sending/page/2/#post-1200853 which demonstrates the issue (the device used there uses HTTP2 (h2)).
You are welcome to install a competitor's contact form plugin to test their form/s using the two devices so that you can see that emails are sent from their forms by the device using HTTP2 (h2) AND by the device using HTTP2 + QUIC (http/2+quic/43).
Thank you for details. My IP is: 103.85.90.4
Thank you I checked the video and based on that I can see the emails are not sent.
I would like to again double check - Is the site access you shared is live site or test site?
Well - we have distributed team and few other people outside the EU zone. It will be great if your hosting authority can provide to demonstrate the http h2 issue with a test site.
Hi Minesh
Thank you for looking at the video.
I can confirm the site is a test site.
I need to use just one method to keep away unwanted visitors & allow wanted visitors (you, me and other Toolset support staff). I can use either individual IP addresses OR the country blocking plugin; there is no sense in doing both as I would then need both your IP address AND your region code. My preferred method is to use IP addresses and de-activate the country blocking plugin but this only makes sense if everyone who needs access to the site can provide an IP address. Please advise which method you prefer (if it's IP addresses, I have all I need until anyone else at Toolset wants to take a look - if it's country blocking, you need to tell me what country you're in so I can find the correct region code to whitelist).
The potential issue with http2 (h2) is happening at server level but is only affecting Toolset forms (not forms created by other plugins) which is why you guys need to be looking into this.
As I said before, the only way you can test & replicate this issue using my site is to submit the form using one device that uses http2 (h2) and another device that uses http2 +QUIC. In the tests my hosting provider carried out using a Macbook (which used HTTP2 h2), the emails failed to send from a CRED form. When they used a desktop PC (which used HTTP2 +QUIC), the emails were successfully sent from a CRED form. Maybe I'm not doing a very good job at explaining this but I don't know how else to explain this so if it's still not clear, you might want to discuss this with say Nigel or Christian??
If you test this on your own install & environment (with the different devices), the Litespeed server needs to be using LSWS (Litespeed webserver) not Apache + mod_lsapi.
Well - can you please allow country Egypt and India.
Countries whitelisted now - please try to log in again
Hello Julie, I have sent an email with the form in question, the email was successfully sent, you can see it in the logging screens (it's the one with s.mail.beda)
I see hence no issue in this server/site/form, but I am probably missing something.
I see that the thread is 3 pages long and I have read thru it in its entirety but could not find anything that I missed.
You probably know that we at Toolset have solved similar "long" issues in past - please rest assured I will commit as always also here to resolve this problem as fast as possible. One such example of a long thread is here (from another user):
https://toolset.com/forums/topic/wp-all-export-pro-cron-job-to-hit-cron-url-not-working-unless-i-deactivate-types/
But, right now, I am not able to see the issue on your site.
Please apologise for my asking:
- precise link where to use the Form if different from what I have (hidden link)
- precise instruction as of whether I shall do that as logged in, logged out, or any other user than admin
- a precise explanation as of what is happening and what is expected (is the email always logged but not sent? do I need to make adjustments to the server to see the issue? other points to consider?)
I have made sure to follow the report of the Support Personnel to the letter, and as you will see in this page, my email went thru with no issue!
hidden link
Once I have precise information and steps, I will be able to detect and solve the issue in a reasonable time. Please accept my apologies that you already have been investing lots of time in this ticket and our Support could not follow up with solutions. Let me change that, I hope, within the next reply.
I activated all sort of private reply in case you need to share private data.
I am already able to connect to the site even I am from Malaysia/Thailand, however, I do not see that Minesh asked you to open the site for those countries. Does this mean the site is now open for all countries?
Beda,
Screenshots uploaded - please see next reply for further details
Hi Beda
Thank you to you, Waqar and Minesh for running your own form submissions on Friday although I'm disappointed that the three of you haven't discussed your findings.
I've provided answers to your questions below. Please also consider watching the video I provided for Luo here https://toolset.com/forums/topic/cred-post-form-emails-not-sending/page/2/#post-1200853
Does this mean the site is now open for all countries?
No, it's currently only open to GB. Whoever logged in to the site (Minesh??) added other region codes to the plugin settings (I removed them once it was clear you guys had stopped testing).
I can confirm you have used the correct form on the correct page (there is only one) and using it as a Guest is fine (makes no difference whether you're logged in or out).
a precise explanation as of what is happening and what is expected
The form is set up to send 3 notifications; one to the site admin, one to a hotmail account and the third to the email address provided by the user completing the form (meaning there should be 3 emails per form submission, i.e a total of 30 for the 10 form submissions made by you guys).
The notifications are not always sent from CRED i.e. the message post is created but the email data isn't always sent to the email processor. This isn't an issue of emails not being received; they are not being sent in the first place.
I have taken screenshots from the test site; one of the 10 message posts created, one of the email log entries created by the plugin you guys installed and one of the 'track delivery' page in cpanel. The numbers on each correspond to the message numbers I added using Photoshop so you can see where emails were not sent. The email log isn't actually 100% accurate as it only shows 7 emails being sent whereas in fact 13 were sent as can be seen from the server log (should have been 30). You'll notice that of all the form submissions made, emails were missing from Minesh's and Waqar's; only yours sent all 3.
My server is using Litespeed webserver (not Apache + mod_lsapi) and my hosting provider suspects there's a bug with LiteSpeed's HTTP2 implementation because in their tests, emails were sent when using a device using HTTP2 +QUIC protocol and not sent when using a device using HTTP2 H2 protocol (which is what my device uses).
This is however isolated to Toolset forms; whenever I use a competitor's contact form plugin (Formidable Forms, Ninja Forms and Form Maker), all emails are sent. This is why you guys need to be looking into this your end too. If I set a Toolset form to expire however, the emails are sent (and this makes sense if my hosting provider's suspicions are correct).
Unfortunately, no screenshots reached me.
However, please let me reply to your comments.
1. No, it's currently only open to GB. Whoever logged in to the site (Minesh??) added other region codes to the plugin settings (I removed them once it was clear you guys had stopped testing).
I apologise, I did not know this. I really apologise for this to happen and can guarantee that I would never just add other countries to your server if you do not permit me so. I had asked Minesh to ask you to add Malaysia and Thailand because I work here and I wanted to take a look, hence I safely assumed, this will be discussed with you, by Minesh.
I apologise if this has generated safety issues on the server.
From now on, only me will work on this problem and for that to happen I need to access the site. I am currently in Thailand but I use often a VPN situated in Malaysia so, if it is possible to add those 2 countries, I would be able to see the site again.
2. I can confirm you have used the correct form on the correct page (there is only one) and using it as a Guest is fine (makes no difference whether you're logged in or out).
I used that form as an Admin (with the login details I got from Minesh for this ticket).
3. The form is set up to send 3 notifications; one to the site admin, one to a Hotmail account and the third to the email address provided by the user completing the form (meaning there should be 3 emails per form submission, i.e a total of 30 for the 10 form submissions made by you guys).
I made only one submit of the form, and I saw later that it sent the email to the email I provided in the form's email field, and 2 more.
Hence, all should be fine.
4. The notifications are not always sent from CRED i.e. the message post is created but the email data isn't always sent to the email processor. This isn't an issue of emails not being received; they are not being sent in the first place.
They are sent, the email logging plugin shows this. If you mean that the end-receiver has no email in the inbox the issue is within the server (after whichever service used on the site intercepts the email and sends it further, if there is any such service)
The mail logger cannot log the email if it's not sent.
5. The email log isn't actually 100% accurate as it only shows 7 emails being sent whereas in fact 13 were sent as can be seen from the server log (should have been 30).
CC and Blind copies are usually not logged by the loggers, only the "to" emails are logged.
6. If the server admin suspects a BUG in the server, then Toolset Forms just "shows" that bug. This happens often. For example, a plugin can produce an error, that in fact is hidden in another software, but is shown because the plugin uses something that triggers that bug.
It is hence then not the task of the plugin to fix this but of the software holding the bug.
Now, I want to solve this for you.
Can I request (along with offering again my apologies for the previous mistakes done here):
- access to the site in question or even better, access to a "5-minutes" install of WordPress and Toolset Forms, on the same server?
(A 5-minutes install on the same server, with just Forms and WordPress and a native theme, will exclude any other interference). This is set up fairly fast. It, however, needs to be on the kind of server you mention.
- this includes, that I am whitelisted on the site in question (Thailand, Malaysia)
- the link to (if on a new site) the new form in question and a link to the form in question in the backend where I can also see to whom precisely this email should be sent to.
- I ask permission to re-upload the mail logger and to send emails in test purpose.
I will then confirm the issue, and eventually create a custom plugin, that uses native wp_mail() to trigger an email.
If that does not work as well, the issue is within the server only. If it works, then we need to find what exactly toolset forms is triggering to make the bug (which is suspected to be in the server) happen. All we could do later is to inform the server admin what to fix or report. We could not solve this in Forms if the issue is within a bug in another server or software; I am sure you understand this.
That is summarized the reason why it would be good to have this on a testing site (not a live site)
I think the site you provide is a live site and would prefer not to upload custom code there, to test.
I can see that you mention it is a testing site here: https://toolset.com/forums/topic/cred-post-form-emails-not-sending/page/3/#post-1204284
However, I must ask, why then the IP blockages? Is this just a generic safety protocol that could be lifted for this one test site?
If it holds no content, you could protect the form with Toolset Access and simply not let anyone but logged in users see it.
That would make it easier to access.
It is of course up to you, I am happy with the current site as well, if I can make any change required, upload custom code, and eventually break it (I hope not).
Thank you for your understanding.
I hope that we can find a solution ASAP.