Close Forms After X Entries: safe setup, failure cases, and rollback

Direct answer

To close a WPForms form after a fixed number of entries, count only submissions that WPForms reports as successfully completed, reserve the final available slot atomically before side effects, and check the limit again when a cached form is submitted. Do not use IP addresses, cookies, email fields, or stored entry contents when the job is a site-wide total limit.

StoreFixKit's Close Forms After X Entries follows that narrow model. Free limits one WPForms Lite form. Pro adds more form limits, optional spots-left text, and an administrator reset. Neither version reads submitted fields or edits WPForms entries.

Total entry limits are not per-person limits

A total limit answers a simple question: how many successful submissions may this form accept altogether? Common examples include event seats, beta access, contest entries, limited consultations, volunteer slots, and preorder-interest forms.

A per-person limit is a different job. It usually needs an identifier such as an account, email address, IP address, or cookie and therefore introduces privacy, shared-device, proxy, deletion, and bypass questions. A schedule is also different: it closes by time, not by successful count. Spam prevention is different again.

WPForms documents these separate controls in its official Form Locker Addon guide. That guide includes total entry limits, user entry limits, schedules, password protection, and unique-answer rules. The existence of several controls is precisely why a small plugin should state which one it implements instead of presenting every restriction as the same feature.

What should count as successful

WPForms documents wpforms_process_complete as the action fired at the end of successful form processing, after entry saving and email notifications, and says it does not fire for submissions containing errors. Its developer hook reference also notes that WPForms Lite can provide an entry ID of zero when entry storage is disabled.

That creates two important rules. First, the plugin cannot use a positive entry ID as the definition of success because WPForms Lite may complete successfully without one. Second, it cannot simply increment at the beginning of every POST because validation and processing may still fail.

StoreFixKit therefore reserves capacity before WPForms side effects, then commits the reservation only when WPForms reaches successful completion. If later processing fails, the pending reservation is released. The plugin does not need names, emails, field IDs, or entry records to do this.

Why the final slot needs an atomic reservation

Suppose the limit is 100 and the stored count is 99. Two visitors submit at nearly the same moment. A naive sequence that reads 99, decides a slot exists, and later writes 100 can allow both requests through. The form has accepted 101 successful submissions even though each request individually saw 99.

An atomic reservation combines the condition and increment in one database operation. Only one request can move the count from 99 to 100. The other request sees that no slot remains and receives the closed message before WPForms performs its normal submission side effects.

This does not require a custom table or background queue for a small site-wide counter. It does require a bounded integer, a single owner, a clear failure state, and an integration test that sends simultaneous final-slot requests.

Cached pages need a second server check

A full-page cache or CDN may continue serving HTML that contains the form after another visitor takes the final slot. Hiding the form during page rendering is useful but cannot be the security boundary.

The submitted request must check the current server counter again. When the limit is already reached, the plugin should stop the request before WPForms saves an entry or sends notifications and return the same plain closed message. Purging the page cache improves the visible experience, but correctness cannot depend on a purge arriving in time.

A beginner setup that can be verified

Create or choose the WPForms Lite form first. Send one ordinary successful test without a limit so its validation and notification flow are known to work. Then open WPForms > Entry Limit, choose the form, enter a small test limit such as two, write the closed message, enable the rule, and save.

Submit once and confirm the form remains open. Submit the second successful entry and refresh the page. The form should be replaced by the closed message. Open an old cached copy or second tab and try one more submission; the server should reject it without producing another successful WPForms completion.

The complete controls and rollback steps are in the Close Forms After X Entries documentation.

What the counter should not do

It should not query or copy WPForms entry records to decide the current count. That would make behavior depend on whether the edition stores entries, whether records were imported or deleted, and whether personal submission data is available.

It should not inspect field values to identify duplicates. It should not store IP addresses or cookies. It should not edit forms, confirmations, notifications, email delivery, user accounts, or published pages.

It should also avoid catalog-wide work on unrelated requests. One selected form ID and one autoload-disabled counter are enough for the free workflow. No frontend JavaScript, stylesheet, scheduled job, telemetry, or StoreFixKit request is necessary.

Failure behavior matters more than a clever counter

If WPForms is missing, no processing hooks should run. If the selected form no longer exists, unrelated forms should remain open and the administrator should receive a precise warning. If the counter is malformed or the atomic update cannot be proven, the plugin should not mutate uncertain state.

StoreFixKit chooses fail-passive behavior for that uncertain case: leave the form open and avoid an unprovable count write. That choice may accept an extra submission during a database fault, but it avoids silently blocking a legitimate form based on damaged state. The tradeoff is explicit and can be monitored.

Testing checklist

Below the limit

Submit valid data and confirm WPForms completes normally. The counter should increase exactly once.

Validation error

Submit missing or invalid required fields. The counter must not become committed.

Processing failure

Trigger a controlled later failure in a test environment. The pending reservation should be released and the original WPForms error should remain visible.

Simultaneous final slot

Set the counter one below the limit and send parallel requests. Exactly one reservation may succeed.

Cached form

Load the form before the limit, reach the limit in another tab, then submit the old page. The server must reject it before normal success side effects.

Missing dependency

Deactivate WPForms with StoreFixKit still active. WordPress must keep loading without a fatal error, and reactivating WPForms must restore the configured workflow.

Update and rollback

Install the current version, save a rule and count, downgrade to the previous ZIP, and move forward again. The valid owned state must remain readable throughout.

Privacy, security, and support evidence

WordPress settings writes should use capability checks, nonces, input validation, and late output escaping. The official WordPress Settings API guide explains the built-in form handling and nonce protections, while the Plugin Handbook security guidance covers capabilities, sanitizing, and escaping.

For support, the useful evidence is the form ID, configured limit, StoreFixKit count, WPForms and plugin versions, whether the submission reached successful completion, cache/CDN name, and screenshots. Submitted names, email addresses, messages, credentials, and full license keys are neither necessary nor appropriate.

Rollback boundary

A focused entry-limit plugin owns only its settings and counters. Rolling it back or uninstalling it should never rebuild, delete, or renumber WPForms forms and entries. Keep previous ZIPs and a database backup, activate Free before Pro, and test below-limit and at-limit paths after the change.

FAQ

Does a failed WPForms submission use a spot?

No. StoreFixKit commits the reserved slot only after WPForms reports successful completion. Validation and processing failures do not become committed entries.

Does it work with WPForms Lite when entries are not stored?

Yes. The integration uses WPForms' successful completion boundary and does not require a positive stored entry ID or access to submitted fields.

Can it limit one email address or IP address?

No. This plugin implements a total form limit. Per-person restrictions need identifiers and a separate privacy and bypass model.

Can two visitors take the final spot?

The counter uses an atomic reservation so only one request can reserve the final available slot. The concurrency case is part of the release test suite.

What happens when a cached page still shows the form?

The request is checked again server-side. A late submission receives the configured closed message before WPForms completes its normal side effects.

Does Pro replace the free rule?

No. Free keeps the first valid form limit. Pro adds capacity, spots-left text, and authorized resets; a license or network failure cannot disable the free rule.