nocabt

Switching to a proper email field did seem to fix it, thanks. I guess I was confused b/c the Reply-to in “Additional Headers” didn’t throw off a warning and it was also using a text field. I’ve always thought reply-to should be it’s own field, btw, then you could also validate that easily. seems like using reply-to is a pretty common setup.

Thanks for your help!

No, still get that error when I use a new test email field:

[email email-786]

Then get in Mail(2):

To [email-786]
This field has syntax errors.

For the email field body, I have:

[text* email id:email placeholder “Email”]

Also our “Additional Headers” field has:

Reply-To: [email]

Which validates fine. It’s only the Mail (2) “To” field that isn’t working.

Looking at this now, though, I wonder if it’s b/c the developer used a text type field instead of a proper email field?

To expand on devinian’s correct comment – the reason it’s recommended to be setup like this is to prevent emails from being rejected as spam by a mail server. For example if the site domain.com sends an email that is from [email protected], the receiving mail server (myemaildomain.com) might flag that as spam or outright reject it, especially if domain.com is using strict email authentication, with the logic, “I just got this email that says it’s from [email protected], but anotherdomain.com doesn’t say that domain.com has permission to be sending this message, so I’m going to reject it…”

I’m guessing the reason CF7 developers added this feature in is b/c I’m guessing they’ve received a ton of complaints about contact form submissions not arriving in inboxes b/c of a similar configuration to what you’re using.

On another note, maybe you should have started your post, “Thanks for the great plugin I’ve been using for free for years on my website! I have a bit of feedback…”

You know what they say about catching more bees with honey than vinegar…

I know this is a couple months old but the correct format for dates in Schema.org is ISO 8601, which you can get in PHP using “c” instead of “Y/m/d g:i:s A”

For example:

[types field=”my-date” format=”c”][/types]

(to use that shortcode example)

For now I disabled Object Caching, I was never able to get a straight answer about this and the site is performing well without it enabled. Thanks for your help though.

Actually I spoke too soon; I reinstalled it and when I select a timezone in WP options; All-in-One tells me “”The plugin is installed, but has not been configured. Click here to set it up now ?”” and asks me to choose a time zone, and I save it with Chicago. Then, the problem pops back up. First event is correct, all following are +5 hours.

However, if I make WP use UTC-5 BUT do not respond to the All-in-one message saying, “The plugin is installed, but has not been configured. Click here to set it up now ?” and don’t save that setting, it works… The second I save it it breaks again..

However, I installed this on a fresh WP install on the same server and it worked fine using Chicago setting in WP… so I guess it is something with my install?

It did, but then I decided to reinstall, and now it’s working fine with Chicago time set in WP, Calendar plugin, and server. Not sure what it was but it’s working now!

Not necessarily I don’t think, b/c UTC – 5 is the same time as America/Chicago. I think this will only cause an issue if you observe daylight savings, which we do, so I’ll have to manually change it then I guess to UTC – 6, which is less than ideal of course, unless I’m missing something.

Our server was set to GMT -5 America / Chicago, and so I set WP to use the same. However that was causing the issue. I changed WP to UTC -5 and it fixed it.

Hope that helps you.

I’m getting this same error as well, but it seems to still work ok.

Have you verified those values are being applied by creating a simple PHP info page:

<?php phpinfo(); ?>

then making sure the local value column contains 128M for “memory_limit”?

My gut tells me it’s a memory issue still, I used:

define('WP_MEMORY_LIMIT', '128M');

and you can increase PHP Memory Limit in .htaccess or local php.ini file (I think the latter on Bluehost as PHP is running as CGI?). Here are a couple help pages from bluehost:

https://my.bluehost.com/cgi/help/memory
https://my.bluehost.com/cgi/help/557

Right after I posted that I tried increasing WP_MEMORY_LIMIT in wp-config.php, and it upgraded fine.

Hope that helps you Cloudrunner.

Same exact problem here. upgraded a couple sites and all fine except one failed with this exact issue. I’m still investigating it, I’ll post back here if I figure it out.