Leah

Exactly what I was looking for, so cool. ?? Thank you!

Awesome, thanks for the quick fix!

@joshuabaer23 @pgsvensk

As stated above, this is an issue with the endpoint that the plugin is trying to reach. For both of you, it sounds like this is your CRM.

If you’re getting this error every time, you’re likely using the wrong endpoint (Submission URL field in the plugin settings). I’d suggest reaching out to your CRM and asking them what the appropriate cURL would be to use with a 3rd party API.

If it only happens occasionally, the endpoint timeout might be set too low. This is set by the 3rd party CRM or service you’re trying to connect to (not the plugin), so you don’t have a whole lot of control in this regard. It could realistically be caused by a number of things, but most likely just a brief spike in yours or your CRM’s server load at the time of the submission that caused it to hit the set timeout limit. You can ask your CRM if they can increase the timeout limit, but if it’s only an occasional occurrence, it’s probably less of a hassle to just manually re-submit these submissions as they come in.

If it happens quite often, but not all the time, you probably have an issue with your server load. Consider reaching out to your host to increase your memory or see if there are any long-running processes on your server that are eating it up.

• This reply was modified 7 years, 1 month ago by Leah.

Hey @jayk1, for debugging mainly.

While I’m testing with 3rd party components at play, I try to be as lenient with my code as possible, so that if something does go wrong, I can be sure that it’s a problem with the code itself and not some external force (such as the mail server).

The other reason is because I want our leads to still be redirected to our Thank You page in the event that something does go wrong with the mail server (as opposed to to just getting hung up on the form submission page and seeing an error message, not a great user experience). I know I could just write two event listeners, and I still might once I’m confident that everything is working as expected, but for now this just makes troubleshooting easier. ??

Also, sorry @johnja1, I completely missed your reply!

Firstly, if you’re going to use the code the way I did it, you’re actually going to want to put it in the footer, not the header. document.querySelector is looking for a specific object in the DOM (in this case, the ID #cf7-custom-container). If your script runs in the header, the DOM will not have propagated yet, which means #cf7-custom-container doesn’t exist yet and your formStandard variable will be empty!

Secondly, #cf7-custom-container is an ID that I added manually to my form container. You’ll either have to add that same ID to surround your form, or modify your code to select whatever container you have surrounding the form on your page that you want to add the DOM event to.

Hope that helps!

Awesome, thanks Damian!

For the record, uploading a previous version of an already-installed plugin will not overwrite the existing plugin. You’ll just get an error upon upload saying that a plugin with that name already exists.

To fix this issue, simply append !important to the end of your CSS declaration, like so:

span.wpcf7-list-item { display: block !important; }

Hey AJ,

Try [your-name] <[email protected]>

If that doesn’t work, it could also be the top-level domain you’re using.

• This reply was modified 7 years, 5 months ago by Leah.

For future reference: There’s a “Delete All” button at the bottom of the 404 log page.

This turned out to be a conflict with modsec. I reached out to our host and they resolved the issue.

I recently got this error as well. I believe it actually has to do with the third party service (CRM?) that you’re trying to post data to.

This plugin looks for a request from whatever endpoint you give it in the settings. If it can’t reach that endpoint before the timeout period, it will return that error to you.

Hmm, this is the only thing I found in my staging logs:

[23-May-2017 20:40:24 UTC] PHP Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 24576 bytes) in /wp-includes/wp-db.php on line 1841

I can’t imagine that being from the form content, though, unless I guess it was a long-running process due to the form perpetually trying to post.

I’ve reached out to my host to see if there are any memory limits in place on their end. It’s just odd because I’ve posted much larger forms without any problems.

Any other ideas?

Hey @takayukister

I’ve gone through the process of setting up this form on my staging site, deactivating all plugins, and switching to a default theme.

https://staging.gradepotentialtutoring.com/city-content

I’m still running into this issue. Again, this is only the case with some specific submissions. Most of them work. I can privately send you the content that I’m trying to input if that would be helpful?

Please advise.

Hey Takayuki,

I did see that FAQ, but I figured – since this is only happening for very few submissions and all else is the same – that perhaps there might just be an issue with submitting large blocks of text or certain special characters?

I was hoping to rule out the easiest possibility before undertaking the extensive troubleshooting involved in deactivating plugins and testing each one.

Thanks!

• This reply was modified 7 years, 6 months ago by Leah.

Hey, is there any way to edit my post above to remove the link to my staging site? We’ve received some human form spam over the last couple of weeks.

Thanks!

I was afraid of that ??

I’ll start looking into possible plugin conflicts, thanks for getting back.