Affilateallinone
Forum Replies Created
-
Forum: Plugins
In reply to: [Contact Form 7] Mail 1 is sent, mail 2 is not sentClassic one — this is almost always one specific checkbox: at the top of the Mail (2) tab in your form editor, there’s a checkbox that says “Use mail (2)”. If that’s unchecked, everything you type into Mail 2’s fields (To, Subject, Body) is saved but never actually sent — CF7 just silently skips the whole tab. That trips up almost everyone the first time.
Worth checking:
- That checkbox is ticked
[email-838]matches your field’s exact name — if the actual field tag in your form is[email* email-838], then[email-838]in the To field is correct as long as there’s no typo- The field is actually required (
email*notemail) so it can’t be blank when Mail 2 tries to send to it
If the checkbox is already on and it’s still not sending, one more thing to know: CF7 tells the visitor “message sent successfully” based on Mail 1 alone — if Mail 2 fails silently (bad recipient, host blocking it, SPF/DKIM issues since Mail 2 often goes to an external address that doesn’t match your sending domain), you’d never see an error, it just quietly doesn’t arrive.
- This reply was modified 4 days, 18 hours ago by Affilateallinone.
Forum: Plugins
In reply to: [Contact Form 7] Fields won’t disappear after message sentCommon one — CF7 does clear the form fields after a successful send by default, so if it’s not happening, something’s interrupting that JS behavior. Usual suspects, in order of likelihood:
Cache/minify plugins serving a stale or minified copy of CF7’s own script file that’s missing or breaking the reset code. Worth clearing all caching (page cache, JS/CSS minify, CDN) and reloading with a hard refresh before testing again.
A JS error elsewhere on the page. If any other script on that page throws an error before CF7’s script runs, it can silently stop CF7’s own event listener from firing. Check the browser console (F12) right after submitting — any red errors there are the real lead.
Contact Form 7 itself out of date. Older CF7 versions handled this differently; updating to the latest version alone fixes this for a lot of people who report “it used to do this.”
A theme or another plugin loading its own jQuery version alongside WordPress’s bundled one, which breaks event binding for other scripts on the page (very common with page builders/themes that bundle their own jQuery).
Simplest test to isolate it: switch to a default theme (Twenty Twenty-Four) and disable all other plugins except CF7, then test the same form. If it resets properly there, it’s a conflict, not a CF7 bug, and you can re-enable plugins one at a time to find which one’s responsible.
Not tying LeadShield to this one either, it’s a front-end reset behavior issue, nothing to do with what LeadShield actually does.
Had this happen before — CF7 form just sits there for 20-30 seconds after you hit submit, feels broken.
Quick way to check: open DevTools (F12), Network tab, submit the form, click the request that shows up. If the delay is “waiting for server response,” it’s not your internet, something on the server side is blocking.
Usually it’s another plugin doing extra work at the same moment CF7 sends its email — most often anything that logs or saves your form submissions somewhere. If that plugin does a slow DB query or calls an outside API right then, it holds up the whole thing.
Easiest fix: disable your plugins one by one and test after each. Start with whatever’s saving/logging your leads, that’s almost always it.
- This reply was modified 4 days, 18 hours ago by Affilateallinone.