Core Forms 4.0 is out as of May 1, 2026. It is the first stable release on the 4.x line, and the change you will notice first is that a form is no longer a block of HTML you maintain by hand. Every form now has a schema behind it, the visual builder edits that schema and the HTML is rendered from it.

This post covers the 4.0 line as a whole, since most of it arrived through the betas that ran from April 10 and only the block editor work is new in the stable build. Existing forms keep rendering as they were. If you are coming from 3.5, the update is safe on a live site, and the code editor is still there for anyone who would rather write markup than drag fields.

The update shows up under Dashboard, then Updates, the way every release does. The docs cover each area in more depth, and anything that does not behave the way this post says can go to the support page.

What’s New in Core Forms 4.0

Four things changed at once in 4.0, and they depend on each other. The schema is the base, and the builder, the smart-form features and the analytics all read from it.

Schema-Backed Form Engine

Every form is stored as JSON, with versioning, instead of only as HTML. Before 4.0 a form was the markup you typed. Now the structure is data and the HTML is rendered from it, which is what makes a visual builder possible at all.

Forms you wrote as HTML in 3.x keep working. The engine converts a legacy form to the schema when you open it in the visual builder, and the code editor remains available for anyone who prefers markup. You can move between the two.

Visual Form Builder

The builder is a 3-column screen: an inserter on the left, the canvas in the middle and an inspector on the right, the same layout the block editor uses. It ships with more than 25 field types, drag and drop reordering, fieldset nesting, 6 starter templates and a fullscreen preview.

Where it helps most is on a form with sections. Nesting fields inside a fieldset in HTML means keeping track of closing tags. In the builder it is a drop.

Smart Forms

These are the features that used to need a separate plugin or custom JavaScript:

Multi-step forms with a progress bar.
Save and resume through tokenised draft links, so a visitor can come back to a half-finished form.
Field calculations with a safe expression parser, for order totals and quotes.
Schedule windows, so a form opens and closes on a date.
Conditional logic with 14 operators and grouped AND/OR rules.
Accessible inline validation.

Every one of these is a per-form setting. A plain contact form does not carry the weight of a multi-step wizard.

21 Native Integrations

Actions run after a submission, and each one is native, meaning a direct API call from the plugin with no middle service. The set at 4.0:

Notifications: Email, Autoresponder, Slack, Discord, Telegram and Twilio SMS.
Marketing and CRM: Mailchimp, ConvertKit, ActiveCampaign, Brevo, Drip, MailerLite, HubSpot and FluentCRM.
Data: Google Sheets, Notion and Airtable.
Automation: Webhooks, Zapier and Make.
WordPress: Create User, Create Post and Create Article with ACF field mapping.

Behind these sits a workflow layer: an async action queue with background processing, retries with exponential backoff, structured action logs and HMAC-SHA256 signatures on outgoing webhooks. A Slack outage no longer blocks the visitor’s submission. The action retries on its own and the log shows what happened.

Analytics

Core Forms records views, starts, submissions and abandonment for every form, along with field-level drop-off, UTM and referrer attribution and a set of generated recommendations. The point of field-level drop-off is to show which field people leave on, which is generally the one asking for something they do not have at hand.

Native Block Editor Support

The Core Form block renders a live preview in the editor through server-side rendering, with a form picker in the inspector, a shortcode transform, block variations and spacing and alignment supports. The stable build adds a fuller inspector: header controls (show the title, pick the heading level), layout controls (alignment, max width, anchor) and per-block stylesheet overrides.

One behavior changed in stable. The block now respects the global and per-form “Default form theme” toggle. In the betas it force-loaded the theme stylesheet whatever the setting said.

Security, Tests and Docs

6 audit rounds fixed more than 50 bugs during the beta period.
Upload MIME validation and more than 30 blocked file extensions.
114 PHPUnit tests, PHPStan at level 5 and ESLint on the builder.
61 documentation files, more than 11,000 lines, covering getting started, the builder, smart forms, integrations, workflows, analytics and the developer reference.

The requirements at 4.0 are PHP 7.4 and WordPress 6.0.

The Patch Releases

Three patch releases followed within the week. All three are admin work. No form markup or data changed.

4.0.1

May 3, 2026. The Actions tab was redesigned. Each configured action is now a card with its icon in the header; click to expand, and removing one is a soft remove. Every action card carries an “Available variables” panel, and clicking a token inserts it at the cursor of the focused field. New variables cover the submission source (referrer URL, post ID, post title) and the logged-in user (login, email, display name).

4.0.2

May 4, 2026. The admin screens got a set of design tokens for color, spacing and shadows, scoped to Core Forms pages so they do not leak into the rest of wp-admin. The default front-end form theme was rewritten with brand-blue submit buttons, 8px input radii and a 4-step focus ring. No webfonts load anywhere: the admin uses the system font stack and the front end inherits the host theme’s font.

4.0.3

May 5, 2026. Every Core Forms admin page now shares one sub-navigation bar (Forms, Add New, Submissions, Settings, Spam), and page headers match the form theme card in Settings. Submissions show readable action labels, so cf_form_submit reads as “Form Submission” and cf_save_draft as “Form Draft Saved”. Submission columns gained a non-destructive Hide Column toggle beside Rename and Delete. More template variables landed: CF_REFERRER_URL, CF_POST_TITLE, CF_USER_EMAIL, CF_SUBMISSION_ID and others.

The Limits

4.0 does not take payments. A form can collect an order, but the charge has to happen somewhere else. Payments are on the roadmap.

There is no way to render or submit a form from outside WordPress. The REST API from 3.5 covers submissions for an authenticated admin, not a public submit endpoint.

The analytics live in the site’s own database, so a very busy form will grow those tables. There is no retention setting in 4.0.

Docs and Links

Core Forms 4.0 in the changelog, with the beta entries beneath it.
Creating your first form and the visual builder.
Multi-step forms and conditional logic.
Integrations overview.

Final Remarks

If you have updated, your forms look the same on the front end and the work of maintaining them has moved from markup to a builder that knows what each field is. That is the idea behind the whole 4.x line, and everything after this release builds on it.

Two things are worth doing right after updating. Open one existing form in the builder and check that the conversion kept every field, because that is where a legacy form with unusual markup would show a problem. And turn on analytics for the one form that matters most before deciding whether you want it everywhere.

The docs cover each feature in more depth than a release post can, and the support page is open for anything that does not match what is written here.

That is all for 4.0. I hope it makes your forms easier to keep.

Core Forms 4.0