Nathan Adams

Damn, but good to know it’s nothing to do with the site itself. A hosting move is already planned.

Did you ever find a solution @davemak ?

I’ve had the same issue for months on Mediatemple (part of GoDaddy). They’ve just migrated us from their old Grid hosting to a new cPanel Hosting plan and I was hoping whatever issue it had would fix itself in the move, but still getting the same. (Meanwhile, I’ve cloned the site to a personal server on a different provider, and not getting the problem at all)

Ended up resolving this by rolling back all the way to 4.7.

There was no caching/minifier on the host, nor any server settings that seemed abnormal. Tried turning off all other plugins, changing to a bare minimum theme, nothing seemed to work.

Yeah, I fixed up some of the html errors it was showing, so all that’s left is some type attributes on scripts some plugins are loading. So I can rule that out.
Time to go find out about their current hosting! Thanks.

I’m at a bit of a loss. I’ve cloned the site from the client’s server to my own, and with the same theme, same plugins, the contact form works fine.

The server details (as shown in Site Health) don’t look terribly different between the two, but that’s the only point of difference between the two Not working vs Working. https://dev.sector7g.com.au/madderns/contact/

Hi Erik,

I’ve had the caching plugin turned off while troubleshooting, so it wouldn’t be that.

By “the script”, do you mean the cf7 index.js? It’s being loaded in the footer, and it’s definitely loaded before I’m trying to submit the form.

No update on this at all, after 9 months?

This is a rather critical thing to have available. It certainly shouldn’t be marked resolved.

Thanks!

I’m going to add to this call to remove the wrapping nf-field tag, or apply size classes to it. It might not impact the layout if you’re using floats, but it kills using flexbox.

Hi Raam,

I’m running 160917 on all of our sites.

The error has reappeared on one of our sites, and the error is definitely being cached. I’ve opened up wp-content/cache/comet-cache/cache/http/site-name/index.html and it’s there on the second line.

I’ve been running both iThemes Security and Comet Cache for quite some time now, and it’s only been recently that this issue has come up.

Hi Raam,

Thanks for your response. I’m using the Lite version of the plugin, and 404 Caching is not on.

I think you’re right about spidering, as I can see large numbers of cache files being updated with identical timestamps. I’m guessing it’s going through ?p=1, ?p=2 etc. and if the post id matches a post/page, that isn’t ignored by the cache.

I’ll up my security settings to crack down on multiple 404 requests and see how that goes.

Ok, so I’ve managed to write some Excel formulas that can generate the array of post-IDs in the format the relationship field saves as the meta_value, so that part of the equation is solved.

Example:
a:4:{i:0;s:4:"1027";i:1;s:4:"1028";i:2;s:4:"1046";i:3;s:4:"1047";}

However when I import that, it adds that entire string as a single item within a whole new array, like:
a:1:{i:0;s:60:"a:4:{i:0;s:4:"1027";i:1;s:4:"1028";i:2;s:4:"1046";i:3;s:4:"1047";}";}

What’s going on there? How can I get it to update the meta_value exactly as entered in the CSV?

Thanks for the insanely quick update, Mickey.

Issue is fixed for me.

I’m also getting memory limit errors after updating to the most recent version. Disabling the plugin fixes the issue, so clearly related to the plugin. (Increasing the memory allocated to PHP as per the link doesn’t help.)

In the end I just edited line 347 of useremails.php, changing
$Template_Body = str_replace ( '[password_reset_url]', wp_login_url ( ) . '?action=rp&key=' . $Key . '&login=' . $User_Login, $Template_Body );
to
$Template_Body = str_replace ( '[password_reset_url]', wp_login_url ( ) . '?action=rp&key=' . $Key . '&login=' . rawurlencode($User_Login), $Template_Body );

That seems to have done the trick.