Core Forms 4.5

Core Forms 4.5 is out as of July 22, 2026. It is a smaller release than 4.4 and most of it is about what the plugin loads and when. The change you will notice first is the URL of a standalone form, /collect/form-slug/ instead of ?cf-form=slug. The change you will notice on a speed test is that a basic form no longer pulls in the Smart Forms stylesheet and scripts it does not use.

This post covers the release in full. Existing fullscreen forms move to the new URLs on their own and the old links keep working. Two settings became explicit in this release, analytics and partial entries, and a form that relied on either running by default needs a look, so that section comes first.

The update sits under Dashboard, then Updates. The changelog has the raw list. Anything that does not behave as described here can go to the support page.

Before You Update

• Analytics is a global and per-form control now, and a form with analytics off loads no tracker and records no server-side events. Before 4.5, collection could run for forms that had not opted in. If you report on a form’s numbers, check its toggle after updating.
• Partial-entry capture is its own setting, separate from save and resume. Draft and partial storage does not run unless the form opts in.
• A form with AJAX disabled in its settings now actually submits without AJAX. The setting was being ignored, so a form that had it off was still submitting through JavaScript. From 4.5 it does a full-page submit through the new Post/Redirect/Get path.
• Existing fullscreen forms are migrated to the /collect/ route. Legacy ?cf-form=slug links still resolve. The base slug is a global setting, and it is wise to choose it before sharing standalone links.

What’s New in Core Forms 4.5

Four areas changed. The first one is a URL, and the other three are about the plugin doing less on pages that need less.

Standalone Form Pages

A form can live at its own address, /collect/form-slug/ by default. The base is a global setting, each form gets a stable public slug, indexing is optional per form, the route checks for collisions with existing content and the response is served private with no-store headers so a shared link is not cached along the way.

These pages go through the normal WordPress enqueue pipeline with wp_head() and wp_footer(), so anything a plugin adds to the head arrives here too. External fullscreen assets are limited to validated HTTPS URLs.

Assets Loaded Per Feature

Front-end assets now resolve through a per-form capability manifest, and the same manifest serves embedded, preview, fullscreen and standalone renders. A basic schema form keeps inline validation without loading the Smart Forms stylesheet. Drafts, partial entries, calculations, counters, the multi-step UI, scheduling, resize helpers, the fullscreen UI, analytics and inline payments each load only when the form uses them.

Two leaks were closed with it. Pages with no form were keeping Core Forms assets enqueued through metadata or third-party block discovery, and basic forms were loading core-forms-smart-inline-css without using any styled Smart Forms feature. Both leaks are closed in 4.5.

Submissions Without JavaScript

A form with AJAX disabled uses a native Post/Redirect/Get flow: the browser posts, the server processes, and the visitor is redirected to the confirmation message or the redirect URL. Validation errors, success messages and stored submissions all work without a line of JavaScript, which is the form a screen reader or a locked-down browser gets.

Analytics and Partial-Entry Controls

Analytics has a global switch and a per-form switch, plus a cf_should_track_analytics consent filter so a consent tool can decide per visitor. Partial-entry capture is an explicit setting. The form editor also shows per-form runtime diagnostics and finds where the form is used through shortcodes and blocks, so you can see what a form loads and where before changing anything.

Smaller Changes and Fixes

• The historical poll-voter migration relied on MySQL-only hashing functions. It now runs on SQLite-backed installs, so activation and upgrades are clean on WordPress Studio.
• The poll voter cookie was issued on every front-end request, including pages and standalone forms with no poll. It is issued on poll pages only.
• Validation and provider failures omitted the JSON error flag, which could make the front end fire a success event and reset a form that had not been accepted. The flag is always present.

The Limits

A standalone page is the form and nothing else. The active theme is not rendered there, so its header, footer and navigation do not appear.

The consent filter is a hook, not a banner. It gives your consent tool a place to say no; it does not ask the visitor anything itself.

The manifest decides by feature, per form. A form that turns a feature on later loads the assets for it from the next render, but a custom script of your own that assumed the Smart Forms bundle was always present on the page now has to check.

Docs and Links

• Core Forms 4.5 in the changelog.
• Standalone form pages and fullscreen forms.
• AJAX submissions and form analytics.
• The previous release, Core Forms 4.4.

Final Remarks

If you have updated, a page with a plain contact form loads what a plain contact form needs, and a page with no form loads nothing from Core Forms at all. The idea to keep is that what a page loads should follow what the form actually uses, and 4.5 is where the plugin started reading the form before deciding.

There are three things I would check after updating. Check the analytics toggle on the forms you report on, because collection no longer runs by default. Submit one form with AJAX off and watch the redirect, so you know what the no-JavaScript path looks like on your theme. And pick the standalone base slug once, before anyone bookmarks a link.

The standalone forms guide covers the base slug and indexing choice, and the support page is there if a page loads something it should not.

That is all for 4.5. I hope your speed tests notice.