[Résolu] CRED Post Form Emails Not Sending

[Auteur]

Publications

[julieP]

Hi Beda

I've given you a link to the images this time - hopefully you can see them now.

In response to your comments, there are no cc or bcc in the notifications, you're forgetting that Minesh & Waqar also submitted the form, the site was a test site and already a fresh install with minimum plugins, no SMTP plugin was used; only native wp_mail(), there are no IP blockages, the restrictions are based on country and yes this is a safety mechanism. No I wouldn't be happy to lift this; a test site is no less important than a live one and doesn't affect your access to the site once I have put the necessary things in place.

I could go on but actually overnight, there has been a development in that Litespeed have advised the following:-

This issue stems from the way in which some browsers using HTTP2 handle redirects and also from the way in which submissions are handled by Toolset. It effectively spawns a background PHP processes to handle the submission and then immediately redirects the user to the "success" page. Depending on the device/browser, the HTTP connection to the background process is terminated and as a result, LiteSpeed considers the process 'abandoned' and consequently aborts it mid-execution (this would explain the half-written log files & sporadic notification behaviour).

The solution proposed by Litespeed was to disable LiteSpeed's abandoned process management by adding this rule to .htaccess:-

RewriteEngine On
RewriteRule .* - [E=noabort:1]

I've tried this on all my sites and can confirm that notifications are now sending correctly.

I do hope you don't just simply write this off now as not a Toolset problem because the fact still remains that this issue only appeared when CRED was upgraded to 2.1.2 and the issue isn't present when using any other forms plugins.

[Beda]

Hello Julie, thanks for the reply.

1. It effectively spawns a background PHP processes to handle the submission and then immediately redirects the user to the "success" page

So this happens only on a success redirect and only on certain browsers.
Does this maybe explain why my email went thru?
The form was indeed redirecting to the success message when sent, but I tested on Google Chrome, my default browser.
My apologies if it was clear to not use that browser, I must have missed this.

2. Without access to the site, I cannot test this anymore.

3. I can inform our developers about this but they will say the same as me. Without access to the site, we cannot test this.

4. this issue only appeared when CRED was upgraded to 2.1.2

I would also need and like to confirm this before I can ask the developers to fix something, I am sure you understand.

I do not know how to set up a LiteSpeed’s HTTP2 or HTTP2 + QUIC (http/2+quic/43) server, but I can ask our Developers if they do.

Please stand by, so I can clarify if, and if they can then set one up so we can test, fix and ship the adjustments if required.

Please forward also my thankfulness to the Server Admin on your end who debugged this, and I offer my apologies for not being of any help here.

I also requested access to the screenshots folder, so I can look at them.

Thanks for your patience!

[julieP]

Don't know what happened with the link; I had set it up to share with anyone with the link. You should have access to the folder/images now though.

HTTP2 and HTTP2 + QUIC (http/2+quic/43) are not types of Litespeed server; they are protocols and are device dependant (not browser dependant). I provided screenshots of developer tools earlier in this ticket to show Minesh. Just to complicate things, you can get Litespeed servers running Apache with mod_lsapi. This is the cheap way of providing Litespeed but doesn't appear to cause an issue. It's to do with using Toolset forms with Litespeed webserver (LSWS).

I advised the issue was related to CRED 2.1.2 back in November (see this ticket https://toolset.com/forums/topic/email-notifications-not-working-since-update-to-cred-2-1-2/).

Yes, my hosting provider has been nothing short of brilliant. I think your developers need to troubleshoot this alongside a server expert. You'll find all the information I've been able to provide in the contents of this ticket. If your developers need more info in order to better understand the server environment, I can ask my hosting provider if they would accept your developers contacting them.

[Beda]

Thank you for this additional information, I also got the screenshots permission now.
I am talking today to developers, and will then feedback to you.

[Beda]

Is it possible to get direct contact to the hosting provider's developer who debugged this, please?

Then we can talk to each other directly and make sure this gets addressed.

I'd need email and name, if possible

Thanks!

[julieP]

Hi Beda

My hosting provider is happy for you to contact them. As this is a public forum, please enable a private field for the details. Thanks

[Beda]

I thought I enabled it.

I re-enabled all kind of private sections now, please ignore the ask for WP Access and similar

Thanks!

[julieP]

<secure form did not work>

[Beda]

I will keep you in the loop.

I immediately after your reply removed the content as despite all it seems something is wrong with the private reply.
However, since I reacted immediately no data was exposed.

Thanks for your patience.

[Beda]

I have contacted the hosting provider and will update here when we have news.

Note, I needed to ask him for additional help which may seem obvious to you or anyone else familiar with such server setup in general.
We are very familiar with Plugin Coding, but less with setting up a particular server or/and protocols.

I am sure with the help and information of your host provider and our own coding expertise we can solve this problem.

[Beda]

Hi there

We managed to set up such server and with HTTP2 device, we cannot replicate this problem, which also was shown on the site you provided in past.

Instead of bothering you with more details, I already updated your Server Host as well with this and offered our logins to the server we did set up so we can work on this together and find out what is wrong.

On our test site, everything works fine with the mails on the form that redirects to a success page, and we also tried many other settings, just to be sure.
We even use cache, to make it less easy for Toolset.

However, maybe you can ask your Hosting Provider if he already got my email (as I did not yet get a reply, but I do also not mean to stress!!)
The mail was sent to him from an email of OTGS, starting with my name as seen here:
https://toolset.com/forums/users/beda-s/

[Beda]

I received a reply from the host and it does seem to confirm what I suspected and stated previously.

The number of affected devices/browsers seems to be quite low, we were only able to reliably produce the problem on one MacBook (Chrome, Firefox and Safari were all affected, so it could even be an OS level TCP/IP or TLS issue) and Julie's Windows 7 PC.

When we contacted LiteSpeed regarding the issue, they found that LiteSpeed's process aborting was responsible and simply disabling this feature ("noabort" .htaccess flag) allowed the form to POST successfully. Our general theory is that certain browser versions of HTTP2 implementations were prematurely ending the HTTP2 connection, causing LiteSpeed to abort the execution of the PHP process when they're redirected to the "success" page.

I haven't had the opportunity to compare LiteSpeed configurations or test Julie's site on a different server as she was satisfied with the fix (noabort).

Further, your Host is inquiring about our own test environment and I am in close contact with them now to clarify every doubt and make sure, this issue gets either replicated and solved or declared as an exception in either device, browser or even server.
The tests are still ongoing on our end as well, to be sure we catch every single chance and detail.

Currently, I recommend (as the Host) to either not use success redirects (which is the less desired) or simply leave the rule in the .htaccess to resolve this exception (it is an exception because not clearly replicable yet).

We will of course not stop here, in case we cannot confirm the issue we will make sure to have covered every single possible replicable scenario.

[Beda]

I am clarifying a few last details but it looks like this issue is not replicable steadily on other devices/servers.

I am awaiting a few more details From your Host, to confirm this.

[julieP]

Hi Beda

I really appreciate you keeping me in the loop, thank you. I hadn't actually received any notification via email about your updates to this ticket over the past few days; I simply noticed it had been updated when I logged in to the forum.

I have just one question; you mentioned recommending "not use success redirects (which is the less desired) or simply leave the rule in the .htaccess". By success redirects, do you mean redirects after form submission?