sporkme

Yes, that’s me!

So on one question, I did find an answer, and I’ll share here. If you want to change the day of the week the calendar starts on, the plugin pulls that info from the WP settings under Settings -> General.

Any quick fixes I can do on my end with the missing deps issue? I did some digging and I’m lost as to what eventually makes it start working.

Yeah, I wasn’t really clear on when that fired – I assumed literally “on submit”, not “after form is submitted”, but the docs on all this are a bit sparse.

I’ve seen that page on “accessing user data”, but I’m not at all clear how I’d send my altered field entry back.

I also have a few related questions in via your main support portal, but have not heard anything back. What is your target time for turnaround on tickets?

Thanks – I also wanted to triple-check that the Classic block remains so I not only deleted, but removed the plugin (and restarted apache, php-fpm, redis, etc.) and the Classic block remains. I assumed this would be the case, but just wanted to be sure. ??

I would LOVE to hear any kind of official word on what the prognosis is for this block…

Sorry I drifted away from this one…

Yes, the message is sent, but is missing the headers.

Personally, even just something, anything that would show up with debug enabled would be great. The error I tracked down ended up being really simple, but was nearly impossible to find by digging in logs and adding extra debugging in the plugin. I mean, maybe even displaying the error in all cases is worth something? If a user is expecting certain parameters to be set for the mail message and those are not being set do to a syntax problem, it seems like telling them is generally a good thing?

PHPMailer does give a very nice and verbose answer when you screw up:

in wp_mail() - address checker, adding reply-to as addr and name
<[email protected]
<strong>Invalid address:  (Reply-To): <[email protected]</strong><br />
in wp_mail() - before switch() on address_header
reply_to
in wp_mail() - address checker, adding reply-to as addr and name
[email protected]>
<strong>Invalid address:  (Reply-To): [email protected]></strong><br />

I figured most of this out. Debating whether to raise a bug with WordPress itself or not.

First, the “From:” tag not being obeyed was easy. I found someone had stashed a filter in functions.php that was always overriding the From address. Removed that, problem solved.

Second, what I was banging my head against with the Reply-To: field was the issue of it working in one place and not another, even with matching versions of everything. What I missed is where it was working, my “Additional Headers” had “Reply-to: [location]” and where it was not, I had “Reply-to: <[location]>”. Both are proper syntax… until you have multiple addresses. For example “<[email protected]>” is legit, as is “[email protected], [email protected]”, or “<[email protected]>, <[email protected]>”.

“<[email protected], [email protected]>” is NOT, and that’s what “<[location]>” would generate.

I can’t see an easy way to have CF7 validate something like that.

I moved on to wp_mail() (in wp-includes/pluggable.php) before figuring out the issue and just added debug statements all over the place until I found my “$headers” array had lost the Reply-to. Around line 409 the reply-to is added using phpMailer’s “addReplyTo” method. If the syntax is incorrect, the header is not added, but wp_mail() DOES NOT catch and report the error.

Any opinions on whether this is worth raising as a bug? The user/developer should be notified of syntax errors rather than just silently failing, but I have no idea how open to commentary the devs are…

Slowly working through this, maybe it will be helpful to someone else?

I added some debugging in includes/mail.php just before “wp_mail()” is called so I could see what’s inside “$headers” and whether the mail-tags were working. Looks like they work, but something further down the line (in wp_mail(), which I assume eventually uses PHPMailer) must be “fixing” something:

This is the log – two emails are sent, one being to the form recipient, the other being the autoresponder:

start cf7 log
From: [email protected]
X-WPCF7-Content-Type: text/plain
Reply-To: [email protected]

start cf7 log
From: [email protected],[email protected]
X-WPCF7-Content-Type: text/plain
Reply-To: <[email protected],[email protected]>

So my “From:” and “Reply-To:” are intact up to line 135 or so of “includes/mail.php” in CF7.

OK, last ask for some insight here and then I’m just going to go with a workaround.

Anyone familiar with the code for where mail-tags are parsed? I’m thinking somewhere there’s a test where this fails and default values are subbed in.

Still looking for any general debug tips as well – thinking about hacking something into WP’s included phpmailer to see what CF7 is passing to phpmailer just in case phpmailer is the culprit here.

This is getting nutty – two sites on one this works, on another it does not. Same version of WP, same version of CF7.

On the not-working site even after disabling all CF7-related plugins, same behavior – the “From:” and “Addtional Headers” with “Reply-To” set are silently ignored.

This seems to be happening well before the MTA is even involved.

Had a quick look, but didn’t find anything totally relevant yet.

Currently trying on a stripped-down site and seeing more things work, but also seeing this break in new ways. Putting multiple email addresses in on this site is generating the generic error “There was an error trying to send your message. Please try again later.”.

Even withe WP_DEBUG enabled, there’s nothing in my php error log, apache error log nor the browser console. I would love to find a way to have CF7 output some debugging info.

OK, alternately, is there a function I can hook into to hopefully override whatever behavior is happening here?

I was looking around here: https://contactform7.com/docs/ but didn’t really see any developer docs.

It’s a staging site behind a user/pass…

Good luck getting things back up to speed! Obviously there are a ton of people that love this plugin. You hopefully just saved some of us the work of digging around for a compatible replacement.

Looking forward to hearing what the developers of those other plugins have to say.

If just one would step up with a transparent, zero-touch migration, they’d easily gain a huge number of users…

@devaghost – Which plugins have you found that allow for an import? We’re still OK here with the patch that was posted, but I’d love to migrate to another plugin, but we have SO MANY images categorized with this (our library is upwards of 3,000 images) that we just have no interest in re-tagging everything for a new plugin.