Lead forms

How it works

theme/inc/lead-form.php renders the form and handles the POST. It is server-side, with no third-party form plugin, for one reason: a form plugin puts your leads in someone else's database and usually adds its own styling you then fight.

form POST → nonce check → honeypot check → validation → wp_mail( SB_LEAD_EMAIL ) → thank-you state

Rules

• Nonce on every form. wp_nonce_field() in, check_admin_referer() out.
• Honeypot, not CAPTCHA. A hidden field that must stay empty stops the great majority of bot submissions at zero cost to the human filling it in. Reach for a CAPTCHA only if the honeypot demonstrably stops working — it is a real conversion tax.
• Sanitise in, escape out. sanitize_text_field(), sanitize_email(), wp_kses_post() on the way in; esc_html() on the way out.
• Ask for the fewest fields that qualify the lead. Every field costs completions. If nobody reads a field's answer, delete it.
• Never log submissions to a file in the webroot. That is how a leads file ends up publicly fetchable.
• Never commit real submissions. *leads*.csv and *subscribers*.csv are gitignored deliberately.

Delivery

wp_mail() to SB_LEAD_EMAIL. On most hosts PHP mail is unreliable and lands in spam — configure SMTP at the host or with an SMTP plugin.

Credentials never go in this repo. Not in a config file, not in a comment, not in a .txt alongside it. Use the plugin's own settings screen or an environment variable. An app password committed to a repo is compromised the moment the repo is cloned, and deleting the file does not remove it from history.

Debugging "the form does not send"

In order — it is almost always the third one:

1. Does the POST reach the handler? error_log() at the top of the callback.
2. Does the nonce pass? A cached page serves a stale nonce; exclude the page from full-page caching.
3. Does wp_mail() return true? If yes, it is a deliverability problem, not a code problem. Check SMTP and SPF/DKIM before touching the form.