Forminator Pro - WordPress Plugin

A Guide to Configuring and Using Forminator Pro on a WordPress Site

Forminator Pro is useful for far more than just building a contact form. In this guide, we will look at how to turn it into a working tool for inquiries, surveys, quizzes, calculations, registration flows, payment forms, data exports, and post-launch verification. This material is written for site owners, webmasters, and editors who need more than a form embedded on a page. The goal is to understand which settings control email delivery, submission storage, spam protection, appearance, and integrations.

This guide does not cover purchasing, activating a subscription, or bypassing restrictions. We are looking at the situation where the plugin is already available in the admin panel and needs to be configured safely on a live site. The focus is on practical logic: which fields to add, where to enable notifications, how to verify the submission in Submissions, why the form might not send email, when to enable CAPTCHA, and what to keep in mind when working with payments, PDF, and geolocation.

We will also cover the limits and risks. Forms involve user data, email, third-party services, and sometimes payments, so what matters here is not just attractive fields but also privacy, mail delivery, caching, theme compatibility, editor permissions, and a safe way to roll back a questionable setting. If you need a short product overview, that already appears above on the page. This section is the reference guide you can use as a checklist when launching a form.

What the Plugin Can Handle and Where It Is Most Useful

Forminator Pro's main strength is that it combines several interactive modules in one interface. The same product includes forms, surveys, quizzes, calculation fields, registration forms, payment fields, reports, submission exports, and additional Pro modules. That makes it especially useful on sites where forms are not just a single "Contact Us" block, but part of several business workflows.

Typical use cases look like this:

• A contact form with conditional email routing to different managers.
• A service request form with an estimated cost calculator.
• A survey with results that helps collect audience feedback.
• A quiz that shows the visitor the best-fit service or product option.
• A registration form where fields are mapped to WordPress user data.
• A form with payment, donation, one-time order, or subscription billing, if the required payment settings and add-ons are connected.
• A form that sends data to Google Sheets, a CRM, an email platform, Slack, Trello, or another external tool through integrations and webhooks.

For a simple site with just a few pages, Forminator Pro may be more powerful than necessary. If all you need is a minimal form with a name, phone number, and message field, a lighter form plugin may be a better fit. But if the site owner wants to view submissions in the admin panel, send different notifications, keep a history, export data, add spam protection, build calculations, and reuse templates across projects, Forminator Pro becomes a much more justified choice.

Practical rule of thumb: if a form affects sales, service bookings, user registration, payments, or data transfer to a third-party system, it should be configured as a small workflow, not as a decorative block on the page.

There is another important nuance: Forminator Pro stores and processes user data. Depending on the features you enable, it may use third-party services, add CAPTCHA checks, store IP addresses, send data into integrations, or generate a PDF from a submission. Before launching a form, it helps to decide within your team who handles notifications, who checks Submissions, how long data should be retained, and which fields are actually necessary.

Who Forminator Pro Is a Good Fit For, and When Another Approach Makes More Sense

The plugin is a strong fit for sites where forms change frequently and need to be managed from the admin panel without constant help from a developer. An editor can add a field, update the confirmation message, enable conditional logic, copy the shortcode, and test the submission in preview. For agencies, this saves time: the same logic for forms, surveys, and quizzes can be reused across multiple client sites, while import, export, and cloud templates make it unnecessary to rebuild everything from scratch.

Forminator Pro is especially appropriate if:

• You need more than forms, such as surveys, quizzes, or calculations.
• There are multiple notification recipients and you need routing by selected service, city, or inquiry topic.
• You need to store submissions in WordPress and export them to CSV from time to time.
• You need integrations with Google Sheets, Mailchimp, HubSpot, Slack, Trello, ActiveCampaign, AWeber, Campaign Monitor, MailerLite, Mailjet, Groundhogg, Uncanny Automator, Zoho Flow, or webhooks.
• You need Pro add-ons such as PDF Generator, Geolocation, or Stripe Subscriptions.
• The form needs to be embedded in a post, page, widget area, or marketing block, for example through Hustle.

There are also cases where more caution is warranted. If a project needs complex developer-driven logic with custom database tables, nonstandard validation, a dedicated user area, and a large number of custom actions after submission, a visual builder alone may not be enough. In that case, Forminator Pro can still serve as a fast input layer, but the broader architecture is something you should discuss with a developer.

The plugin can also be unnecessary for sites where storing personal data inside WordPress is not allowed and all processing must happen in a separate certified system. In that situation, the form should be designed around security requirements and legal review, not just editor convenience. On projects like that, it is especially important to disable unnecessary storage, review the privacy policy, control integrations, and avoid collecting fields "just in case."

What to Check Before Installation and the First Launch

Preparation takes less time than fixing a form after visitors have already started submitting it. With Forminator Pro, it makes sense to check four areas in advance: the WordPress environment, email, privacy, and compatibility with the public-facing site.

Email and Domain

A form can be built perfectly and still have notifications land in spam or fail to arrive. Forminator calls the WordPress mail system and passes it the notification data, but delivery then depends on the server, SMTP, domain authentication, and the mail provider's policies. Before publishing a form, check the following:

• Whether SMTP or another reliable method of sending email from the site is configured.
• Whether the sender address matches the site domain or an approved mail domain.
• Whether the sending domain has SPF, DKIM, and DMARC records.
• Whether the hosting provider blocks outgoing email or attachments.
• Whether the site can send a test email before the form is configured.

If a WordPress test email does not go through, do not start troubleshooting with Forminator. Stabilize mail delivery first. Otherwise, any form will look "broken" even though the submission may still be saved in Submissions.

Cache, Optimization, and Theme

Forms rely on JavaScript, field validation, AJAX submission, CAPTCHA, and sometimes payment fields. Aggressive script bundling, deferred loading, jQuery optimization, fragment caching, and theme popups can all affect the form. Before launch, choose the page where the form will live and test it with conflicting optimizations turned off. Then re-enable optimization one setting at a time.

Pay special attention to page builders and themes that control popups or delay script loading. Forminator's changelog has included compatibility fixes for Elementor, Oxygen, Divi, OceanWP, and other environments. That does not mean a conflict is guaranteed, but it does mean the form should be tested in the exact template where it will be published.

Data and Consent

If the form collects a name, email address, phone number, address, file, geolocation, quiz results, or payment details, think through which fields are actually necessary. Forminator includes settings for storing submissions, storing IP addresses, and responding to personal data deletion requests. Do not automatically set the retention period to "forever." For some projects that is convenient, but for others it creates unnecessary risk.

Roles and Editor Access

Forms are often edited by several people. One person manages the fields, another handles notification copy, and a third manages integrations. Before launch, decide who is allowed to edit published forms, who can view submissions, and who is responsible for exports. This is especially important for registration forms and file upload forms, because a mistake in a field or notification routing can affect real user data.

Installation and Initial Checks in the Admin Panel

After installation and activation, a Forminator Pro section appears in the admin panel. The main entry point is a dashboard with an overview of active modules, the latest submission, and quick access to forms, surveys, and quizzes. Do not start by publishing on a live page right away. First create a test form, verify the basic cycle, and only then move the logic into a production scenario.

Minimum Test After Activation

1. Open Forminator Pro in the admin panel and make sure the dashboard loads without errors.
2. Go to Forms and click + Add New.
3. Choose a blank template or a suitable preset if one is close to your use case.
4. Add the Name, Email, and Textarea fields, and keep the submit button.
5. Publish the form, open Preview, and send a test submission.
6. Check whether the entry appears in Submissions.
7. Check whether the administrator email notification arrives.

If the entry appears in Submissions but the email never arrives, the form most likely worked. The next step is to check notifications, the sender address, SMTP, and the mail log. If there is no entry, the problem is closer to the form submission itself: the script, CAPTCHA, a cache conflict, a payment field, a validation error, or the server response.

What to Do Before Publishing on a Page

Once the test passes, create a separate WordPress test page and insert the form using the Forminator block or a shortcode. The documentation confirms both approaches: the form can be added through the block editor, a widget area, or a copied shortcode. On that page, check the public-facing appearance, not just the preview window in the admin panel.

Result check: a form is only ready for a live page after three successful checks: it appears on the public page, it saves the entry in Submissions, and it sends the notification to the correct address.

If the site uses caching, clear the page cache and the optimizer cache after publishing. Then open the page in incognito mode. That lets you test the form the way a normal visitor sees it, not the way an administrator sees it with extra editing links.

Detailed Post-Install Setup: Fields, Behavior, Notifications, and Appearance

The biggest mistake when configuring Forminator Pro is assuming the form is done as soon as the fields are added. In practice, a working form has several layers: field structure, display rules, post-submission behavior, notifications, protection, submission storage, appearance, and publishing method. If one layer is skipped, the visitor may still submit data, but the team may never get the email, the submission may go to the wrong manager, or the form may conflict with caching.

Fields and Form Logic

Start with the data, not the design. Write down what should come through in the submission and what the manager needs to do with it afterward. For a simple inquiry, that usually means a name, an email address or phone number, the topic, and a message. For a calculator, it means numeric fields, selectable options, and a calculated field. For registration, it means fields that can be mapped to WordPress user data. For a form with uploads, it means limits on file type and quantity.

Forminator supports conditional logic, so there is no need to show every question at once. If the visitor selects "Consultation," you can show one set of fields. If they choose "Project Estimate," you can show another. That kind of logic shortens the form and improves submission quality. But conditional logic must be tested on every branch. After each major change, send a test submission for every option.

What You Should Not Add Without a Clear Reason

• A required phone number if communication can happen by email.
• File upload in the first version of the form if the file is not needed to process the request.
• Too many required fields that the manager will end up clarifying manually anyway.
• Hidden fields with no clear purpose and no verification in the notification.
• A payment field in a form where a manual consultation should happen first.

The fewer unnecessary fields you have, the easier it is to test the form, protect the data, and explain to the user why each block is there.

Behavior After Submission

In the form behavior settings, define what the user sees after a successful submission. Options include an inline message above the form, hiding the form, or redirecting to another page. For most inquiry forms, it is safer to start with a clear inline message and confirm that it appears without a page reload. A redirect can be useful for a Thank You page, analytics, or a defined next step, but it should be intentional. The user should not lose context or end up on a page unrelated to their choice.

If you use multiple behavior variants based on conditions, configure the conditions for each one. The documentation specifically notes that without conditions, only the first scenario may run. That is an important trap: the administrator expects different responses for different services, but every visitor gets the same result.

Notifications and Email Routing

A notification is more than just an email saying "a submission arrived." In Forminator, you can use merge tags, include all fields with {all_fields} or only the filled ones with {all_non_empty_fields}, configure recipients, sending conditions, From Name, From Email, Reply-To, CC, and BCC. For a production form, create at least two notifications: one internal notification for the team and one confirmation for the user, if that makes sense.

For the team, it is useful to include:

• The form name and page name, if there are multiple forms.
• The key submission fields in a clear order.
• A link to the page or product, if the form appears in multiple places.
• The user's address in Reply-To, if the manager is expected to reply directly.
• An internal note if the submission came from a test form.

For the user, it is better not to send sensitive personal data back unnecessarily, especially if the form collects confidential information. Usually it is enough to confirm that the submission was received and state the expected next step. If the site uses SMTP, keep in mind that it may override From Email and From Name. That is not a Forminator error, but a normal part of mail delivery policy.

Appearance and Theme Compatibility

In the appearance settings, you can choose Forminator styling, a base style that inherits the theme, or a mode without built-in styling. For a typical site, start with theme inheritance. That usually makes the form feel like part of the page instead of a third-party widget. Then fine-tune colors, fields, spacing, fonts, and focus states as needed.

If the theme already styles fields well, do not enable a lot of custom plugin styling unless you actually need it. The more overlap there is between the theme, the page builder, and Forminator's settings, the harder it becomes to understand why a button or field looks wrong. The best approach is to get a clean base appearance first, then change one parameter at a time and recheck the public page.

Safe CSS Tweak for the Submit Button

If you want to give the form button a bit more emphasis, add CSS through a child theme, the Customizer, or a safe CSS snippet plugin. Do not edit Forminator files. The example below uses Forminator's general container class and does not depend on hidden internal plugin behavior:

.forminator-ui .forminator-button-submit {
  border-radius: 6px;
  font-weight: 700;
  letter-spacing: 0;
}

.forminator-ui .forminator-button-submit:focus {
  outline: 3px solid rgba(0, 115, 170, 0.35);
  outline-offset: 2px;
}

After adding it, open the page with the form, test the button with both mouse and keyboard, and then send a test submission. If the appearance conflicts with the theme, remove this snippet and go back to the appearance settings inside the plugin itself.

Fields, Calculations, and Conditional Logic: How to Build a Form Without Overloading It

Forminator Pro becomes especially useful when a form needs to react to user input. That can mean a cost estimate, hiding unnecessary questions, choosing the email recipient, showing a personalized post-submission message, or routing the data to different integrations. But this is also where mistakes appear most often: a field is hidden, a calculation does not update, the notification is missing important data, or the user does not understand why the form is asking for the next step.

Calculation Fields

A calculation field uses numeric values from other fields and applies a formula. Calculations can include number fields, currency fields, radio buttons, checkboxes, select fields, and other supported elements, as long as numeric values are enabled for them. A common example is an estimated service cost calculator: the visitor selects the type of work, number of pages, turnaround time, and additional options, and the form displays a total.

To keep the calculation reliable, follow a simple sequence:

1. First add all fields that will be part of the calculation.
2. Assign numeric values to the selectable options, not just visible labels.
3. Add the calculation field and build the formula using the available merge tags.
4. Test the formula with minimum, average, and maximum value combinations.
5. Decide whether the calculation field should be visible to the user or used only in the notification.

Do not turn the calculator into a full accounting system. If the final price depends on manual review, exchange rates, a complex pricing model, or discounts, label the result as "estimated." That way you are not promising an exact price, and the manager still has room to clarify details.

Conditional Logic

Conditional logic is useful when the form needs to be shorter and more precise. For example, the "Property Address" field might only appear for on-site services, the "Website URL" field only for a site audit, and file upload only if the user chooses an option involving documents. In notifications and post-submission behavior, conditions work similarly: you can send the submission to different recipients or show different messages.

The rule is simple: every conditional branch needs its own test submission. Do not verify only the most obvious path. If the form includes three services and two budget options, send several submissions with different combinations. Then check Submissions, the admin email, the user email, and the visible text after submission.

Groups and Repeaters

For forms where the user adds multiple entries of the same type, repeating field groups are useful. Examples include a request for multiple products, a list of event participants, or a set of properties for evaluation. The important part here is not to overcomplicate the email. If repeated data needs to appear in an email or PDF, use a general output of all fields or verified wildcard merge tags so that some repeated values do not get lost.

The more complex the structure, the more important it is to prepare a test example with several completed groups. Submit the form with one group, with two groups, and with an empty additional group. That will show you how the data looks inside the submission, the PDF, and the export.

Spam Protection, CAPTCHA, and Data Privacy

A form on a public site quickly becomes a target for automated submissions. Forminator Pro offers several layers of protection: honeypot, Akismet, restrictions for logged-in users, form lifetime controls, CAPTCHA through Google reCAPTCHA, hCaptcha, or Cloudflare Turnstile, as well as settings for storing submissions and IP addresses. You do not need to enable everything at once. It is better to choose protection based on the form's risk profile and confirm that it does not get in the way of normal visitors.

Honeypot and Akismet

Honeypot is a gentle first layer of protection. It adds a check that is invisible to humans but often triggers bots. That makes it a good choice for a standard contact form because the visitor does not see an extra step. Akismet is worth using if it is already present on the site and you understand how suspicious submissions are handled. Depending on the configuration, they may be rejected or marked as spam.

For a new form, a sensible starting point is honeypot plus stable email delivery. If spam continues, add CAPTCHA or a stricter check. If you enable too many barriers at once, some real users may not get through the form, especially on mobile devices, inside corporate networks, or when script blockers are involved.

reCAPTCHA, hCaptcha, and Turnstile

CAPTCHA requires correctly configured keys in the global settings. The Forminator documentation notes that reCAPTCHA needs the right key versions configured, or errors may appear when saving or previewing the field. reCAPTCHA v3 also uses a risk score threshold: the higher the threshold, the more likely false positives become. Because of that, do not set extremely strict values without testing them against real traffic.

If the site operates in a region where Google services may load unreliably, consider hCaptcha or Cloudflare Turnstile. The key point is not to combine multiple CAPTCHA systems in the same form unless there is a real reason to do so. That makes troubleshooting harder and can hurt conversion rates.

Submission and IP Retention

In the Submissions settings, you can manage how long submissions and IP addresses are kept. The default retention may be long, but that is not always the best choice. For a standard contact form, it may be enough to keep data long enough to process requests and review disputed cases. For sensitive data, it is better to shorten the retention period or avoid collecting that data unless it is truly necessary.

Another important point is deleting fields from a published form. The documentation warns that deleting a field may affect stored submission data associated with that field. Because of that, before changing a live form, it is safer to duplicate it, make the changes in the copy, export the form and submissions, then publish the new version and disable the old one.

Publishing the Form on a Page, in a Block, Widget, or Marketing Module

Once configured, the form needs to appear where the user actually makes a decision. Forminator supports embedding through an editor block, shortcode, and widget area. The form can also be used inside WPMU DEV Hustle marketing modules if the site uses popups, slide-ins, or embedded lead generation blocks.

Editor Block or Shortcode

For a standard WordPress page, the Forminator block is usually the easiest option: the editor chooses the required form from a list and sees it as a separate content element. A shortcode is useful when the form needs to be placed in a template, a page builder text block, a tab, an accordion, or another area where blocks are unavailable. In both cases, once it is published, you need to check not only the display but also the submission itself.

Verification path:

1. Open the page as an administrator and confirm that the form is visible.
2. Open the page in incognito mode and check the form as a regular visitor.
3. Fill in the required fields correctly and submit the form.
4. Repeat the submission with an error, such as leaving out the email, to verify validation.
5. Check Submissions, the admin email, and the user email.

Widget Areas and Reuse

If the form is displayed in a widget, sidebar, or footer area, check the container width. Some fields, especially address fields, file uploads, CAPTCHA, or multi-column layouts, can look poor in a narrow space. In that case, it is better to create a separate compact widget form instead of forcing a full request form into a small block.

Form in a Popup

A form can be placed inside a marketing module, but popups add risk: scripts may load later, CAPTCHA may not initialize in time, and a cache or optimizer may defer the JavaScript the form needs. If a popup form does not submit, first test the exact same form on a regular page. If everything works on a normal page, the problem is more likely related to the popup, deferred loading, or a builder conflict.

Integrations, Webhooks, and Sending Submissions to Other Services

Integrations let the form go beyond WordPress: send a lead to an email platform, add a row to Google Sheets, create a Trello card, notify the team in Slack, push data into HubSpot, or trigger an external workflow through a webhook. In Forminator, you first connect the app in the integrations section, then each individual form gets its own connection settings.

Google Sheets as a Simple Submission Log

The Google Sheets connection is useful when managers need a shared spreadsheet log without access to WordPress. The setup requires a project in Google Cloud, enabled APIs, OAuth credentials, and the correct redirect URI from the Forminator integration window. It is not the fastest setup, but it works well for transparent verification: send a test submission and check whether a new row appears in the sheet.

Do not use the spreadsheet as your only data source until the integration has been verified. At the beginning, it is better to store submissions both in Submissions and in the external sheet. If Google authorization breaks, you will not lose the history inside WordPress.

Webhooks for Zapier, n8n, and Similar Tools

A webhook is useful when there is no built-in integration for a service or when you need to trigger your own custom flow. Forminator sends the form data to the webhook URL. For n8n, the documentation specifically says to use the POST method and enable test event listening before saving the connection, otherwise the configuration may return an error.

You need to test a webhook with a real form submission, not just the button inside the third-party service. That is the only way to see which fields are sent, how the keys are named, and whether hidden or conditional data is being lost. If the form includes personal information, make sure the external service is genuinely necessary and that access to it is restricted.

Keys and Encryption

When working with payments and integrations in Forminator, secret keys are involved. The documentation recommends adding your own encryption key to wp-config.php, because changing WordPress salts can break decryption of stored secrets. That is a task for the site administrator or developer. Do not paste secrets into public notes, contractor tasks, or articles. For this guide, it is enough to understand the principle: keys should be protected, and after changing salts, integrations should be retested.

Pro Add-Ons: PDF, Geolocation, and Recurring Payments

Forminator Pro differs from a basic setup in more than just the number of fields. Important Pro features are provided as add-ons: PDF Generator, Geolocation, and Stripe Subscriptions. They extend the form, but they also introduce dependencies that need to be reviewed before launch.

PDF Generator

The PDF add-on lets you generate a PDF from submitted data. That is useful for applications, receipts, participation requests, order confirmations, contract drafts, or an internal archive. The documentation states that PDF Generator requires the PHP mbstring extension, along with a supported version of the main plugin. If the PDF is not being created, check not only the template but also the hosting environment.

When configuring PDF output, do not try to build a complex multi-page document right away. Start with a basic template, include all form data, send a test submission, and review the result. After that, you can remove empty fields, add a logo, format headings, and configure payment sections if the form includes Stripe or PayPal.

Geolocation

Geolocation adds address handling, Google Maps API support, autocomplete, and Map ID support for custom map styling. It is useful for field service businesses, delivery workflows, real estate requests, events, and local services. But the feature depends on a valid Google Maps API key and correct domain settings. If the key is wrong or API restrictions are configured incorrectly, autocomplete may not work.

Do not enable geolocation in every form by default just because it is available. For a contact form with no address field, it is an unnecessary dependency. For a field service form, it can be a useful way to reduce address errors.

Stripe Subscriptions

Stripe Subscriptions extends Stripe fields with support for subscription plans. That is useful for membership dues, recurring donations, service subscriptions, or periodic payments. This kind of flow needs especially careful setup: the payment fields, conditional logic, payment description, user email, Stripe data, and the result in Submissions all need to align.

Before publishing a subscription form, test it in the payment system's safe mode and verify successful payment, failed payment, invalid data, and repeat submission scenarios. Do not place a subscription form on a live page until your team clearly understands the process for canceling or changing a subscription.

Practical Example: A Request Form with Calculations and Different Notifications

Let us walk through a scenario that shows the real value of Forminator Pro: a small studio wants to receive consultation requests and estimated service quotes through the site. The visitor chooses the project type, the scope of work, and the urgency level. The form shows an estimated amount, sends the submission to the right manager, and stores all data in the admin panel.

Goal

The goal is to create a form that does more than collect a message. It should help the user describe the task and immediately see a useful estimate. The team should receive a clear email, while the administrator gets a record in Submissions for control and follow-up.

Preparation

• The site already has email delivery configured through SMTP or another reliable method.
• A test page has been created and is either hidden from indexing or not added to the menu.
• Email addresses for managers responsible for different request types have been prepared.
• Base values for the calculation have been defined: project type, scope, and urgency.

Setup Steps

1. Create a new form in Forminator Pro > Forms and choose a blank template.
2. Add the Name, Email, Phone, Select field for project type, Number field for scope, and Radio field for urgency.
3. Enable numeric values for the options if they will be used in the calculation.
4. Add Calculations and build the formula, for example: the base price for the project type multiplied by scope and the urgency coefficient.
5. In Behavior, configure the post-submission message: "Thank you, your request has been received. An estimate has been sent to our team."
6. In Email Notifications, create the manager notification and insert {all_non_empty_fields} into the body so the email is not cluttered with empty fields.
7. Add conditional recipient routing: one address for development, another for support, and a third for design.
8. Enable honeypot, and only add CAPTCHA if spam appears after publication or the form is already highly visible to the public.
9. Publish the form and insert it on the test page using a block or shortcode.

Verification

Send at least four submissions: a normal one, one with the maximum scope, one with a different category, and one with an error in a required field. After each submission, check the following:

• Whether the entry appears in Submissions.
• Whether the email reaches the correct manager.
• Whether the calculation appears in the email and matches the visible result in the form.
• Whether empty hidden fields were sent by mistake.
• Whether the post-submission message is clear to the user.

A Common Problem Point

If the email does not arrive but the entry exists in Submissions, do not change the calculation fields or rebuild the form. First check the mail log, SMTP, sender address, domain authentication, and spam filtering. If the email went to the wrong manager, review the routing conditions and the order of those conditions. If the calculation differs from what you expected, check the numeric option values, the decimal separator, and the behavior of hidden fields.

How to Verify the Result After Publishing and Avoid Losing Submissions

Publishing the form is not the end of the setup process. Production forms need a short verification routine. That matters most when the submission leads to a sale, a booking, a user registration, or a payment. The routine only takes 10 to 15 minutes, but it often prevents the loss of real inquiries.

Public Page Check

Open the form page in a normal browser window and in incognito mode. Check the appearance on desktop and mobile widths. Do not stop at visual review alone: fill out the form. Some conflicts only appear during submission, when validation, AJAX, CAPTCHA, a payment script, or a redirect is triggered.

Admin Data Check

After submission, open Forminator Pro > Submissions. Choose the module type and the specific form. The entry should appear in the list, and the necessary fields should be visible inside it. If this is a registration form with manual approval or email activation, also check the user status and whether the activation link can be resent.

Export Check

If the team plans to export submissions, test the CSV export immediately. Forminator lets you download data manually or configure scheduled export delivery. Check the column headers, character encoding, empty fields, and date format. If the data also goes into Google Sheets, compare the spreadsheet row with the record in WordPress.

Failure Check

Submit the form incorrectly: leave a required field empty, enter an invalid email address, or upload an unsupported file if uploads are enabled. The user should see a clear message, and the form should not submit bad data. If the error looks overly technical or appears in English on a fully Russian-language site, adjust the field and message text.

Quick takeaway: proper Forminator Pro verification always follows the chain "page - submission - saved entry - email - integration - export." If you only check one link in that chain, you can miss a problem in the next one.

Reports, Submissions, and Working with Data After Launch

Once the form is live, the administrator should know where to look for the result. Forminator includes Submissions for individual entries and Reports for analyzing views, submissions, conversions, payments, applications, leads, and geolocation where applicable. That is useful not only for marketing, but also for troubleshooting.

When to Check Submissions

Submissions are for operational work: finding a specific submission, checking user data, exporting entries, seeing draft status when Save & Continue is enabled, reviewing a registration form submission, or filtering data by date range. If a manager says the email never arrived, this is the first place to look. If the record exists, the form submitted the data and the next place to investigate is email delivery. If the record does not exist, look for the problem in the submission itself, the scripts, CAPTCHA, the payment field, or server-side processing.

When to Check Reports

Reports help you understand how the form performs over time: how many views it gets, how many submissions it receives, and what the conversion rate looks like. If the page gets many views but few submissions, the issue may be the form length, an unclear offer, strict CAPTCHA, too many required fields, or poor placement on the page. If submissions exist but no leads reach the CRM, the issue is closer to the integration.

How to Change a Published Form Without Losing History

If you need to make major changes to the fields in a published form, do not delete them immediately. First export the form and its submissions, then duplicate the form, make changes in the copy, and test it on a separate page. Only after that should you replace the shortcode or block on the live page. This order is especially important if you are removing fields that already existed in earlier submissions.

Payments, Files, Registration, and Other Higher-Risk Scenarios

Some Forminator Pro features require stricter testing because mistakes affect more than just email. They can affect money, user accounts, files, or permissions. These are not scenarios you should launch the evening before an ad campaign. They need separate testing, documentation, and team signoff.

Payment Form

For one-time payments or subscriptions, verify the payment field, total amount calculation, conditional visibility, the user email, the record in Submissions, and the status in the payment system. If both Stripe and PayPal are used in the same form, make sure the visibility conditions do not allow the user to submit the form with the wrong combination of fields. Forminator's changelog has included fixes related to PayPal, Stripe, Google Pay, hidden Stripe fields, and CAPTCHA, so payment flow testing should always be a separate step.

File Uploads

A file field is useful for resumes, documents, images, or project briefs, but it raises the bar for security and storage. Limit file types, file counts, and size. Check how the file appears in the submission and whether it is included in the email. If attachments are large, notifications may fail to send or may drop the file depending on the hosting and mail settings. For large files, it is often better to store a link in the submission instead of trying to send everything by email.

User Registration

Registration forms need to respect WordPress settings. If user registration is disabled in Settings > General > Membership, the visitor may submit the form, but no new user will be created unless the appropriate manual activation flow is being used. For Multisite, also account for network registration settings and role behavior on the main site.

Check user meta mapping, the assigned user role, the activation method, the emails, the submission status, and the access level after registration. A mistake here can give the user the wrong role or create an expectation of access they do not actually receive.

Common Forminator Pro Issues and How to Diagnose Them

Form troubleshooting should move from observed fact to probable cause. Do not rebuild the form after the first error. First identify which part of the chain is failing: display, validation, submission, saving the entry, email, integration, or the external service.

The Form Does Not Appear on the Page

Symptom: the page shows an empty area, the shortcode appears as plain text, or the block does not render the form.

Possible causes: the form is not published, the wrong shortcode was used, the page is cached, the builder does not render shortcodes, scripts were disabled by an optimizer, or the form was inserted into an unsuitable container.

What to check: the form status, preview, embedding through the editor block, the page without cache, and the browser console. If the form is visible in Preview but not on the page, the issue is usually related to output, caching, or the theme.

How to fix it: publish the form, recopy the shortcode, clear the cache, and temporarily disable deferred script loading for the page with the form. If the form is in a popup, test it on a regular page.

The Submission Is Saved, but the Email Never Arrives

Symptom: the entry exists in Submissions, but the administrator does not receive the email.

Possible causes: SMTP is not configured, the sender address does not match the domain, the email went to spam, the mail service rejected an attachment, the notification is disabled, or the notification conditions were not met.

What to check: the mail log, Email Notifications settings, recipients, From Email, Reply-To, sending conditions, attachment size, and SPF/DKIM/DMARC domain records.

How to fix it: configure SMTP, use a domain-based sender address, temporarily disable notification conditions, and send a test submission. If the email arrives after disabling the conditions, the problem is in the routing logic.

CAPTCHA Fails or Blocks Real Users

Symptom: the user sees a CAPTCHA error, the form does not submit, the badge does not load, or v3 rejects legitimate submissions.

Possible causes: invalid keys, keys for the wrong domain, an overly strict threshold, blocked external scripts, a cache conflict, or a hidden payment field conflict.

What to check: the global CAPTCHA settings, the CAPTCHA type used in the field, the key domain, the browser console, and the form behavior with JavaScript optimization turned off.

How to fix it: regenerate keys for the correct domain, lower the v3 threshold, temporarily switch to a checkbox variant or another CAPTCHA service, and exclude the form page from aggressive optimization.

The Integration Is Connected, but the Data Does Not Go Through

Symptom: the submission exists in WordPress, but no row appears in the spreadsheet, no card is created, or the webhook does not receive the data.

Possible causes: expired authorization, an incorrect redirect URI, the external service is not listening on the test URL, the webhook uses the wrong method, fields are not mapped, or conditional sending did not run.

What to check: the status of the connected app, a real test form submission, the external service log, field names, and integration conditions.

How to fix it: reconnect the integration, send a test submission, and inspect the incoming data in the external service. For n8n, enable test event listening before saving the URL in the form.

The Calculation Shows the Wrong Value

Symptom: the total does not match expectations, does not update after a selection, or breaks when a field is hidden.

Possible causes: options do not have numeric values, the decimal separator is wrong, a field is hidden by a condition, the formula points to the wrong merge tag, or a hidden field value is included differently than expected.

What to check: the numeric values of all fields, the formula, the calculation preview, several test combinations, and the behavior of hidden fields.

How to fix it: simplify the formula, verify each field separately, and then rebuild the overall calculation. If the calculation depends on hidden conditions, add a test case for each condition.

The Payment Form Does Not Submit

Symptom: the user cannot complete the form with Stripe or PayPal, the form hangs, the payment field is hidden, or the amount is incorrect.

Possible causes: invalid payment system keys, a CAPTCHA conflict, a hidden payment field, incorrect conditional logic, cached payment scripts, or an amount error in the calculation.

What to check: the payment system's test mode, payment field visibility, CAPTCHA, the amount, conditions, the browser console, and the record in Submissions.

How to fix it: temporarily simplify the form to a single payment scenario, disable unnecessary conditions, test the payment without cache, and then restore complexity one element at a time.

Safe Improvements Without Editing Plugin Files

Most tasks are better handled through Forminator Pro settings. Code should only be used for small visual or organizational improvements that do not affect the plugin core and can be rolled back easily. With forms in particular, it is important not to interfere with submission, validation, or payments unless you have confirmed hooks or custom development.

Improving Field Focus and Readability

If the form visually gets lost on the page, start with CSS, not PHP. You can make the active field and helper text more visible. The snippet below is safe because it does not change how data is processed:

.forminator-ui .forminator-input:focus,
.forminator-ui .forminator-textarea:focus,
.forminator-ui .forminator-select2 + .forminator-select .selection:focus {
  box-shadow: 0 0 0 3px rgba(20, 115, 230, 0.18);
}

.forminator-ui .forminator-description {
  line-height: 1.45;
}

Verification is simple: tab through the form, make sure the active field is clearly visible, and then send a test submission. Rolling it back is just a matter of removing the CSS snippet from wherever you added it.

When It Is Better Not to Add Code

Do not add random JavaScript snippets to force popup opening, override values, bypass CAPTCHA, or alter payment data. If you need custom behavior, first check the conditional logic settings, post-submission behavior, webhooks, and integrations. If those are not enough, the task should be handled by a developer through documented APIs or a separate plugin, not by pasting unverified code into the site footer.

When Forminator Pro Is the Right Choice

Forminator Pro is worth using when a form on the site is a real working tool: it collects inquiries, calculates values, routes emails, stores history, connects external services, shows survey or quiz results, supports registration, PDF, geolocation, and payment scenarios. In those cases, what matters is not just putting a form on the page, but building a testable path from user input to the result your team receives.

If, after reading this, you understand which fields you need, how to verify notifications, where to check submissions, what to do when email problems appear, and which integrations to connect, you can move on to a practical test. Install the plugin on a prepared site, create a test form, and only after verification move it to the live page. Near the download section, you can get the WordPress version and start with the safest scenario: a simple inquiry form, one page, one notification, a record in Submissions, and a control test submission.

Do not try to enable every feature at once. First get the basic cycle working reliably, then add conditional logic, calculations, CAPTCHA, integrations, PDF, or payments. That sequence makes the setup predictable: if something breaks, you know which layer was added last and how to roll it back.