Core Forms 4.4 is out as of July 12, 2026, and it is the largest release since 4.0. It carries everything that was planned for 4.4 and 4.5 on the roadmap in one build. The change most people will notice depends on what they sell: a Stripe card field inline on the form instead of a redirect, or a complete licensing and ecommerce system for anyone who sells a plugin, a theme or a download from their own site.

This post covers the release and the 3 patch releases that followed through July 17, one of which, 4.4.2, is a security release. Nothing changes for a form that already exists. The update creates a sample product on every site, and the next section says what to do with it.

You will find the update under Dashboard, then Updates. The raw list is in the changelog, and the support page is open for anything that does not line up with this post.

Before You Update

A Sample Product with free, USD annual and INR annual plans is created on new and upgraded sites. It is a placeholder so the licensing screens have something to show. Edit it into a real product or delete it before you publish a catalog page.
Licensing actions are always visible in the Add Action picker under a Commerce & Licensing category. They used to disappear when the public activation API was off.
Plan prices are entered in customer-facing units, 49.00 rather than 4900. Anything that scripts plan creation needs to send the new shape.
The way Core Forms itself gets its updates, through the CF Licenser client and the 32-character key, is unchanged and separate from the new merchant licensing. The two do not share options or tables.

What’s New in Core Forms 4.4

Seven areas changed, and they group into two halves, money and speed. The first five are about selling and connecting, and the last two are about the editor getting out of your way.

Inline Stripe Checkout

Stripe’s Payment Element now renders inline on the form. The visitor enters the card without leaving the page, the price comes from the server-owned product record rather than from anything in the browser, the PaymentIntent is created idempotently and the charge is confirmed by a signed webhook, the same way the hosted flow has worked since 4.1.

Razorpay became a first-class hosted gateway in the same release, with payment-link creation, captured-payment handling and failure, cancellation and refund handling all correlated back to the submission.

Three fulfillment fixes landed with it. A paid plan can no longer be fulfilled from a form that has no payment step, or before the payment is verified. A mismatched paid amount or currency is rejected when validation is on. And a free plan is no longer tied to a payment requirement it does not need.

Licensing and Lightweight Ecommerce

This is the piece a plugin or theme author has been asking for: sell your own software from your own WordPress site, with Core Forms handling the keys.

Products, plans, orders, subscriptions, customer accounts, activation limits, refunds and renewals.
Signed, audited downloads. A package link expires, the stored SHA-256 digest is verified before the file streams, and every download is recorded in an audit table.
A customer dashboard with orders, masked keys that can be revealed, product downloads, activated sites and subscription controls.
Check, activate, deactivate and version endpoints compatible with EDD Software Licensing, so a plugin already written against that client keeps working. Existing issue_license form actions remain compatible.
Free, Stripe, Razorpay and renewal license-form templates with the payment and fulfillment actions already wired.
WP-CLI commands for product and plan administration, license reporting, order reporting and expiry maintenance.
Product and plan slugs generate on their own, normalized and unique, with manual slugs still accepted. Packages use the Media Library picker instead of an attachment ID, and the licensing screens show catalog statistics, quick-start guidance and direct Add plan and Add package links.

Two rules underneath it are worth knowing. Fulfillment is idempotent per submission and product, so a webhook retry cannot issue a second key. And a verified refund disables the license and cancels the related subscription without anyone doing it by hand.

14 New Native Integrations

Each of these is a native action, not a webhook you wire yourself:

Commerce: WooCommerce draft orders with a checkout handoff, Easy Digital Downloads customers, orders and lead-magnet discounts, SureCart customer and checkout with a customer-portal helper, and a WP Simple Pay handoff.
Memberships: MemberPress transactions, LearnDash course and group enrollment, and Paid Memberships Pro levels with user-meta mapping.
CRM: Groundhogg, Jetpack CRM, WP-CRM System and SureContact, with contact, tag, funnel, opportunity, list and field mapping as far as each destination supports it.
Automation: AutomatorWP and Uncanny Automator triggers and actions carrying the form and submission payloads, and an OttoKit trigger plus a submit-form action.

Inbound WhatsApp Conversations

The WhatsApp actions from 4.2 sent messages out. 4.4 brings replies back in. Signed inbound webhooks for the Meta Cloud API and Twilio append a customer’s reply and the delivery state to the submission that started the conversation, so the thread lives in the inbox next to the form data. A webhook without a valid provider signature cannot change anything.

Importers and WP-CLI

Ninja Forms and Formidable Forms join Contact Form 7, Gravity Forms, WPForms and Fluent Forms as one-click import sources. On the command line, wp core-forms now covers form import, export and listing, and submission maintenance, alongside the commerce commands above.

Bricks, Elementor and the Accessibility Audit

Bricks gets a native element and Elementor gets a native widget, so a site on either builder places a form the way it places everything else instead of through a shortcode.

Every form also gets a WCAG 2.2 audit inside the builder, with conservative one-click repairs for the findings that can be fixed without changing what the form means. The rest are reported for you to decide.

A Faster Form Editor

The form editor used to execute every tab’s PHP, JavaScript, analytics and REST requests on every load. It now renders only the active tab. The visual builder boots from server-rendered form and schema data, which removes the 2 blocking REST requests it made at start, and a builder save writes markup and schema atomically through one endpoint with a bounded timeout and a standard form-post fallback.

Tab-specific saves merge with the existing settings, so saving Fields or Messages no longer overwrites the payment and action configuration on the other tabs. The indefinite loading spinner that appeared when either initial request stalled is gone with the requests that caused it, inactive Analytics requests no longer run on unrelated tabs, and the action-variable panel no longer shows a permanent Loading message when the Fields builder is not on the page. Admin stylesheets and the licensing script are versioned from their file modification time, so a stale cache cannot serve last week’s CSS against this week’s markup.

The Patch Releases

Three patches in 5 days. 4.4.2 is the one to install on any public form.

4.4.1

July 12, 2026. The Core Form block preview took about 60 seconds to load on a busy editor screen, because it went through WordPress’s generic server-render request. It now uses a focused Core Forms preview endpoint, a summary-only form selector and shared request caching across block instances, so a page with several forms does the work once.

4.4.2

July 16, 2026. A security release around submission size and file handling:

Server-side limits before any hook, database write or notification runs: a 254-character email limit, enforcement of each field’s declared maxlength, rejection of nested values and a hard 60 KiB ceiling on the encoded submission.
Rendered email inputs get a browser-level 254-character default while smaller form-specific limits are preserved.
Multipart file uploads are restored, including documented multiple-file inputs, by normalizing PHP’s $_FILES data into the submission pipeline. File bytes stay under the separate upload-size control and do not count toward the 60 KiB ceiling.
Invalid or spammed submissions no longer move files or keep temporary upload paths.
The per-form rate limiter read the unused submit_rate_limit key instead of the saved rate_limit setting, and its hourly counter expired after one minute. Both are fixed, and the throttled response is now visible to the AJAX client instead of failing silently.

4.4.3

July 17, 2026. The Send Email, Auto-Responder and Emailit action cards listed no field variables for the current form, because the old JavaScript that populated them only loaded on the Fields tab. The variables are now rendered on the server, array field names are normalized, duplicates are removed and internal fields stay out of the list.

The Limits

The inline Payment Element is Stripe only. PayPal, Razorpay and Polar.sh remain hosted checkout, where the visitor leaves the page to pay.

The licensing system is for products you sell. It runs beside the CF Licenser that licenses Core Forms itself, and the two are separate by design, which means a site that sells software has two licensing systems in its database.

The accessibility audit repairs what it can change safely and reports the rest. A missing label it can add. A color contrast problem in your theme it can only point at.

Docs and Links

Core Forms 4.4 in the changelog, with the three patches beneath it.
Licensing and commerce, the guide to products, plans and subscriptions, and licensing on the features page.
Stripe and Razorpay.
Bricks, Elementor and the accessibility audit.
WhatsApp inbound replies.
The previous release, Core Forms 4.3.

Final Remarks

If you have updated, one plugin can now be the storefront for a small software business, and the editor you spend your time in loads one tab instead of all of them. The idea to keep is that every money path in this release is confirmed by a signature and made idempotent, so a retry, a refresh or a replay cannot create a second order or a second key.

If you are setting up licensing for the first time, three things are worth doing before the first sale. Decide each plan’s activation limit now, because changing it after keys are in the wild means explaining it to customers. Run the accessibility audit on the checkout form first, since that is the form money passes through. And keep the sample product until you have watched one test order go from form to key to download, then delete it.

The licensing guide covers products, plans and the customer dashboard step by step, and the support page is where a first sale that went sideways should go.

That is the whole of 4.4. I hope it pays for itself.

Core Forms 4.4