WPForms Form Locker - WordPress Plugin

A Practical Guide to Configuring WPForms Form Locker for Private and Limited-Access Forms

WPForms Form Locker is not used to build the form itself. Its job is to control who can see the form and when they can submit it. In this guide, we will walk through how to use the addon in a real WordPress project: where the settings live, how password protection, age verification, email verification, scheduling, entry limits, and unique responses differ from each other, how to verify the result on the live site, and how to quickly identify the cause if the form closes in a way you did not expect.

This article is written for site administrators, editors, support staff, or project owners who already understand the basics of working with WPForms but want to restrict submissions in a controlled way. It does not cover license purchases or activation workarounds. The focus here is on properly configuring a plugin you already have access to and safely validating the result.

The core idea is simple: the access rule should match the form's business scenario. A password works well for a private form shared by link, scheduling works for submissions that should only be accepted during a defined time window, a total limit fits an event with a fixed number of seats, a unique email helps prevent duplicate registrations, and the "logged in users only" mode works well for member areas, courses, and internal requests.

At the end of the guide, you will find a troubleshooting section, an FAQ, a comparison with similar solutions, and a natural download link. If you have never used Form Locker before, do not enable every restriction at once. Start with one testable requirement, configure it on a test form, and only then apply the same setup to an important form that receives real submissions.

What Problem Form Locking Solves in WordPress

A standard form on a website will accept any valid submission as long as the visitor can see the fields and passes the basic validation. That is enough for contact forms, feedback forms, or simple requests. But as soon as a form becomes part of a restricted workflow, other questions come up: who is allowed to open it, when submissions should begin, when they should end, how many entries can be accepted, whether the same request can be submitted more than once, and what the visitor should see instead of the form if the condition is not met.

WPForms Form Locker adds a rules layer to the form. That layer does not replace fields, notifications, confirmations, or spam protection. It works alongside them. The user encounters an access condition or limit first. If the condition is satisfied, they see the form and submit it normally. If the condition is not satisfied, the form is replaced with a message, a verification field, or an error state.

This approach is especially useful when you do not need a full membership system but do need precise control over a single form. For example, a school may accept course applications only until a certain date, a service company may show a client form only to logged-in users, an event organizer may cap registration by the number of available seats, and a store may run a private giveaway for subscribers using one-time email access.

It is important not to mistake Form Locker for a universal site security tool. It does not make the entire page private, it does not replace WordPress roles, it does not encrypt submitted data, and it does not solve every spam issue. Its scope is narrower: restrict access to a specific form and reduce unnecessary or duplicate submissions. To protect against automated submissions, you still need WPForms built-in anti-spam checks, CAPTCHA or Turnstile, properly configured notifications, reliable email delivery, and careful handling of personal data.

Who WPForms Form Locker Is For, and When Another Approach Makes More Sense

This addon is a good fit for sites that already build forms with WPForms and need to add restrictions without custom development. Natural use cases include event registration, contest entries, private client forms, internal employee forms, beta access requests, age-gated forms, limited surveys, waitlists, or contact forms that should not be visible to every visitor.

One of Form Locker's strengths is that its settings are built directly into the form builder. An administrator does not have to hunt across the site for a separate access-rules page. Open the form, go to Settings, then Form Locker, enable the mode you need, and write the message visitors should see. That lowers the risk of forgetting which rule belongs to which form.

The addon may not be the right fit if access depends on a complex system of roles, subscriptions, purchased products, membership levels, an external CRM, or multiple related conditions. In projects like that, Form Locker can still work as an extra filter, but the main access architecture should usually be built around a membership plugin, an LMS, a WooCommerce membership solution, custom roles, or separate application logic.

Another case that requires extra care is forms that collect legally sensitive data. Age verification or password protection does not make the process legally compliant by itself. If the form collects medical, financial, children's, or other sensitive information, review your privacy policy, consent flow, data retention period, and who can access entries. Form Locker controls entry to the form, but it does not replace the legal and technical framework for handling data.

Practical takeaway: use WPForms Form Locker when you need to restrict one specific form using a clear rule. If you need to control access to an entire section of the site, user profiles, subscriptions, or complex permissions, use purpose-built tools instead of trying to push the whole job onto one addon.

What to Check Before Installing and Enabling the Addon

Before you configure Form Locker, it is worth spending a few minutes on preparation. That usually saves far more time than troubleshooting strange form behavior on a live page later.

License, WPForms Base Setup, and Where the Settings Live

The official documentation says that Form Locker is available with WPForms Pro or higher. It is also important that WPForms itself is installed, activated, and compatible with the addon's minimum requirements. This article does not list specific version numbers because they change over time, and you should verify them against the current addon screen and the developer's documentation.

Check these three things:

• WPForms is active and the license is validated in the WordPress admin area.
• The Form Locker Addon is visible under WPForms > Addons.
• You know exactly which form you plan to restrict and you have permission to edit it.

If the addon does not appear, the official instructions recommend refreshing the addon list with Refresh Addons. If automatic installation fails, WPForms also documents a manual option that uses the ZIP file from your account and the standard WordPress plugin installation flow. In a normal workflow, it is better to exhaust the built-in installation method in WPForms > Addons first and keep the manual upload as a fallback.

The Form Scenario Before You Turn On Restrictions

Do not start with toggles. First, write the rule in plain language: "the form stays open until all 40 spots are filled," "the form is visible only to logged-in users," "each email can only be used once," or "the form opens after submissions officially begin." If you cannot explain the rule in one sentence, there is a good chance you are trying to solve something too complex with a single Form Locker screen.

Test the form itself without restrictions first: fields, required logic, notifications, post-submit confirmation, entry storage, anti-spam, and the page where the form is embedded. Locking should be enabled only on a form that already works. Otherwise, when something breaks during testing, it will be unclear whether the problem is the access rule, a notification, email delivery, cache, CAPTCHA, or the form itself.

Cache, User Roles, and Test Browsers

For forms that use scheduling, closed-state messages, or different behavior for logged-in users and guests, cache behavior and testing in different sessions matter a lot. If the page is cached too aggressively, visitors may see an outdated state. That does not automatically mean Form Locker conflicts with caching, but you should test the setup in a private browser window, in a guest session, and with a dedicated test user.

For the "logged in users only" mode, prepare at least two checks: one user logged into WordPress and one visitor browsing as a guest. For email verification, make sure the site can send mail, or the visitor will never be able to follow the confirmation link. For limits and unique responses, decide in advance how you will clear test entries or whether you will use a separate test form.

Installation and the First Validation in the Admin Area

Installing Form Locker usually starts in WPForms > Addons. Find the addon by name, click Install Addon, and wait for it to show as active. After that, its settings appear not as a separate large module, but inside each specific form.

Open an existing form or create a new one. In the builder, go to Settings > Form Locker. This is where the main groups of rules live. If the menu item is missing, check whether the addon is active, whether the license is valid, whether WPForms is up to date, and whether the current administrator account has the required permissions.

Your first validation should be simple:

1. Create a test form with Name and Email fields.
2. Publish it on a test page that can be opened without exposing it to real visitors.
3. Submit one normal entry without restrictions and confirm that it appears in WPForms > Entries.
4. Enable one Form Locker rule, such as a password or a total entry limit.
5. Save the form and test the published page in a private window.

This sequence may feel slow, but it eliminates extra variables. If the basic form is not sending notifications, Form Locker will not fix your email delivery. If the form is not embedded on a page, there is nothing for the access rule to control. If the form works without restrictions, then after you enable one rule, you can clearly see which part of the behavior changed.

After installation, do not immediately enable password protection, scheduling, per-user limits, and unique responses all at once. Those combinations can work, but they are harder for visitors to understand and harder for you to test. Start with the main restriction, get predictable behavior, and only add a second layer if you truly need it.

Form Locker Settings Map: What Each Option Does and What Result to Expect

Form Locker includes several different types of restrictions. They are similar in that they all affect access to the form, but they trigger at different moments and solve different problems. If you understand that map in advance, you are much less likely to choose a setting that sounds right but does not actually fit the job.

The most common mistake is choosing a mode based on its label instead of the moment when it is evaluated. For example, a unique field response and a per-user email limit may look similar, but they are used differently. A unique answer checks the specific field value against the entry database. A user limit restricts how many submissions one person can make based on the selected identifier and time period. For a contest rule like "one email, one entry," either approach might seem reasonable, but in practice it is better to choose one primary mechanism so the visitor sees a clear error and the administrator knows where to look when something goes wrong.

There is another important detail here: messaging. Form Locker should not fail silently. For every rule, write text that explains the current state: the form is not open yet, submissions are closed, login is required, a confirmation link has been sent, or the submission limit has been reached. A good closed-state message reduces support load because the visitor understands what happened and whether there is a next step.

Access Verification: Password, Age, and Email

The Form Verification group handles scenarios where a visitor must complete an extra step before they can view the form. This is not the form submission itself. It is a gate that appears before the form. WPForms documents three verification types: Password, Age, and Email.

Password Protection for Private Links and Client Forms

A password works well when the form is meant for a limited audience but you do not want to require those users to create a WordPress account. Typical examples include a client upload form, a private webinar request, an internal partner form, or a project brief that is only shared with someone by email from a manager.

In the settings, enable Enable verification, select the Password type, set the password, and write the message shown above the field. That message should read like an instruction, not a riddle: "Enter the access code from the organizer's email." Do not include the password itself in the message. Also, do not reuse the same simple password across different forms if those forms open access to different workflows.

After saving, test three states: the page before any password is entered, the page after the correct password is entered, and the error shown after an incorrect password. If the visitor enters the correct password and sees the form, the rule is working. If the form appears immediately without any check, you are probably looking at a cached page, browsing in an admin session with a different state, or testing a form that was not saved.

Age Verification Without Overpromising

The Age type asks the visitor for a date of birth and compares the resulting age against your rule. In the settings, you can define the target value and choose the comparison logic: minimum age, exact age, or maximum age. In practice, minimum age is the most common use case.

This mode makes sense when access should be gated by an age threshold. But it is important to understand the limitation: the user enters the date manually. This is not document verification and it is not a legal guarantee. Write the message carefully and do not imply a stronger level of validation than the mechanism actually provides.

Test boundary values. If your rule is a minimum age, check one date that should pass and one that should be rejected. If the error message is not a good fit for the tone of the site, review the validation-message documentation and adjust the text using the standard method, or with a small safe code snippet only if you actually need that level of control.

Email Verification as a Pre-Form Filter

The Email type asks the visitor to enter an email address, sends a message with a link, and opens the form only after the visitor follows that link. This is useful when you want to confirm that the visitor actually controls the mailbox before they are allowed to access the form.

Before enabling this mode, test mail delivery. If your WordPress site is not sending messages properly, or if they regularly land in spam, email verification becomes a barrier for the very people you want to let in. A proper test should include a real email address, delivery of the message, the confirmation click, and the form opening afterward.

Do not rely on email verification as your only protection against automated junk. It can reduce casual or low-quality submissions, but on public forms with heavier traffic, it is better used together with WPForms anti-spam settings, Cloudflare Turnstile, or another CAPTCHA solution when appropriate for the site.

Scheduling and Entry Limits: How to Close a Form Without Manual Oversight

The most practical part of WPForms Form Locker is automatic opening and closing. For events, contests, consultation bookings, cohort enrollments, and limited offers, this is often more important than password protection. The administrator sets the rules once, and the form changes state on its own.

Scheduling Access

The Form scheduling mode lets you define a start date and time, an end date and time, and a closed-state message. WPForms documentation specifically notes that you can set only a start date or only an end date if needed. That is useful because some forms should open later without a fixed closing date, while others are already open and only need to shut off at a specific moment.

The biggest scheduling risk is an incorrect assumption about time zones. WordPress uses the site's own settings, while visitors may be in different regions. Because of that, your message should use clear human language: "Submissions will open at the time provided by the organizer" or "This form is closed because the submission period has ended." If exact timing matters, verify the WordPress time zone before launch.

Total Entry Limit

Enable total entry limit closes the form after a specified number of entries. This works well when there is a fixed number of available spots. For example, if you are accepting signups for a workshop with 30 seats, the visitor will see the closed message instead of the form once the limit is reached.

Wording matters here. Do not write "only a few spots left" unless you are actually showing a live remaining count. By default, Form Locker can close the form based on the limit, but it does not have to display a real-time counter to visitors. WPForms developer documentation includes an example for showing the remaining number via PHP, but even there it is clearly noted that the number is calculated when the form loads and may change before the person submits. Because of that, for public-facing use it is safer to write something like: "Availability is limited. The form will close automatically once all spots are filled."

Per-User Limit

Enable user entry limit restricts repeat submissions from the same person. The documentation describes limits based on IP, email, or both. If you choose email, you also need to specify which form field contains the user's address. You can then set how many submissions are allowed and for what period: until the end of the day, week, month, or year, or relative intervals such as 24 hours or 7 days.

The best identifier depends on the scenario. IP can help stop simple repeat attempts, but it is not perfect: several people may share one network, and one person may switch networks. Email is usually a better choice for registration when the email field is required and meaningful. Combining IP and email is stricter, but it may also create more false blocks. For a form used by real customers, start with an email-based limit if the goal is one submission per person, and add IP only when you have a clear reason.

Every limit should include text for the visitor. Good text does not blame the user or read like a technical failure. For example: "A submission has already been received for this email address. If you need to update your details, contact the organizer." That is much better than a bare "Limit reached" because it tells the user what to do next.

Unique Field Responses: When They Are Better Than a Per-User Limit

The Require unique answer feature is not located on the main Form Locker screen. It lives in the settings for a specific field. Open the field in the form preview area, switch to the Advanced tab, and enable unique answer enforcement. WPForms documentation lists the supported field types as Name, Email, Phone, Website, Password, and Single Line Text.

The difference from a per-user limit is that uniqueness is tied to the field value itself. If an email address already exists in the submitted entries for that form, a new submission with the same email will be rejected with a validation message. This is useful for coupon claims, registrations, one-vote-per-email surveys, or forms where the unique identifier is not the WordPress user account but a specific submitted value.

But uniqueness does not solve everything. If the same person uses a different email address, the rule will not know it is the same participant. If a family shares one email address, the second legitimate participant may be blocked. If an administrator deletes an old entry, the behavior can change because the check depends on existing submissions. So a unique field works best when you accept the rule honestly: the unique thing is the field value itself, not the real-world person behind it.

How to Choose the Right Field for Uniqueness

For most registration forms, use Email. For forms that rely on a participant number or coupon code, Single Line Text may be more appropriate. Phone numbers are trickier because people may enter the same number in different formats. Before launch, guide users toward a consistent format with an input mask, a placeholder, or a short note.

Do not enable uniqueness on a field where natural duplicates are expected. Name, city, job title, or company name are rarely good candidates for a hard uniqueness rule. The unique field should correspond to an identifier that genuinely should not repeat.

Validation Message and UX

By default, WPForms uses a message that tells the user the value must be unique. On a site serving Russian-language users, it makes sense to replace that with clearer wording, and the same principle applies to any site where you want a better message. Global validation messages can be configured using the built-in settings, and for individual forms WPForms publishes developer documentation showing how to change a specific message. Use code only when the global setting is not enough and you understand how to add a snippet safely through Code Snippets or a child theme.

Do not edit plugin files directly. Any change inside the plugin folder can be overwritten during an update and will make support harder. If you need a very specific error message, check the standard WPForms settings first, then a safe snippet, not a core file edit.

How to Combine Multiple Rules Without Confusing Visitors or Support

Form Locker lets you enable multiple restrictions on a single form, but that does not mean every form should become a complicated gateway. The more rules that run before submission, the more pressure you put on support: one user is not logged in, another arrived before the form opened, a third used an email that is already taken, a fourth never got the verification email, and a fifth is seeing the closed message because the total limit was reached. All of those states may be valid, but if your team does not understand the order, every one of them looks like a bug.

A good combination starts with one primary rule. For a client form, that is usually a password or account login. For an event, it is scheduling and a total limit. For a contest, it is usually a unique email or one-submission-per-user logic. For age-gated access, it is age verification. Add other rules only when they cover a separate risk. If the second rule does not change the actual outcome, do not enable it just to feel more secure.

The Thought Process Before You Enable a Combination

Before turning on multiple restrictions, describe the visitor journey in one paragraph. For example: "The participant logs into their account, opens the form during the registration period, submits one registration with a unique email, and after all seats are filled sees a closed message." That sentence already establishes the order: login, schedule, uniqueness, total limit. If your description starts to include "and just in case" logic, stop and check whether the extra rule is truly needed.

Then define what message the person should see in each failure state. For a guest, prompt them to log in. For someone who arrives too early, explain that registration has not opened yet. For a late visitor, explain that registration is closed. For a repeated email, explain that a submission already exists and where they should write if they need a correction. For a full limit, explain that no spots remain. Once those messages are written out, it becomes much easier to see which rules are duplicating each other.

Do not make all messages identical. If every state says "form unavailable," the visitor has no idea whether they can fix the issue. Precise wording improves the user experience and helps support. When someone writes, "I see the message about a duplicate email," the team immediately knows that uniqueness or the email-based limit fired, not scheduling or password protection.

Examples of Good Combinations

For a private webinar, a combination of Logged in users only and Form scheduling makes sense. The first rule filters out random guests, and the second automatically closes registration after the deadline. A unique email can be added if one account could otherwise submit multiple registrations with different details. A total limit only matters when seats are actually limited.

For a client brief, Password is often enough. If the client already works through a member portal, the password can be replaced with Logged in users only. There is usually no reason to require a password, account login, and email verification at the same time unless the form is part of an especially sensitive process. That kind of stack makes the path harder for legitimate users and rarely adds real value if the password is sent through the same email address that later receives the confirmation link.

For a one-entry-per-person contest, a unique email works well. If the contest is open only to subscribers or community members, you can add account login. If the contest runs only during a strict time window, add scheduling. But do not rely on IP alone as your definition of "one person": offices, classrooms, coworking spaces, and home networks can all produce one IP address for multiple legitimate participants.

For a form with a limited number of consultation slots, a total limit is the key rule. If consultations are assigned manually after submission, do not promise a confirmed slot before a manager reviews the request. In that scenario, the post-submit confirmation text matters more than a counter: "Your request has been received. A manager will confirm the time separately" is more honest than an automatic promise of a booking.

Examples of Combinations That Can Cause Problems

One overly strict combination is email verification before the form, plus a unique email field, plus an email-based user limit. That may be justified in rare cases, but in most projects it creates three separate places where email can trigger a block. If the verification email never arrives, the user never even sees the form. If the user passes verification but the email field matches an old entry, they see a validation error. And if uniqueness does not trigger first, the limit may. That is difficult for support to explain.

Another questionable combination is password protection plus logged-in-user access on a standard client contact form. If the client is already logged in, the password is often unnecessary. If the client does not know how to log in, the password does not solve the underlying permissions issue. That setup only makes sense when there are genuinely two different access boundaries: the account confirms access to the client portal, and the password opens one specific temporary workflow inside it.

Scheduling plus manually removing the form from the page can also conflict. If an editor deletes the form block after the submission window ends, visitors never see the planned Form Locker message. It is usually better to leave the form in place and let the addon show a clear closed-state explanation. Removing the form only makes sense when the entire section is no longer relevant and there is no value in explaining the status.

How to Document Rules for the Team

For any important form, create a short internal reference card. It only needs the form ID, the published page, the enabled rules, the message texts, a test account, the expected state for a guest, the expected state for a logged-in user, and the person authorized to change the limit or schedule. This becomes especially helpful when multiple editors maintain the same site.

Example card:

• Form: workshop registration, form ID listed in WPForms.
• Page: public event page.
• Rules: logged-in users only, registration schedule, total seat limit, unique email.
• Guest sees: a message with a login link.
• Logged-in user during the active period sees: the registration form.
• After the limit is reached sees: a message saying all spots are filled.
• Repeat email sees: either an email-field error or a limit message, depending on the chosen mechanism.

The card does not replace WPForms documentation, but it translates settings into process language. When a complaint comes in, you compare it against the expected state matrix instead of relying on someone's memory.

How to Test a Combination Without Chaos

Test rules in layers. First, disable all restrictions and verify a normal submission. Then enable logged-in-user access and test both a guest and a test account. After that, enable scheduling and verify the state during the allowed window. Next, enable a small total limit on a test value and submit several entries. Finally, test the unique email rule or the per-user limit.

Each layer should have one expected outcome. If enabling a new layer breaks a different state, step back and retest. Do not move to the next layer until you understand the current one. A reliable Form Locker setup is not about turning on the maximum number of toggles, but about predictable behavior in every state.

After testing, do not forget to remove the temporary conditions. If you set the total limit to "2" during testing, restore the real value. If you used a temporary schedule, replace it with the production one. If you submitted test entries to a live form, decide whether those entries should remain in the records. For important workflows, it is usually safer to test on a duplicate form first, then recreate the proven configuration manually and test the published page again.

Practical Scenario: Registration for a Private Workshop with Limited Seats

Now let's build a concrete example that shows Form Locker's real value. Imagine an educational project website that accepts workshop registrations from registered participants. The form should open only during the right time window, accept a limited number of entries, prevent one email from claiming multiple spots, and show a clear message after registration closes.

Goal

We want a registration form that:

• Is available only to logged-in site users.
• Accepts submissions only during a defined time window.
• Closes after the overall seat limit is reached.
• Rejects repeat submissions from the same email.
• Shows a clear visitor-facing state instead of a generic technical error.

Preparation

Before touching Form Locker, build the form in WPForms. A minimal field set would be name, email, a choice of time slot or group, agreement to participation terms, and an optional comment. Configure the admin notification under Settings > Notifications and the post-submit confirmation under Settings > Confirmations. Submit one test entry without restrictions and confirm that it appears under WPForms > Entries.

Then prepare the page where the form will be embedded. If the page is cached, clear the cache after each change while testing. Do not test only from an admin tab where you are already logged into WordPress. Use a private window and a separate test account.

Configuration Steps

1. Open the form in the WPForms builder and go to Settings > Form Locker.
2. Enable Logged in users only and write the message guests should see. That message can include a login link if it fits your site's structure.
3. Enable Form scheduling. Set the start and end of the registration period. Keep the closed-state text neutral: "Registration is currently closed. Check with the organizer for updated information."
4. Enable Enable total entry limit, set the number of seats, and write the message shown after the limit is reached. Do not promise a seat before the form is submitted successfully.
5. Open the Email field, go to the Advanced tab, and enable Require unique answer if one email should be allowed to register only once.
6. Save the form, open the published page in a private window, and test the guest state, the logged-in user state, the first submission, and the repeat submission.

Validating the Result

Your validation should mirror the real participant journey. First, open the page as a guest: the form should be hidden or replaced with the message intended for users who are not logged in. Then log in with a test account: the form should appear if the schedule allows access and the limit has not been reached. Submit an entry and confirm that the record is created, the notification is sent, and the post-submit confirmation is displayed.

After that, try submitting again with the same email. If unique answers are enabled, the error should appear on the field. If an email-based user limit is enabled, the visitor should instead see the limit message. Both outcomes are valid, but you do not always need both in one scenario. If you enable both, document for support which message is expected to appear first.

A Note About Changing Conditions After Launch

If you need to increase the number of seats after launch, update the total limit and test the page again. If you need to open registration later, change the schedule instead of removing all rules. If a participant made a mistake in their email, handle that operationally: edit the record, delete a test submission, or accept a new request through a separate channel. Do not change rules at random while registration is active, because you can easily make the form more open than intended.

How to Confirm That Restrictions Work on the Published Page

With Form Locker, it is important to test not only inside the builder but also on the real page where visitors see the form. The configuration may be correct while publishing, caching, user role behavior, or email delivery creates a completely different impression on the front end.

Test with a State Matrix

For each form, create a small matrix. In the rows, list user states: guest, logged-in user, user who has already submitted. In the columns, list form states: before opening, during the active period, after closing, before the limit, after the limit. You do not need to test every possible combination for every small form, but for an important registration workflow this kind of matrix helps you catch obvious failures.

Minimum checks:

• A guest sees the correct message if access is restricted to logged-in users.
• A test user sees the form when the conditions allow access.
• An incorrect password or invalid age shows a clear error.
• Email verification sends the message and the link opens the form.
• After the total limit is reached, the form is replaced by the closed message.
• A repeat email or repeat submission is blocked by the expected mechanism.

Check Entries and Notifications Separately

Form Locker controls access, but entries and email are handled by other parts of WPForms. After a successful submission, open WPForms > Entries and locate the test record. Then check the email notification. If the entry exists but the email does not, the issue usually belongs to notifications or mail delivery, not Form Locker. If there is no entry, look at the access rule, field validation, CAPTCHA, and form errors.

For forms where each submission has high value, it is helpful to add an internal note to the support workflow: which form states are considered normal, which messages visitors see, and where to verify entries. This matters especially when the form is managed by an editor or manager rather than a developer.

Remaining Spots: When Code Helps and When It Is Better to Skip It

WPForms publishes a developer example for displaying the number of remaining entries when a total limit is enabled. That can be useful for a workshop, a contest, or any limited enrollment where showing the remaining capacity improves clarity. But that counter comes with a limitation: the number is calculated when the form loads and may change before the user submits. So you should not present it as a legally precise promise of a spot.

If you need a soft counter, use a safe approach only: add the code through Code Snippets or a child theme, restrict it to one specific form ID, and test it on a staging page. Below is a custom adaptation based on the documented wpforms_frontend_output action and the publicly documented Form Locker settings. Replace 123 with your own form ID.

add_action( 'wpforms_frontend_output', 'site_show_wpforms_places_left', 10, 1 );

function site_show_wpforms_places_left( $form_data ) {
    $target_form_id = 123;

    if ( absint( $form_data['id'] ) !== $target_form_id ) {
        return;
    }

    if ( empty( $form_data['settings']['form_locker_entry_limit_enable'] ) ) {
        return;
    }

    $limit = isset( $form_data['settings']['form_locker_entry_limit'] )
        ? absint( $form_data['settings']['form_locker_entry_limit'] )
        : 0;

    $submitted = wpforms()->entry->get_entries(
        array( 'form_id' => $target_form_id ),
        true
    );

    $left = max( 0, $limit - absint( $submitted ) );

    echo '<p class="form-places-left">' . esc_html( $left ) . ' spots left</p>';
}

Validation after adding it is simple: open the form, confirm that the line appears above the fields, submit a test entry, and refresh the page. Rolling it back is just as simple: disable the snippet or remove the function from your child theme. If the form is business-critical, do not show remaining spots without also clarifying that the spot is confirmed only after a successful submission.

Troubleshooting Common Problems with Restricted Forms

Most Form Locker issues fall into five areas: the rule is enabled in the wrong place, the page is showing a cached state, the user is testing with the wrong role, the verification email is not arriving, or the limit is being calculated from existing entries. Below is a practical symptom-based map.

The Form Is Not Showing Even Though It Should Be Open

Symptom: the visitor sees a closed message, a password field, or a login requirement even though the administrator expects the form to be open. Check which rule is active in Settings > Form Locker. Then open the page in a private window and clear the page cache. If scheduling is enabled, verify the site time zone. If logged-in-user mode is enabled, make sure the test is being performed under the correct account.

The fix depends on the cause. For scheduling, adjust the access window or the closed-state message. For login-based access, verify the login link and the user's role. For caching, exclude the form page from aggressive caching or reduce the cache lifetime. If you are not sure, temporarily disable only one rule and repeat the test so you do not lose control over the entire configuration.

The Password Does Not Open the Form

Symptom: the user enters the password but sees an error. First, check case sensitivity, extra spaces, and whether the password was copied from an email. Then make sure the password was set on the correct form and not on a duplicate. If the same form is embedded on multiple pages, test each page separately. Sometimes what looks like a password issue is really just an older cached version of the page.

A safe fix is to set a new password, save the form, clear the cache, and send users updated instructions. Do not publish the password on the page itself. If different groups need different access, it is usually better to create separate forms or separate workflows than to manage a complicated list of codes in one message.

Email Verification Does Not Send the Link

Symptom: the user enters an email address but never receives the message containing the link. Check whether the site sends ordinary WPForms notifications. If standard emails are not arriving either, investigate SMTP, domain email configuration, SPF/DKIM/DMARC, and the sending log. If standard email is working, check the spam folder, the sender address, and the content of the verification email.

In most cases, the fix is not in Form Locker but in WordPress mail delivery. Set up a reliable SMTP solution, test sending to several domains, and only then enable email verification on an important form. If time is short, temporarily use password protection or logged-in-user access so participants are not blocked by mail issues.

The Limit Is Reached Too Early

Symptom: the form has closed even though it seems like fewer entries than the limit have been submitted. Check the form entries in WPForms > Entries, any test submissions, and possible duplicates. If you tested on a live form, those test entries may also have been counted. Also verify whether the total limit, user limit, and unique field rule are enabled at the same time.

The fix may be to increase the limit, remove clearly test-only entries if that is acceptable for your process, or create a new form for the next registration cycle. Do not delete real entries just to reopen the form if those entries are already part of reporting or user communication.

A Repeat Email Is Being Blocked in the Wrong Place

Symptom: the user sees either a field-level email error or a general limit message, but the support team expected different wording. Most likely, both Require unique answer and an email-based user limit are enabled at the same time. Both mechanisms can restrict duplicates, but they produce different states.

Choose one primary mechanism. If you want the problem tied to a specific field, keep the unique answer rule. If you need to control the repeat-submission window, keep the per-user limit. After changing the setup, submit a new test entry and verify the text of the resulting error.

The Form Works for the Administrator but Not for a Regular User

Symptom: the administrator can see the form, but a participant sees a closed message. Check Logged in users only, the actual login state, the login page, and the registration flow. Do not confuse a WordPress administrator with a normal participant. An administrator may have an active session, a different cached state, and access to restricted pages.

The fix is to test with a separate low-permission user. If the form should be available to all logged-in users, make sure the registration and login process works before the user reaches the form. If the form is meant only for a specific group, Form Locker alone may not be enough and you may need a roles or membership solution.

Working Alongside Anti-Spam, Notifications, and Entries

Form Locker is often viewed as a security addon, but it is better understood as an access dispatcher. It decides whether the form should open, while the quality of the submissions you collect depends on the surrounding WPForms and WordPress settings.

Anti-Spam and Cloudflare Turnstile

If a form is public and receives junk submissions, access restrictions will not always solve that by themselves. A password can filter out random visitors, email verification can make entry harder, and limits can reduce mass repeats, but automated submissions are better handled with dedicated anti-spam tools as well. WPForms documentation includes separate Cloudflare Turnstile setup under WPForms > Settings > CAPTCHA and Turnstile activation in the form's protection settings.

The practical model looks like this: Form Locker controls access rights, Turnstile or CAPTCHA confirms that a human is submitting, notifications deliver data to the administrator, and entries provide auditing and export. One mechanism should not be forced to do every job.

Notifications and Team-Facing Messaging

Before launching a restricted form, review notifications in Settings > Notifications. The administrator should receive an email containing enough information, and the participant should receive a clear confirmation if that is part of the process. For internal forms, it can be useful to add Smart Tags that show the user ID, the submission page, or other details if they genuinely help the team process requests.

Do not insert Smart Tags thoughtlessly. For example, IP can help investigate repeat submissions, but it is also personal data that should be handled carefully. The stricter the form, the clearer your internal rules should be for who can access entries and notifications.

Entries, Export, and Post-Launch Auditing

After launch, check not only the number of submissions but also the quality of the collected data. In WPForms, entries can be viewed, filtered, and exported if your license level supports it. For limited forms, it is useful to document which entries were tests, who is allowed to delete entries, and what should happen when someone submits a duplicate by mistake.

If the workflow matters, do not change Form Locker rules without a short note in the team's operating log: what changed, why it changed, and who verified the outcome. That is not a technical requirement of the plugin. It is just good operational discipline for forms where every seat or submission has value.

Safe Improvements Without Editing Plugin Files

Sometimes the built-in settings are enough, but you may still want to improve the visitor experience: make the closed message clearer, show remaining spots, add a login link, or change the text of a unique-value error. Start with standard WPForms settings. Code only makes sense when there is a documented extension point or a normal safe WordPress pattern.

Closed-State and Login Messages

Each Form Locker rule has its own message. Write it as an answer to the user's question: why is the form unavailable, and what should they do next? Examples:

• "Submissions have not opened yet. Return to this page after registration begins."
• "All spots are filled. If you already submitted the form, check your confirmation email."
• "This form is available only to participants. Sign in to your account and refresh the page."
• "This email has already been used for registration. Contact the organizer if you need to update your information."

If you add a login or registration link, use the site's real pages. WPForms Smart Tags may help with system WordPress URLs, but test them on the published page, especially if the site uses a custom login form.

A Small CSS Tweak for the Remaining-Spots Message

If you use the custom PHP snippet above and output a line with the form-places-left class, you can style it cleanly with CSS in a child theme or in the standard Additional CSS area. That approach does not depend on WPForms internal markup and is easy to roll back.

.form-places-left {
    margin: 0 0 16px;
    padding: 10px 14px;
    border-left: 4px solid #2e7d32;
    background: #f1f8f2;
    color: #1f4d25;
    font-weight: 600;
}

The validation is simple: the line should appear above the form, should not break the fields, should not overlap Form Locker messages, and should look fine on mobile widths. Rollback means removing the CSS and disabling the PHP snippet. Do not use this tweak if the counter could mislead people or if spots are confirmed only through separate manual review.

When It Is Better Not to Add Code

Do not add snippets for silently changing access logic, bypassing restrictions, deleting entries automatically, or changing form state without a clear reason. If your business workflow requires complex rules, it is more honest to choose a better-fit tool or build a small custom extension with tests. Form Locker is strongest when the rule can be explained, tested, and rolled back.

A Useful Video Walkthrough from WPForms

The official WPForms documentation for Form Locker includes an embedded video about the addon. It is best viewed not as a standalone promotional clip, but as a quick visual reference: where Settings > Form Locker is located, what the access checks look like, and what states the user sees before the form opens. After watching, come back to the practical scenario above and test your own rules on a staging page.

When WPForms Form Locker Is the Right Choice

WPForms Form Locker is a strong fit when you already have a form built in WPForms and need to add clear access rules to it: a password, age verification, email verification, scheduling, a total limit, a per-user limit, or unique field values. Its strength is not vague "security," but a controlled workflow: the form is open to the right people, at the right time, up to the right limit.

Before launch, verify the license, addon installation, standard form submission, notifications, entries, caching, and test roles. Configure restrictions one at a time, write messages like a human, and test the published page the way a real visitor will see it. After that, you can download the latest version of WPForms Form Locker and test the addon in your working environment.

If the access rule can be explained in one sentence and verified across a few states, Form Locker will almost certainly fit your process well. But if the form has become part of a larger permissions system, subscription flow, or member dashboard, use it selectively and do not hesitate to move the main access model into a more specialized tool.