Core Forms 4.9

Core Forms 4.9 is out as of September 5, 2026. This release fixes problems that could reject valid submissions or lose form data, alongside changes that make the admin easier to use day to day.

I recommend updating, particularly if your forms use captcha protection or calculated payment amounts. Some fixes affect database tables and existing defaults, so a current backup and a check of your important forms should be part of the update.

You can get it under Dashboard > Updates with an active Core Forms license. The full changelog lists every change, and the support page is there if you need help with a particular setup.

Before You Update

There is no need to rebuild your forms, but this release does more than change their settings screens. These are the changes that deserve attention before an update on a live site:

• Submission indexes: Core Forms adds database indexes for the fields used to find and count submissions. A site with a large submissions table should allow time for the migration.
• Unused store defaults: Earlier versions could create store pages and enable the license API during activation. The upgrade disables that API and returns untouched generated pages to draft where the stored records show an unused default store. Stores with genuine commerce records are preserved.
• Fullscreen compatibility: Forms with payments or multiple steps fall back to Normal mode because the fullscreen interface cannot correctly represent those features.
• Default form colors: Saved colors that still match the old defaults receive the improved contrast values. Colors you chose yourself are preserved.

The data-loss fixes prevent those operations from causing the same damage again. They do not restore HTML or metadata that an earlier version already removed. If something is missing before you update, keep the relevant backup or revision available.

What’s New in Core Forms 4.9

The visible changes focus on finding the right control and understanding what a save will do. Most of the improvement is in ordinary work: changing a setting, checking submissions or returning to a product you need to finish setting up.

Settings

Global Settings now lets you work in one section at a time, with search across the settings and a Show all sections option when you want the full page.

The earlier page placed every section in a long form. Finding a captcha setting meant scrolling past unrelated email or payment controls, and the navigation could highlight more than one section. The section list now gives you one current location.

A few details make this more useful than simply hiding parts of the page:

• Search finds sections from their labels and descriptions.
• Unsaved changes clears when you restore a setting to its original value.
• Save settings remains reachable, including on smaller screens, and returns you to the section you were using.
• Validation opens a hidden section if a field there needs correcting before the form can save.

Saving still applies to the settings form as a whole. A section being out of view does not remove its values from the save.

The section list keeps unrelated controls out of the way while the save bar makes the current save state visible.

Core Commerce

Core Commerce keeps the same places for managing products and customer access, with flat tabs that match the rest of the plugin. The thick tab baseline and extra borders around action rows are gone.

Recent activity now groups the person or system responsible beneath each event, with the date alongside it. That keeps an event and its context together when the page becomes narrow, instead of making you read across separate columns.

The overview keeps setup work above the store totals, so an unfinished product is easy to find.

These changes help you read the existing records. They do not create release packages or complete product setup for you; an item under Needs attention still needs the action it names.

Fixes That Matter to Existing Forms

The admin is the part you can see immediately. The following fixes are the stronger reason to update.

Form and Submission Safety

Saving a form from a tab other than Fields could replace its HTML with an empty value because that tab did not submit a markup field. Core Forms now retains the stored HTML when the control is absent. Changing a notification or payment setting should not cost you the form you built.

Related fixes cover the rest of the submission path:

• Bulk deletion removes submission data without treating submission IDs as WordPress post IDs and deleting unrelated post metadata.
• Failed inserts no longer produce a success response and trigger notifications as though the submission had been stored.
• File uploads reach the server when a form uses the no-JavaScript submission path.
• Field validation follows the fields the form actually renders, including forms saved through the visual builder.

Spam and Payment Validation

Captcha protection has to distinguish a rejected visitor from a broken check. The reCAPTCHA and math-captcha validators now read the submitted tokens correctly, so valid responses reach validation instead of being discarded first.

The payment and privacy checks also received fixes:

• Calculated payment amounts are recomputed on the server rather than accepted as a total supplied by the browser.
• Draft saving checks the form nonce and field allowlist before storing submitted values.
• Template tags can read only the supported user and post properties, rather than exposing sensitive fields.
• GDPR erasure matches the exact submitted email address instead of treating parts of it as search wildcards.

These fixes improve the checks Core Forms performs. They do not replace payment-provider configuration or make every possible form immune to spam.

Smaller Changes and Fixes

A few other changes will show up during regular work:

• Submissions: Search, date range and status filters now work together. Bulk controls are available above the records, and the per-form inbox has search.
• Form editor: The toolbar uses consistent colors for its controls and disabled states. Shortcodes have copy buttons that work from the keyboard.
• Standalone URLs: The URL, Copy and Open controls align in one row. URL displays appear only when Fullscreen mode and standalone publishing are enabled. Changing the URL base now refreshes the correct route.
• Duplicate prevention: Repeated submissions with identical values can be refused within the duplicate-detection window. A changed answer is treated as a new submission.
• Email logs: A failed send records the error reported by the mail transport. An accepted send still does not prove that the email reached the inbox.
• Spam reprocessing: Marking a submission as valid respects the conditions on its configured actions.
• Diagnostics: wp core-forms doctor checks installation health, with related information available under Tools > Site Health > Info.
• Uninstall: Delete data on uninstall is off by default. Turning it on means deleting the plugin also removes its stored data; deactivating it does not.

The Limits

The fullscreen interface still handles one question at a time and does not support payment forms or multi-step layouts. Normal mode is the appropriate choice for those forms.

The built-in contrast checks cover the tested color combinations. They do not certify an entire form or the page around it as accessible, particularly when a theme or custom CSS changes what visitors see.

And a successful update does not prove that every integration on your site is configured correctly. A form that sends to a mail provider or a webhook still needs a submission that confirms the destination received what you expected.

Docs and Links

The detailed references are available here:

• Core Forms 4.9 in the changelog.
• Core Forms documentation for configuration and integration details.
• Core Forms 4.8, the preceding release covering minified assets and form detection.
• Core Forms support for problems with an existing installation.

Final Remarks

Once you have updated, the useful next step is to check the forms people depend on. A contact form should leave a stored entry and the expected notification. A paid form should use the amount your calculation produces and reach the correct payment state.

I would also check one form from outside the Fields tab, since that is the everyday action behind one of the more serious fixes in this release. Save a harmless setting change and confirm the form remains intact.

The documentation covers the individual settings, and support is available if a result does not match the configuration. I hope this update makes your forms easier to maintain.