Core Forms 4.6 is out as of July 22, 2026, the same day as 4.5. Where 4.4 added the licensing and ecommerce system, 4.6 rebuilds the admin around it. The change most people will notice is that Products & Licensing is now a workspace with an overview, searchable tables and a page per product, instead of a set of settings forms. The second change is a native checkout that sells a product and plan without a stored Core Form at all.

This post covers the release and the 2 patches through July 27, one of which renamed the workspace to Core Commerce. Nothing changes for forms that do not sell anything. If you sell software, there is a new capability and a new checkout-page rule, and both are in the next section.

WordPress offers the update under Dashboard, then Updates. The changelog has the raw list, and the support page is open if something behaves differently from what is written here.

Before You Update

Licensing screens now sit behind a dedicated manage_core_forms_licenses capability, granted to administrators. Any other role that managed licenses before needs the capability added.
Renewal links no longer carry a license key or a customer email in the URL, and newly signed package URLs identify the license by record ID instead of embedding the full key. Existing unexpired links keep working, so nothing you have already sent breaks.
From 4.6.2, the checkout page is provisioned as /core-checkout/ when a /checkout/ page already exists that Core Forms did not create. WooCommerce and hand-built checkout pages are left alone.
From 4.6.3, the menu labels change: the Forms dashboard is called Core Forms and shows the installed version beside its heading, and Products & Licensing is called Core Commerce.

What’s New in Core Forms 4.6

Six areas changed. The first three are the admin, the next two are how a product reaches a page and a program, and the last is what a customer sees.

Products & Licensing Workspace

The overview opens on store totals, the operational states that need attention, setup readiness checks and a persistent activity timeline. Products, licenses and orders each have a searchable, filterable list table with screen options and a focused record view, and each product has its own workspace with summary, plans, releases, customer setup and product-specific activity.

The screens were flattened at the same time: flat tabs, dividers instead of rounded cards, page-canvas layouts and quieter product artwork. Numeric page ID fields became WordPress page selectors, and the product, pricing, customer-page and release settings are grouped around the workflow each one belongs to rather than in one long list.

Release Preflight and Product Setup

Publishing a plugin or theme release now runs a preflight before anything is stored. It checks ZIP integrity, rejects unsafe archive paths, reads the plugin or theme header, compares the declared version, asks for confirmation before replacing an existing release and records a SHA-256 checksum.

Setting a product up got three helpers. Product icons come from the Media Library, with a fallback per product type across the admin and the public catalog. Product form generation is non-destructive: it creates a prewired checkout form and page for every active plan, plus a renewal form for a renewable product, and leaves anything you already had alone. And a Generate sample products action, safe to run more than once, creates a plugin, a theme and a digital-download example to learn the screens on.

Currency Routing and Native Checkout

Each currency routes to a gateway, with an ordered default and more than one compatible gateway allowed per currency, so a store can take USD through one provider and INR through another without a second form.

The native [cf_license_checkout] flow resolves the product and plan from the URL and takes the visitor through purchase without a stored Core Form. Product catalogs use this shared checkout. A generated Core Form is still there as an option for a page that needs custom fields, extra actions or a campaign-specific layout, and the optional generated forms keep plan-specific pages instead of forcing every plan through one product-level page.

The licensing Sample Forms grew optional phone, company, tax, billing-address, licensed-site and order-note fields, with mapped fulfillment and administrator-email actions, and there are gateway-specific product-purchase and software-license Sample Forms for Stripe, PayPal, Razorpay and Polar.

Blocks and Shortcodes

Seven dynamic blocks put a product on a page: a product catalog, a compact product list, a single product, a price, a buy button, the checkout and the customer dashboard. Four shortcodes cover the same ground, [cf_license_product_list], [cf_license_product], [cf_license_price] and [cf_license_buy_button], with product and plan attributes for native checkout and catalog filtering, limits, ordering and columns.

Every Core Forms block, form, poll and licensing alike, now sits in one Core Forms category in the inserter, and a complete block and shortcode reference lives in global Settings and on the Display tab of the licensing screens.

Commerce REST API and WordPress Abilities

A permissioned REST API covers products, plans, releases, orders, licenses, activations, subscriptions, download audits, events, sample generation, gateway status and currency routing. The same operations are registered as WordPress 6.9 Abilities with MCP discovery metadata, permission callbacks and behavioral annotations, so an agent or an automation tool can find and call them the way it calls core.

Neither route ever returns a gateway credential or a full license key.

Customer Access

The customer dashboard and the optional product catalog were reworked as responsive, theme-compatible pages backed by external assets. License and order pages show explicit status, relative dates and masked secrets, with accessible reveal, copy and confirmation controls.

A customer who has lost access asks for a fresh 30-day magic link by email. The request returns the same response for a known and an unknown address, so nobody can use the form to check which emails have an account, and it is throttled to one request every 5 minutes. Package downloads, activations, deactivations, renewals, cancellations, access emails, product edits and release publication all write non-secret operational events to the activity timeline.

Smaller Changes and Fixes

The product URL in the plugin header and the installation docs is https://core-forms.com.

The Patch Releases

Two patches in 5 days. 4.6.3 is the larger one and carries a schema repair, so read it if any of your forms started life as hand-written HTML.

4.6.2

July 25, 2026. A public, read-only Storefront REST API for static sites and external product embeds, exposing active-only product and plan data with resolved icons, hosted checkout URLs, filters, pagination, CORS, caching and ETags. The form skeleton and the default theme now load inside the Block Editor canvas, so the Core Form block preview matches the front end instead of rendering unstyled, and the form builder’s preview pane loads both stylesheets in the head so it paints styled on the first frame. That preview used to enqueue its stylesheets from a wp_head callback at priority 10, after core prints styles at priority 8, so they only ever reached the footer; and the preview request was not recognized as containing a form, which let the unused-asset cleanup dequeue the preview’s own styles; both are fixed. Also: the checkout-page rule above, every DOING_AJAX check replaced with wp_doing_ajax(), two orphaned admin methods removed, several wrong PHPDoc return types corrected and the licensing maintenance cron no longer returns its summary array to do_action().

4.6.3

July 27, 2026. Beyond the renames, three groups of fixes:

Licensing. License heartbeats send the canonical site URL and runtime versions, so the account service repairs a missing activation record during normal validation; this fixes licensed sites that kept validating and downloading updates without appearing in the customer’s Active sites list. Activation and deactivation retry once after a transient failure, and a failed remote deactivation no longer erases the locally stored key, so an administrator can retry without creating an orphaned activation.

Validation. Required and email fields are derived from the stored schema or the legacy HTML attributes for server-side validation, while explicit legacy field lists still work. Same-name checkbox and radio inputs were being converted into duplicate schema fields with no options and duplicate IDs; an explicit empty <option value=""> was being replaced by its visible label, which let a required select placeholder pass; and invalid submissions were being stored in the inbox and consuming the visitor’s successful-submission rate limit. All fixed, and a migration repairs existing schemas that carry the affected legacy-parser signatures without touching custom layouts or unrelated fields.

Headless and mail. Headless REST validation and provider failures returned HTTP 200 because the adapter checked an error_code key the processor never emits; they return 422 now. Headless submissions work with global nonce enforcement on, JSON array field names normalize to the same keys PHP produces for a regular post, and field descriptions use the canonical schema with grouped options intact. Emailit v2 sends and subscriptions were logged as failed when the API correctly answered HTTP 200 instead of the hard-coded 201. The redundant one-page table footer in Core Commerce is gone, and real multi-page footers stay flat.

The Limits

The public Storefront API lists. It does not sell. Checkout still happens on the WordPress site through the hosted checkout URLs the API hands back.

The native checkout handles a product and a plan. A page that needs extra fields, a coupon question or a different action after purchase goes through a generated Core Form, which is why those forms stayed.

A magic link is the only recovery route for a customer dashboard, and it expires in 30 days. A customer who lets one expire asks for another, 5 minutes apart at most.

Docs and Links

Core Forms 4.6 in the changelog, with both patches beneath it.
Products, licenses and subscriptions and customers, orders and activated sites.
Product pages, blocks and shortcodes.
Integrating license keys and automatic updates into your own plugin or theme.
The previous release, Core Forms 4.5.

Final Remarks

If you have updated, the licensing side of Core Forms reads like the rest of WordPress, a product has one page that shows everything about it, and a customer can get back into their dashboard without emailing you. The idea to keep is that a commerce admin should show the next thing to do, not a row of counts, and the overview was rebuilt on exactly that.

If you are about to sell your first product through it, I would do three things first. Run Generate sample products on a staging site first, because the screens make more sense with records in them. Set the currency routing before enabling a second gateway, so the first INR order does not land at a USD-only provider. And upload one release with a deliberately wrong version number to see what the preflight catches, then upload the real one.

The licensing guides walk through products, customers and the update integration, and the support page is open for anything the guides do not answer.

That is everything in 4.6. I hope the first order goes through without you watching it.

Core Forms 4.6