DEV Community: Vitalii Kiiko

Contact Form 7 sent the email — but did it arrive? You have no way to know

Vitalii Kiiko — Mon, 29 Jun 2026 09:41:21 +0000

Contact Form 7 runs on millions of sites for a good reason: it's free, light, and gets out of your way. I shipped it on client sites for years. The problem isn't that CF7 is bad — it's that it answers exactly one question ("did the form submit?") and stays completely silent on the one that actually matters in production: did the notification arrive?

Here's the call every developer who maintains WP sites has taken at least once:

"I filled in your contact form last week and never heard back."

You check. The form is fine. JavaScript fires, the success message shows, no console errors. CF7 did its job — it handed the message to wp_mail() and forgot it ever existed. There's no record the submission happened, and no log of whether the email was delivered, bounced, or quietly dropped by the host's unauthenticated sendmail. The lead is just gone, and you have nothing to debug with.

The three gaps that bite in production

No submissions database. CF7 sends an email and discards the data. If the email fails or lands in spam, the submission never existed. (Flamingo helps, but it's a bolt-on — separate screen, no filtering or export out of the box, not tied to your form config.)
No delivery log. You can't tell whether mail was sent, rejected, or bounced. "I never got it" has no audit trail to check against.
No native block. CF7 is still a shortcode — [contact-form-7 id="123"]. You can't drop it into a block template, control its layout with block spacing, or edit it inline in Gutenberg. You paste a shortcode and hope.

None of these are dealbreakers for a throwaway contact form. All three are dealbreakers when a missed submission is a missed sale.

Migrating without rebuilding by hand

The reason most people put off switching isn't the feature gap — it's the thought of rebuilding every form field by field. That's the part I wanted to skip.

The migration path I use reads CF7's stored form definitions directly and recreates them as native forms. What comes across automatically:

All standard fields — text, email, URL, tel, number, textarea, select, checkbox, radio, file upload
Visible field labels
Placeholder text
Required-field rules

What doesn't (and why it's fine): custom PHP validation hooks that lived in your theme, Flamingo's historical submissions, and CF7's mail-tab config. The importer handles form structure, not server-side glue or past data — so you recreate email sending fresh, which you'd want to do anyway given the next part.

Keep CF7 active during the import — the importer reads its database entries directly.

The five minutes that were the whole point

Once a form is across, the upgrades that close the CF7 gaps take about five minutes:

Add a Save Submission action — now every submission is in a searchable, exportable database. No more "it probably went to spam."
Connect real SMTP — an authenticated service (Brevo's free tier is 300/day) with a per-email delivery log: sent, failed, or bounced, recorded. The "did it arrive?" question becomes answerable.
Behaviour-based spam scoring — runs automatically, no reCAPTCHA checkbox in front of real users.

That delivery log is the thing I actually switched for. Debugging a missing email by reading the log entry instead of interrogating the client's spam folder is a different job.

I wrote the full step-by-step — running the importer, what to verify after import (field names/slugs matter for your dynamic tags), and wiring up email templates — over on my blog:

👉 How to Migrate from Contact Form 7 to CraftForms

Disclosure: I build CraftForms, the plugin with the CF7 importer described here. The "store submissions + log delivery" principle applies whatever you migrate to.

Why wp_mail() silently eats your form notifications — and how to fix it for free

Vitalii Kiiko — Sun, 21 Jun 2026 17:26:58 +0000

You build a contact form. You submit it. The "Thank you" message shows up. Everything looks fine.

Three weeks later a client mentions they never heard back. You check WordPress — the submission is right there in the database. The form worked. The email didn't.

This is one of those bugs that stays invisible until it costs you something, and it's far more common than it should be.

Why it happens

When WordPress calls wp_mail(), it hands the message to PHP's built-in mail() function, which asks your web server to deliver it directly. On a dedicated server with a properly configured MTA, this works. On the shared hosting plans that most WordPress sites actually run on, three things go wrong:

No authentication. Gmail, Outlook, and corporate mail servers expect email from an authenticated sender. A bare mail() call carries none, so it lands in spam or gets rejected outright.
No SPF or DKIM. These DNS records tell the world which servers are allowed to send for your domain. Shared hosts send for hundreds of domains and can't be listed in everyone's SPF. Result: soft fail → spam folder.
Silent failure. mail() returns true when it hands the message to the local mail daemon — not when the message actually arrives. If it bounces later, WordPress never finds out. No log, no error, no trace.

The ugly part: you can have a contact form running for months, fully "working," with half the notification emails going nowhere — and you'd have no idea.

The fix: a dedicated SMTP service

SMTP replaces the guesswork with a proper handshake. You authenticate with a service that has managed IP reputation and DNS records, and you get a delivery log you can actually read. The good news: the free tiers are generous enough that most small sites never need to pay.

Here's the short version of the comparison:

Provider	Free tier	Best for
Brevo	300/day	Quickest setup, beginners
Mailgun	100/day	Best deliverability (bookings, payments)
SendGrid	100/day	Long-term, clear upgrade path
Gmail SMTP	500/day	Already on Google Workspace
Amazon SES	~$0.10/1K	High volume, AWS users
Mailtrap	1K test/mo	Testing and staging (sandbox inbox)

For most WordPress sites with a contact form, Brevo is the right starting point — 300 emails per day, no credit card, five-minute setup. If deliverability matters most (bookings, payment confirmations), go with Mailgun. If you're still building or testing, start with Mailtrap — its sandbox catches every outgoing email and shows you the full render before a real inbox ever sees it.

How to tell if you're affected

Before you sign up for anything, confirm you actually have a problem. If you use a form plugin that has a built-in email test (CraftForms has one under SMTP Servers — send a test email, get a 6-digit code, enter it to confirm), run that first. If the email arrives, your default mail works and you can stop here.

If it doesn't — or if you've had the "I never got your email" conversation even once — set up SMTP. Ten minutes now saves weeks of missed emails later.

I wrote the full walkthrough — all six providers compared in detail, step-by-step setup, email logging, and how to route different form actions through different SMTP servers — on my blog:

👉 Best Free SMTP for WordPress — Setup Guide

Disclosure: I build CraftForms, the form plugin I used for the examples. The SMTP providers and the underlying wp_mail() problem are the same regardless of which plugin you use.

Using a locked-down WordPress as the form backend for my static sites

Vitalii Kiiko — Fri, 19 Jun 2026 12:34:31 +0000

Static sites are great: fast, cheap to host, almost nothing to attack. Then you add a contact form and hit the same wall everyone hits — a static site can't process a submission. You need a backend.

The usual answers are a third-party service (Formspree, Netlify Forms, Basin) or a small server you now have to babysit. Both add a dependency you don't control, a recurring bill, and — the part that bugs me most — your submission data lives on someone else's infrastructure.

There's a third option I've been running for a while: one WordPress install, zero public pages, used purely as a form endpoint. Every form from every static site I own hits it. I own all the data. And because it serves no public HTML, its attack surface is close to nothing.

The architecture

Three pieces, each doing one job:

WordPress — the backend. Locked down so hard it doesn't behave like a normal WP site anymore.
A form plugin — handles building, validation, storage, email, file uploads. (I use CraftForms because it exposes a clean craftforms/v1 REST namespace and can also serve the form HTML to an external page — more on that below.)
Your static frontend — Cloudflare Pages / Netlify / wherever. It either fetches the REST endpoint on submit, or drops in an embed snippet.

WordPress never serves a public request. It only processes submissions.

The part that matters: locking it down

The biggest WordPress attack vector isn't your host — it's outdated plugins. So the first move is brutal minimalism: one plugin, no theme, no page builder, no public frontend. A WP install with one plugin and a blocked frontend has almost no CVE surface, because none of the usual stuff is installed.

The rest is one must-use plugin. Drop this in wp-content/mu-plugins/ (no activation needed) and you've blocked the four standard entry points:

<?php
if ( ! defined( 'ABSPATH' ) ) exit;

// 1. Restrict the REST API to your form namespace only.
//    Kills user enumeration (/wp/v2/users), route discovery, the usual REST exploits.
add_filter( 'rest_pre_dispatch', function ( $result, $server, $request ) {
    if ( strpos( $request->get_route(), '/craftforms/' ) === 0 ) {
        return $result;
    }
    return new WP_Error( 'rest_restricted', 'REST API disabled.', [ 'status' => 403 ] );
}, 10, 3 );

// 2. Kill XML-RPC (brute-force + pingback DDoS amplification).
add_filter( 'xmlrpc_enabled', '__return_false' );

// 3. Block every public frontend request for logged-out visitors.
//    Runs in PHP, so it works on Apache, nginx, anything — no .htaccess needed.
add_action( 'template_redirect', function () {
    if ( is_user_logged_in() ) return;
    status_header( 403 );
    nocache_headers();
    exit;
} );

template_redirect doesn't fire for REST or wp-admin, so your submission endpoint and the admin panel still work — only public pages get the 403. (The full version in the article also moves /wp-login.php to a secret slug so brute-force scanners can't find it.)

Verify it:

curl https://your-backend.com/wp-json/wp/v2/          # → 403
curl https://your-backend.com/wp-json/craftforms/v1/embed/KEY   # → form data

Submitting from the static side

Plain JSON to one endpoint:

const res = await fetch(
  'https://your-backend.com/wp-json/craftforms/v1/submit/contact-form',
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(Object.fromEntries(new FormData(form))),
  }
);

Or skip building the form entirely and let the backend render it — a single embed <div> + script tag, and you get every field type, client-side validation, and even Stripe payments / bookings on a site that has no server of its own.

Why I keep doing it this way

A third-party form service gives you one thing: an email on submit. This setup gives me a real backend I own — SMTP delivery I control, branded HTML emails, a submissions database, file uploads into the Media Library, and (with the embed) full ecommerce/booking on a static site. No per-submission billing, no data on someone else's box.

I wrote the full walkthrough — the complete mu-plugin (including the hidden-login bit), the embed setup, required-header spam protection, and the static-frontend workflow — over on my blog:

👉 Use WordPress as a Locked-Down Form Backend for Static Sites

Disclosure: I build CraftForms, the form plugin used here — but the lock-down approach works with any plugin that exposes a single REST namespace.

Release of Builderius 0.9.5!

Vitalii Kiiko — Thu, 16 Sep 2021 09:32:52 +0000

I am happy to announce the release of the new version of Builderius! This is a new-gen site builder for WordPress. You can download it from wordpress.org plugin's repo: https://wordpress.org/plugins/builderius/

We, my team and I, advertise Builderius as the professional site builder for WordPress. The key points which support this statement:

Builderius is precise and outputs only those HTML tags which are added; it is like manual coding of HTML layout - full control over output;
Builderius has built-in support of GraphQL; to get any data from DB is very easy, even the complex one like post with custom fields and user data attached - everything in one query!

Starting from version 0.9.5 Builderius has a built-in implementations of version control system for all settings and continuous delivery system. It is a huge step forward reliability and flexibility!

We have videos on our YouTube channel: https://www.youtube.com/channel/UCHuPcLh4TJTPD7c2OmzmS6Q
Builderius documentation: https://docs.builderius.io/

How to add custom options to WooCommerce products via Uni CPO

Vitalii Kiiko — Sat, 23 Jun 2018 11:52:08 +0000

Uni CPO WooCommerce Options and Price Calculation Formulas plugin gives a possibility to add custom (extra) options to you WooCommerce based products. Having custom options are vital for some products, especially those which depend on customer-defined values/customization choices. Uni CPO plugin can help you to create a price quoting calculator for your product and a possibility to order the product with the quoted configuration instantly.

The video version is available here: https://www.youtube.com/watch?v=dX7-T4gVJ_I

The free version of the plugin is available here: https://wordpress.org/plugins/uni-woo-custom-product-options/ So, go and grab it and install it along with WooCommerce. Now create a product and set its price to smth. Actually, anything, even '1'. This is needed so WC will not treat the product as free. That's all you need to begin product configuration.

Uni CPO has a quite powerful visual form builder. However, it is very easy to use and intuitive. So, activate the builder mode. Add a row by dragging and dropping a module with such a name from the builder panel. Do the same for a column. Now this is the time for custom options. Add Text Input option (again, by dragging and dropping it from the builder panel). Hover it and click on the cogs icon - option's settings modal window will be opened. Define option's slug and other settings such as make it required, step value, default value etc. Save the option.

Create a copy of the whole column - this action leads to duplicating both the column and the option. This is a faster way to add a similar option. Repeat option's configuration but choose a different slug name and save it then.

Now you have two custom options - width and height. Save the builder content by clicking "Save" button on the builder panel. Now open "Formula and conditional logic" modal window and define your price calculation formula. It is as is as writing an arbitrary maths formula. Save it.

Click on "Product general settings" icon on the builder panel and open the modal window with product-specific general options. Enable two first settings here. These are "displaying custom options" and "enable product price calculation". Save the settings.

That's all! Your product has two custom extra options - width and height - and price calculation based on the values of these options. Easy, huh? :)

Also, please, check the pro version of the plugin: https://builderius.io/cpo/ It has a lot more features, tons of features!