Convert Forms Pro - Joomla Extension

A Guide to Setting Up and Using Convert Forms Pro in Real Projects

Convert Forms Pro is best understood not as a single form builder screen, but as a working system for capturing inquiries on a Joomla site. In this guide, we will walk through how to prepare the site, build a form, connect it to notifications, tasks, spam protection, and menu or module placement, and then verify the result without taking unnecessary risks on a live page.

This article is written for site owners, Joomla administrators, marketers, and developers who need more than a basic contact form. The goal is to build a proper workflow: a visitor fills out the fields, the system stores the submission, sends an email, optionally passes the data to an email marketing service or external handler, and gives the administrator a clear place to start when something goes wrong.

This guide does not cover purchasing or activating the paid version. It assumes the extension is already available for installation. The main focus is setting up Convert Forms Pro after installation, building a practical submission workflow, and diagnosing common issues.

What This Extension Actually Solves on a Joomla Site

Convert Forms Pro becomes useful when Joomla's standard contact component is no longer enough. A simple "name, email, message" form quickly stops being practical when you need different behavior for different departments, confirmation emails for users, mailing list signups, price calculations, hidden fields, file uploads, spam protection, or a way to display submissions in the admin panel or on a public page.

At the core of the extension are four entities. Campaign groups submissions and can connect them to an external service. Form controls the fields, design, and behavior of the form. Submission stores an individual user submission. Addons and Tasks handle external actions such as email, integrations, webhooks, user creation, working with Joomla content, and other operations, if those features are available in your version and enabled in settings.

This approach is useful for several types of tasks:

• Contact forms with department-based email routing.
• Subscription forms where the submission is stored locally and also sent to a mailing service.
• Service request forms with conditional fields, so visitors only see the questions that apply to them.
• Calculators where the final amount or score is based on selected values.
• Registration forms or Joomla content creation workflows, if that scenario is supported and configured through Tasks.
• Internal forms for clients or staff, where submissions need to be displayed on a public page with access control.

The main advantage of the Pro version is not just that it lets you add more fields. It becomes valuable when the form starts making decisions: show or hide a field, send the submission to a specific service, trigger a task conditionally, calculate a value, attach a file to an email, filter spam, or display submissions in the right place on the site.

Who Convert Forms Pro Is For - and When Another Approach Makes More Sense

This extension is a strong fit for sites where Joomla remains the central content management system. If submissions need to be stored inside the site and editors are comfortable working in the admin panel, Convert Forms Pro covers more use cases than an external form embedded through a third-party script.

When It Is a Good Fit

Convert Forms Pro is worth considering if you need a form that works closely with Joomla logic: menu items, modules, articles, users, local submissions, templates, and language settings. For agencies, it is also convenient because forms can be moved between sites, turned into repeatable workflows, and explained to clients in a way that makes it clear where to check submissions.

It is also a strong option for marketing-oriented sites. The documentation shows integrations with email platforms, CRMs, analytics tools, and webhooks. That does not mean every form needs to be connected to an external service right away. But if the site is likely to grow from a simple inquiry form into a more automated workflow, it is better to structure the form properly from the start so that fields, names, consent checkboxes, and notifications are clean and reliable.

When It May Be More Than You Need

If you only need one simple contact form with no submission storage, no integrations, and no special behavior, it makes sense to first evaluate Joomla's built-in options or a lighter solution. If the company already relies on an external form platform and does not want to store personal data in Joomla, that external platform may be easier to manage from both a legal and operational perspective.

Another case is a very complex business workflow with multi-step validation, operator roles, approvals, and user portals. Convert Forms Pro can be part of that process, but it should not be treated as a replacement for a full CRM, help desk, or document workflow system. In projects like that, the form is best seen as the entry point, not the whole process.

Practical takeaway: use Convert Forms Pro when the form needs to work inside Joomla and produce a controlled outcome: a submission, an email, a record, a task, an integration, validation, and troubleshooting.

What to Check Before Installation and First Launch

You do not need to run a full site audit before installing the extension, but a few things are worth checking in advance. A form is almost always tied to email, JavaScript, caching, the template, permissions, and external services. If any of those areas are already unstable, the problem usually appears not during installation, but with the first actual submission.

Site Readiness on the Technical Side

First, verify that the site is running a supported Joomla branch and meets the developer's PHP and database requirements. There is no point memorizing version numbers from a third-party article - those can change. It is more reliable to confirm the requirements on the official product page and in the documentation before installation.

Next, make sure Joomla can send email. Convert Forms is not a mail service and relies on Joomla's mail configuration. If the global mail settings are wrong, form notifications will not go out either. Before building a more advanced form, send a test message from the system settings or through another component that is already working, if you have one.

Cache, Optimization, and the Template

Forms rely on scripts and dynamic values. Because of that, it helps to identify in advance which optimization extensions are active on the site: page cache, JavaScript minification, deferred loading, file combining, form protection tools, editors, SEO extensions, and SEF systems. The Convert Forms documentation specifically describes cases where Joomla cache or third-party optimizers affect form rendering, tokens, dynamic Smart Tags, and the /media/com_convertforms/js/site.js script.

If the form will be embedded through a shortcode inside an article and the site uses Conservative or Progressive Cache, plan to test any dynamic fields right away. For forms that rely on URL parameters, PHP prefill, or Smart Tags inside an article, you may need this shortcode variant:

{convertforms ID --skipPrepareContentRender}

This should not be applied to every form by default. It is intended for cases where the normal shortcode shows stale cached values. If the form is rendered through a menu item or module with caching disabled, the situation may be different.

Permissions, Data, and Consent

Before launching the form, decide what data you actually want to store. For a contact form, name, email, subject, and message are usually enough. A service request form may also need a phone number, city, attachment, and consent to data processing. The more fields you collect, the greater your responsibility for storing, exporting, restricting access to, and deleting submissions.

If several administrators work on the site, limit access to submissions to the people who truly need it. In Joomla, this is handled through permissions and carefully structured admin roles. There is rarely a good reason to give full component access just so someone can view submissions if a narrower role would do the job.

What Data You Should Not Collect Without a Real Need

Do not collect passport data, a full street address, financial details, internal order numbers, or other sensitive information if the request can be handled without them. For a support form, a page link, a description of the issue, and a contact email are often enough. If the team later needs more details, they can request them in follow-up communication once the context is clear.

For public-facing forms, it is especially useful to separate required and optional fields. Keep only the fields that are absolutely necessary to respond to the user as required. Everything else should be marked as additional information. That lowers drop-off rates and reduces the amount of data you need to store and protect.

How to Prepare a Test Environment

If the site is already receiving real inquiries, do not test a new form on a live public page. Create a hidden menu item available only to administrators, or use a page that is not linked from navigation. In emails, use test addresses, and in integrations, use a test list, a test webhook, or a temporary CRM pipeline. A test form should validate the product's behavior, not generate real leads.

Installation and Initial Verification in the Admin Panel

After installing the extension, the goal of the first launch is not to build the perfect form. It is to confirm that the component appears in the admin panel, forms can be created, the module can display them, email is sent, and submissions are stored. Only after that is it worth enabling conditional logic, calculations, integrations, and more advanced styling.

The Basic Path After Installation

In the Convert Forms documentation, the starting point is Components -> Convert Forms. This is where campaigns and forms are created and submissions are reviewed. For the first verification, you can either choose a ready-made form template or start with a blank form, add a few fields, and save it.

1. Open Components -> Convert Forms.
2. Create a campaign if you want to separate this form's submissions from other workflows.
3. Create a form from a template or from scratch.
4. Add the minimum fields needed for a basic test: name, email, subject, message, and a submit button.
5. Save the form and confirm that it appears in the list.
6. Create a Convert Forms module or menu item to display the form on a test page.
7. Send a test submission and open the Submissions list.

If the form does not submit at this stage, do not make it more complicated. First check the basics: the script is loading, there are no browser console errors, Joomla mail works, cache is temporarily disabled, the test page is not restricted by access rules, and the form was not inserted into an editor in a way that turned the shortcode into plain text.

How to Tell the Initial Check Was Successful

The initial check is successful when four things happen. The form opens on the public page, the submission goes through without a reload or shows the expected success message, the record appears in Submissions, and a notification arrives at least at one test address. If any of those links in the chain is missing, it is too early to start configuring integrations.

Form Setup: Fields, Behavior, Notifications, and Storage

The most common mistake when working with forms is adding a large number of fields first and only later deciding what to do with them. In Convert Forms Pro, it is better to start from the outcome. First decide what kind of submission the administrator should receive, what data the user needs in the confirmation email, what should be stored in the database, and which fields affect later actions.

Fields and Field Names

Every field should have a clear role. For the user, the important part is the label and helper text. For the administrator, it is the value in the submission and email. For an integration, it is a stable technical name. If a field will later be used in Smart Tags, conditional logic, calculations, or Tasks, do not rename it randomly after launch.

A sensible field set for a standard inquiry form looks like this:

• Name - used to address the person in email and identify them in the admin list.
• Email - needed to reply to the user and send a confirmation.
• Inquiry Topic - helps determine the department, reply template, or conditional task.
• Message - the main content of the inquiry.
• Consent - needed if the form collects personal data and the site's policy requires explicit confirmation.
• Hidden Field - useful for the page source, article author, campaign, or an internal marker, if it is actually needed.

Do not overload the first screen of the form. When visitors see a long list of questions, they are more likely to abandon the submission. For longer workflows, conditional fields are a better approach: ask for the inquiry type first, then show only the relevant follow-up fields.

Administrator and User Notifications

The Behavior -> Email Notifications section controls the emails sent after a successful submission. For the administrator, the goal is to receive complete data without unnecessary noise. For the user, a short confirmation is usually more useful: the request was received, here is what happens next, and here is how to follow up.

The fields Send To Email Address, Email Subject, From Name, From Email, Reply-To Email, and Message deserve deliberate attention. In many cases, it is safer to use the site domain or the mailbox Joomla actually uses to send mail as the sender address. The user's email is usually better placed in Reply-To Email so the administrator can respond without damaging deliverability.

Smart Tags help inject submission data. For example, the email subject can include the submission number or inquiry topic, and the email body can show selected fields instead of dumping every value. But there is no reason to include everything if some fields are internal-only or contain information the recipient does not need.

Email to the Administrator

The administrator email should answer three questions: who submitted the request, what it is about, and where to view the full record. For a small site, it is usually enough to include the name, email, phone number, subject, and message text. For a site with separate departments, also include the selected inquiry type and the page link the request came from, if that field is actually being stored.

The subject line should be recognizable without becoming cluttered. A good pattern is to include the site name, the form type, and the inquiry topic. If all forms send messages with the same subject, it becomes hard to distinguish a consultation request from a technical issue in the inbox.

Email to the User

The user confirmation email should not repeat all internal details. It is usually enough to confirm receipt of the request, mention the selected topic, explain the next step, and provide a contact channel. If the email includes a copy of the user's message, format it clearly so the recipient can quickly understand what was actually sent.

If the site uses an auto-reply, do not promise an exact response time unless the team can consistently meet it. A neutral message is usually better: the request has been received, a specialist will contact you at the address provided, and you can reply to this email if needed. That is more honest and safer from a support standpoint.

Submission Storage and Export

Local storage of submissions is useful as a backup control point. Even if the email never arrives or an external service is temporarily unavailable, the administrator can still check Submissions. At the same time, storing data requires discipline: delete what you do not need, restrict access, do not collect data just in case, and make sure the site's policy matches the form's actual behavior.

If the form is used for internal workflows, think through who is responsible for exports, who reviews new submissions, and how long they need to be retained. Convert Forms includes export and submission management tools, but those do not replace a process. A form without a submission-handling process quickly turns into a data warehouse.

Conditional Fields and Calculations: How to Make the Form Shorter and More Useful

Conditional logic is one of the main reasons to use the Pro version. It helps hide irrelevant fields, change values, add or remove options from a list, and show the submit button only when the user meets the required conditions. In the documentation, this logic is built around the When and Do pattern: when a rule matches, perform an action.

Simple Conditional Logic

Start with a simple scenario. For example, a support form might have a Topic field with the options "Sales," "Support," and "Other." If the user selects "Other," an extra clarification field appears. If they select "Support," a field for a page link or order number appears. The result is a shorter form that still collects the context you actually need.

Inside the builder, it is important to distinguish between the condition source and the target field. The source is the field whose value is being checked. The target is the field you want to show, hide, or modify. If you change list options after the rule is configured, the condition may stop behaving as expected. For production forms, it is better to stabilize the options first and build the rules after that.

Rule Groups and Processing Order

For more advanced forms, rules can be combined into groups. Conditions within a group work as AND, while groups relate to one another as OR. This is useful when an action should fire for one of several possible condition sets. For example, show the submit button if the email field is filled out and the user has accepted the terms, or if an administrator is logged in and testing the form through a separate workflow.

The order of rules matters. The documentation notes that rules are processed from top to bottom, and once a matching group is found, unnecessary browser processing stops. In practical terms, that means you should place broad hide rules first, then rules that reveal specific branches, and finally any narrower refinements.

Calculations and Numeric Fields

Calculations are useful for quote request forms, calculators, scoring systems, day counts, pricing tiers, or internal request forms. A calculated field can pull values from numeric fields, dropdowns, checkboxes, and radio buttons if the options have calculation values assigned. The result can be stored, shown to the user, and included in email.

Do not turn calculations into a hidden financial system. If the result affects payment, a contract, or an important decision, add an administrator-side review step and avoid telling the user the number is final. For a service inquiry, it is better to frame the result as a preliminary estimate.

How to Avoid Flickering Hidden Fields

With conditional logic, fields can sometimes flash briefly before JavaScript hides them. The documentation describes this as a FOUC effect. For fields that should be hidden from the start, you can add the cf-hide CSS class in the field settings. This is not an undocumented hack - it is the documented way to reduce visual flicker.

cf-hide

The check is simple: open the page in private browsing mode, refresh it several times, and see whether hidden fields appear for a split second. If flickering remains, review cache and JavaScript optimization instead of piling on more rules.

How to Test Conditional Logic

Do not test only the happy path. For every rule, run at least three checks: a value that should reveal the field, a value that should keep it hidden, and a submission after switching the value back and forth. The last test matters most because a user may first choose "Support," fill in the link field, and then switch the topic to "Sales." You need to know whether the hidden value is still preserved and whether the form logic should clear it.

If hidden values make it into the email or submission, the administrator may receive unnecessary data and misunderstand the request. In longer forms, it is worth deciding separately which fields are only hidden visually and which should be cleared or ignored in later actions.

Tasks, Integrations, and Webhooks Without the Chaos

Tasks turn the form into a working workflow. After a new submission, the form can send an email, create a Joomla user, subscribe a contact to a mailing list, pass data to a CRM, trigger a webhook, or run another available action. In the documentation, Tasks are described as a combination of app, trigger, and action. The main trigger right now is a new submission, while the available actions depend on the selected app.

How to Design the Task Chain

Do not start by connecting every service at once. First decide what should happen after a submission. For example: store the request locally, send an email to the administrator, send a confirmation to the user, add the email to a mailing list only if consent is checked, and send a webhook to an external system only for submissions with the topic "partnership."

A good task chain looks like this:

1. A new submission appears in Convert Forms.
2. The administrator receives a notification with the key fields.
3. The user receives a short confirmation.
4. An integration runs only when the required condition is met.
5. If the external integration fails, the local submission still remains as the control point.

The documentation emphasizes that tasks run synchronously and can use data from earlier tasks through Smart Tags. That is convenient, but it also requires care: if the first external task depends on an API, the whole workflow needs to be tested against real failures, not just successful submissions.

MailChimp, CRM, and Webhooks

Integrations with email platforms and CRMs rely on configuring the connection, choosing an audience or object, mapping fields, and defining execution conditions. For example, in a MailChimp task, you need to choose the list, map the email and merge tags, decide how to handle double opt-in, and then enable the task. Problems like trying to re-subscribe a deleted contact or running into a compliance state are best diagnosed through the service's own documentation, because at that point the issue is no longer just about Joomla.

Webhooks are a good fit for technical teams that need to send data to an external handler without a built-in integration. A webhook can send a GET or POST request to a specified endpoint and can run conditionally. But a webhook should not be treated as a universal replacement for everything. If the service is supported by a ready-made Convert Forms app, that built-in integration is usually easier for an administrator to manage.

What to Enable Only After Testing

Conditional tasks, webhooks, PHP Scripts, and external CRMs are best enabled only after the basic form is already working. If everything is turned on at once, it becomes difficult to tell whether a failure comes from a form field, a notification, SMTP, an API key, a task condition, spam protection, or page caching.

For each integration, create a separate test: a normal submission, a submission where the condition is met, a submission where it is not, a repeat submission with the same email, and a submission with an invalid value. That helps reveal not only the successful path, but also the boundaries of the behavior.

The Local Submission as a Control Point

Even if the main value of the form is passing data into a CRM or email platform, the local record in Submissions still matters. It proves that the user actually submitted the form and helps separate a form issue from an external service issue. If the record exists but the task did not run, investigate the integration. If the record does not exist, start with the form, scripts, protection, and cache.

For critical forms, it is useful to assign someone to review the submission list. For example, a manager can check new records once a day during the first few weeks after launch. That is not a workaround - it is a normal safety measure during rollout.

Task Execution Conditions

Conditions in Tasks help prevent sending all data to every service. For example, a submission with the topic "Sales" can go to the CRM, while a "Support" submission can go to a help desk or a separate email address. If the consent field is not checked, the subscription task should not run. A task condition should reflect a real user consent choice or a genuine business rule, not just what is convenient for the administrator.

How to Display the Form on the Site: Menu, Module, Shortcode, and Popup

Convert Forms can be displayed in several different ways. The method you choose affects caching, permissions, editing convenience, and how quickly the administrator can locate the form. There is no single best option for every Joomla site.

Menu Item

A menu item is useful when the form needs to live on its own page: a request form, registration form, support form, contact page, or event signup. The advantage is that the page gets a clear URL, menu handling, metadata, access permissions, and fewer caching surprises inside article content. For forms that rely on dynamic Smart Tags or URL parameters, this is often the more predictable option.

Convert Forms Module

The module is useful for a sidebar, footer, template position, or targeted display on selected menu items. The documentation describes the route through Extensions -> Modules, where you choose the Convert Forms type, set the title, pick the correct form, and assign the pages. Here it is important to review the module cache setting, especially if the form contains dynamic values.

Shortcode Inside an Article

A shortcode such as {convertforms ID} is convenient when you want to insert the form into an article or a Custom HTML module. But it is sensitive to editors, content processing, and cache. If the shortcode itself is visible on the page instead of the form, check the Convert Forms system plugin order, the editor mode, and whether the shortcode was escaped as plain text.

If the form depends on dynamic data and Joomla cache shows stale values, use the documented --skipPrepareContentRender variant or render the form through a menu item or module, where caching is easier to control.

Popup Window

The documentation describes displaying a form in a popup through EngageBox, where the form is inserted into the popup content via shortcode or the CMS Content -> Convert Forms dropdown. This is a reasonable option for a newsletter signup, a quick inquiry, or a promotional workflow, but not for a more complex request form with many fields. The more important the data is, the calmer and more focused the submission environment should be.

Practical Example: A Department-Routed Inquiry Form

Now let us build a concrete workflow. The goal is a service-site form where the user selects the inquiry topic and the submission is routed to the right department. At the same time, the record is stored in Submissions, the user receives a confirmation, and the administrator can verify the full result.

Goal and Preparation

We want a "Consultation Request" form with the fields name, email, inquiry topic, message, and consent. If the topic is "Support," we show the "Page URL" field. If the topic is "Request a Quote," the notification should go to the sales address. If the user gives mailing consent, a separate Task can send the email to a mailing platform.

Before you begin, make sure:

• The component is installed and opens under Components -> Convert Forms.
• Joomla mail can send test emails.
• You have a test page or hidden menu item for verification.
• Cache and JavaScript optimization are temporarily configured so they do not interfere with the first round of testing.
• Department email addresses are verified and test emails will not go to real customers.

Setup Steps

1. Create a new form from a suitable template or from scratch.
2. Add the Name, Email, Topic, Message, Consent fields, plus a hidden field for an internal page marker if you need one.
3. In the Topic field, define stable options: "Sales," "Support," and "Other."
4. Add a Page URL field and hide it by default if it should only appear for support requests.
5. Enable Behavior -> Conditional Logic and create this rule: if Topic equals "Support," show Page URL.
6. In Email Notifications, configure the administrator email. In Reply-To Email, use the Smart Tag for the user's email field, while keeping the sender address on the site domain or the system mailbox if that matches your Joomla mail setup.
7. Add a separate notification for the user if your version and settings support multiple notifications.
8. If you use Tasks, add the mailing or CRM task only with a condition that matches the user's consent.
9. Display the form through a menu item or module on a test page.
10. Send several test submissions with different topics and check the emails, the submission list, and the behavior of the conditional field.

Verifying the Result

After testing, open the public page in both a normal window and a private window. Select different inquiry topics. The link field should appear only for support requests. The administrator email should include the topic, the user's details, and the message text. The user email should be delivered to the address entered in the form, not to the site's system address.

In the Submissions list, confirm that records are being stored with the expected values. If the mailing integration is enabled, submit the form once without consent and once with consent to make sure the Task only runs when it should.

Control Tests for Three Departments

Send three submissions: "Sales," "Support," and "Other." For Sales, confirm that the email goes to the commercial address and that the technical field does not appear. For Support, confirm that the link field appears and makes it into the email. For "Other," confirm that the submission is not lost and still reaches the general address even if there is no dedicated rule for it.

After that, submit the form with an error: an empty email field, unchecked consent, or a message that is too short. Validation messages should be clear to the user. If a Russian-language site shows English technical messages, check the language strings, field settings, and available Joomla language overrides.

A Common Detail That Causes Problems

If the form is inserted into an article via shortcode and the site has caching enabled, a dynamic field or Smart Tag may show an old value. In that case, first test the form through a menu item or a non-cached module. If it works there, the issue is not the form itself, but the rendering method and the way cache is being handled.

Another issue is testing from the same browser over and over. Session state, autofill, cache, and saved values can hide the real problem. For final testing, use a private window, a different browser, or a separate test user. This matters especially for forms with hidden fields, UTM tags, login-based conditions, or different email routing paths.

Checking Form Quality After Launch

Once the form is published, it should be tested with more than a quick visual check. A form can look fine and still fail in practice: the email never arrives, a hidden field is not stored, a task does not run, spam gets through, the user cannot understand the error, or the administrator never sees the record.

Post-Launch Mini Checklist

• Submit the form with the minimum valid data and verify the success message.
• Submit the form with an empty required field and check whether the error message is clear.
• Test the mobile view, especially phone fields, date fields, dropdowns, and the submit button.
• Check the administrator email and user email in different mail services.
• Open Submissions and make sure the values are readable without unnecessary internal data.
• Turn cache and optimization back on, then submit the form again.
• Check the browser console for JavaScript errors.
• If Tasks are enabled, test both the matching and non-matching condition paths.

Usability and SEO

The form itself does not improve search rankings, but it does affect user behavior. A form that is too long can hurt conversions, and a poor error message can cost you a lead. On a product or service page built for SEO, the form should appear after useful content, not block the reading flow. If the form opens in a popup, make sure it does not cover important text or annoy the user on the first screen.

From a performance standpoint, do not overload the page with unnecessary integrations. If the form is simple, do not enable extra tasks or protection services without a real reason. If protection is needed, start with the built-in honeypot and add CAPTCHA only when spam is real or the risk is high.

Accessibility and Clear Errors

The form should not be convenient only for the administrator. Check field labels, contrast, error visibility, focus after submission, and keyboard navigation. If the user cannot tell which field is wrong, then even a technically working form is still failing its job.

For longer forms, short helper text next to fields can be useful, but do not turn every field into an instruction manual. A helper should explain the format, such as "Enter the URL of the page where the error occurred" or "Add your order number if available." Wording like that reduces the number of follow-up emails after the form is submitted.

Safe Improvements: Styling, Hidden Fields, and Output Overrides

Improvements should be small and reversible. Do not modify Joomla core or the extension files. For styling, use the form design settings or CSS in the template. To display submissions on a public page, use a Joomla template override if the documentation provides the correct path. For more advanced logic, use documented PHP Scripts, Tasks, or Webhooks - but only after testing.

A Light CSS Tweak for the Button and Spacing

If the design settings do not give you the small adjustment you need, add CSS to the template file or another safe location that will not be overwritten during updates. The example below makes the form button more prominent and adds clean spacing between fields. The selectors should be adapted to your form markup after checking them in browser developer tools.

.convertforms .cf-control-group {
  margin-bottom: 16px;
}

.convertforms .cf-btn {
  border-radius: 6px;
  font-weight: 700;
  padding: 12px 20px;
}

After adding the CSS, test the form on the actual page where it is rendered: a menu item, a module, and an article if you use multiple display methods. Rolling it back is simple - delete the added lines or temporarily comment them out in the template file.

Overriding the Submission List Output

For front-end submission display, the documentation describes a Joomla override. For example, the list can be overridden by copying the file from the component into the template folder. This is appropriate when you need to change how the submission table is displayed for users without changing the component logic itself.

Before creating the override, back up the template and record which file was copied. After updating the extension, verify whether the original component template changed. If it did, the old override may hide important fixes.

PHP Scripts and Their Limits

The Convert Forms documentation includes sections on PHP Scripts and a list of restricted functions. That is an important signal: any server-side code inside the form should be short, clear, and safe. Do not use those areas to bypass permissions, perform file operations, delete data without checks, or run heavy external requests. For most administrative tasks, Tasks and ready-made integrations should be your first option.

Common Convert Forms Pro Problems and How to Diagnose Them

Troubleshooting works best when you follow the chain: form display, submission, storage, email, external task. If you start changing everything at once, you may hide the real cause by accident.

The Shortcode Is Visible on the Page Instead of the Form

Symptom: the user sees {convertforms ID} instead of the form. A likely cause is that the shortcode was inserted in a place where content processing does not run, the Convert Forms system plugin is firing in the wrong order, or the editor turned the shortcode into plain text.

What to check: display the form through a menu item or module. If it works there, the issue is specifically related to the shortcode. Then check the system plugin order, the editor mode, and the insertion method in a page builder or Custom HTML block.

How to fix it: use the Convert Forms module or a menu item if the current editor does not process shortcodes correctly. If you need the shortcode inside an article, review the plugin order and save the code without extra formatting.

The Form Submits, but the Email Never Arrives

Symptom: the submission appears in Submissions, but the notification does not arrive. In that case, the form is working as a data collection tool, and the problem is most likely in the mail chain.

What to check: Joomla mail settings, SMTP, the sender address, Reply-To, the spam folder, the error log, and a test message outside Convert Forms. The email delivery documentation explicitly states that Convert Forms relies on Joomla's mail settings.

How to fix it: configure a valid SMTP setup, use a domain-based sender address, avoid placing the user's email in From Email unless absolutely necessary, and put the user's email in Reply-To instead. If email still fails, enable mail debugging on a test form rather than on the live submission workflow.

An Invalid Security Token Error Appears

Symptom: the form shows an invalid security token message during submission. Possible causes include a session that expires too quickly, page cache, module cache, or a conflict involving the CSRF token setting.

What to check: try the submission again after disabling Page Cache, and review module caching and the Joomla session. If the form has been left open in the browser for a long time, reload the page and submit it again.

How to fix it: set a reasonable session lifetime, disable caching for the form module, or use a display method that does not cache the dynamic form. Consider disabling the CSRF option only after checking the documentation and only on a test form.

Dynamic Fields Show Old Values

Symptom: Smart Tags or URL-based values do not update for different users. This is common when a form is inserted through a shortcode on a cached page.

What to check: open the page with different parameters in different windows, temporarily disable cache, and compare the behavior. Then test the same form through a menu item or module.

How to fix it: use {convertforms ID --skipPrepareContentRender} for the shortcode inside the article if that matches your use case, or render the form through a menu item or module without caching.

Honeypot Blocks the Submission or Honeypot ID not found Appears

Symptom: the form blocks the submission even though the user is not a bot, or a honeypot-related message appears. The documentation links these cases to JavaScript optimizers and caching, especially when the hidden field is generated dynamically.

What to check: disable JavaScript minification and combining on the form page, check JCH Optimize, Route 66, and similar tools, then submit the form again.

How to fix it: update the conflicting extensions, exclude the form scripts from aggressive optimization, or temporarily disable the problematic mode. If spam volume is low, do not add multiple CAPTCHA services at once - first make sure the built-in protection works reliably.

The Integration Returns an API Error or the Subscriber Is Not Added

Symptom: the local submission exists, the email may arrive, but the external task does not run. Possible causes include an invalid connection, a disabled Task, an API error, a missing required field, or a condition that never matches.

What to check: run one test without the condition and then another with it. Check field mapping, audience/list selection, double opt-in behavior, the contact status in the service, and the error message in the task interface.

How to fix it: recreate the connection, enable the task, and verify Smart Tags and conditions. For MailChimp errors related to deleted contacts or compliance states, rely on the service documentation along with the Convert Forms integration documentation.

Video Walkthrough for a Help Desk and Submission Routing Scenario

For a visual breakdown of a similar use case, you can watch Tim Davis's video about using Convert Forms with a help desk workflow. It is useful not as a universal setup guide for every setting, but as a reference for the intent cluster of "Joomla support form," "department-based submission routing," and "conditional email delivery." The video shows department selection, email setup, and form verification on a Joomla site.

It makes the most sense to watch it after the practical example section, because that makes it easier to connect the video to topic setup, email notifications, and result verification. Keep in mind that the Joomla and Convert Forms interface may differ from what is shown in the video, so confirm exact menu items against the current documentation.

When Convert Forms Pro Is the Right Choice

Convert Forms Pro is worth using when your form needs to be part of a Joomla workflow instead of acting like a random widget. The product is strongest in scenarios involving conditional fields, notifications, local submissions, integrations, Tasks, calculations, spam protection, and multiple display methods across the site.

Before launch, do not try to enable every feature at once. First create the form and verify submission and storage. Then add notifications, then conditional logic, then integrations and protection. That sequence reduces hidden errors and makes troubleshooting much clearer.

If you already know what kind of form the site needs, you can go to the Convert Forms Pro download, install it on a test site, and run a short verification: the form opens, the submission is stored, the email arrives, and the public page does not break because of cache or optimization.

The final decision is straightforward: choose Convert Forms Pro when you need a manageable Joomla form builder with practical automation. If all you need is a minimal form with no storage and no follow-up actions, start with a simpler solution and come back to the Pro version when there is a real need for conditional logic, Tasks, or integrations.