WPForms goes silent after a security plugin update

This is the exact class of bug the "Emergency Form Fix" service targets: the form looks fine to every visitor, and there is no error anywhere in wp-admin — but the business hasn't received a single lead in days.

Step 1
Reproduce before touching anything

Before changing a single setting, submit a real test entry through the live form exactly as a visitor would — same browser, no admin session, no ad blockers disabled. This confirms the failure is real (not, say, a lead landing in spam) and captures the exact conditions to compare against after the fix.

Result: the success message displayed normally. No email arrived at the site's admin address within 10 minutes. The WPForms entry itself, however, did save correctly in wp-admin → WPForms → Entries — which immediately narrows the bug from "form is broken" to "form saves the entry but the notification email never sends."

Step 2
Isolate: plugin, mail transport, or hook conflict?

Three usual suspects for this exact pattern, checked in order of likelihood and cost to check:

Step 3
Fix the actual cause, then verify

The fix here was to reconfigure outbound mail to go through an authenticated SMTP connection instead of PHP's mail(), so it's no longer subject to that hardening rule (and is more deliverable in general — fewer landing in spam). After the change, the same live-form test from Step 1 was repeated and the notification arrived within seconds.

This is also why a fix isn't called done here until a real test lead is confirmed delivered — a config change that "should" work isn't the same as watching the email actually land.

Step 4
Wire in a alert that survives the next update

The underlying risk doesn't go away just because this specific cause is fixed — a future plugin or hosting change could break mail delivery again, silently, the same way. The fix for that is a second, independent notification path that doesn't depend on the form plugin's own mail handling: a Slack webhook fired directly from the form's submit hook, plus a backup email sent through a separate code path.

// wp-content/mu-plugins/wp-lead-alerts.php (excerpt)
// mu-plugins can't be deactivated by a future plugin update — the
// alert layer stays in place even if the form plugin changes again.

add_action( 'wpforms_process_complete', function ( $fields, $entry, $form_data ) {
    $summary = "New lead via WPForms (\"{$form_data['settings']['form_title']}\")\n"
             . wpla_format_fields( wp_list_pluck( $fields, 'value' ) );

    wpla_notify_slack( $summary );          // independent Slack webhook
    wpla_notify_backup_email( 'New lead', $summary ); // separate wp_mail() call
}, 10, 3 );

// Contact Form 7 gets the same treatment, but also alerts on FAILURE —
// this is the line that would have caught the bug above the moment it happened:
add_action( 'wpcf7_mail_failed', function ( $contact_form ) {
    $msg = "Contact Form 7 mail FAILED for \"{$contact_form->title()}\" — check mail config now.";
    wpla_notify_slack( "🚨 $msg" );
    wpla_notify_backup_email( 'ALERT: form mail failed', $msg );
} );

The full file — including Gravity Forms and WooCommerce support — is what ships with the Lead Alert Setup add-on. It's a single mu-plugin file, no database changes, no third-party service required beyond an optional free Slack incoming webhook.

Result