ChronoForms Pro - Joomla Extension

ChronoForms Pro for Joomla Guide: forms, events, notifications, and result verification

ChronoForms Pro is best understood not as a simple field builder, but as a working environment for Joomla forms. A form here is made up of pages, load and submit events, visible elements, server-side actions, conditions, shortcodes, and different publishing methods on the site. In this guide, we will walk through how to configure it without turning the process into chaos: what to check before installation, how to build the form, how to set up email notifications and submission storage, how to publish the result through a menu item, article, or module, where to enable spam protection, and how to troubleshoot cases where the form does not send email or does not appear on the page.

This article is written for a Joomla site owner or administrator who already understands what the form is supposed to do, but does not want to reduce it to a basic set of "name, email, message" fields. ChronoForms is especially useful when you need control over the logic: show a field only for a selected option, send different emails, save data, pass the submission into a table, create a multi-step form, or temporarily enable debugging.

In official sources, the current product line is usually called ChronoForms or ChronoForms 8, while product listings and user searches often use the name ChronoForms Pro. In this article, ChronoForms Pro refers to an installed and validated working version of the Joomla extension where the administrator can use advanced features without public-side limitations. Wherever a feature depends on a separate plugin, module, third-party service, or service keys, that is noted separately.

The purpose of this guide is not to give you a promotional overview, but a practical roadmap. After reading it, you should be able to decide whether ChronoForms Pro is a good fit for your site, build a contact or request form, verify email delivery, enable data storage, publish the form in the right place in Joomla, and understand when it makes sense to look at alternatives such as RSForm! Pro, Convert Forms, or Visforms.

What the extension does and where it works best

ChronoForms Pro is designed for situations where a site needs to do more than simply display a form to the user. It needs to process that form as a small workflow. The simplest example is a contact form: a visitor enters their name, email, and message, the site validates required fields, sends an email to the administrator, shows a thank-you message, and saves a record. But the same mechanism can be extended into a service request form, questionnaire, department-routing form, file upload form, Google Sheets entry, subscription form, multi-step survey, or even an internal staff form.

The product's main strength is the combination of Views and Actions. Views control what the user sees in the browser: fields, buttons, HTML blocks, messages, JavaScript, and security elements. Actions handle server-side work: sending email, reading or writing data, running PHP logic, redirecting the user, or talking to external services. This model is more complex than "add a field and click save," but it gives you much more control.

That matters even more in Joomla. A form can be published as a standalone menu item, embedded into an article through a plugin, or published through a module in a template position. That means the same form alias can be reused in different parts of the site, as long as you understand in advance which publishing method a given section actually needs.

Who ChronoForms Pro is a good fit for

This extension is a strong fit for administrators who want to build forms around a real process rather than a single generic template. It works well for service websites, educational projects, clubs, associations, directories, internal portals, and small business workflows where a submission needs to go through multiple checks or be routed into multiple channels.

• You need forms of varying complexity, from simple contact forms to multi-page questionnaires.
• You need conditional fields, dynamic lists, events, custom validation, or data handling.
• It is important to store submitted data instead of relying only on email delivery.
• You need to publish the form in different ways: menu item, article, system plugin, or module.
• The administrator is willing to spend time understanding the logic of Pages, Events, Views, and Actions.

When the product may be more than you need

ChronoForms Pro is not always the best first choice. If your site only needs one very simple signup form with a built-in marketing service integration and no complex logic, a more specialized tool may get you there faster. If your team is not prepared to test email delivery, permissions, spam protection, and post-update behavior, ChronoForms flexibility can quickly turn into a collection of settings nobody fully understands.

User reviews in the Joomla directory highlight this tradeoff well: the product is often praised for its power and conditional logic, but people also note that the learning curve and version transitions require attention. That is why the right way to start is not with the most complex form possible, but with a short working scenario you can verify from submission to stored data.

How a form is structured: pages, events, Views, and Actions

Before you start configuring anything, it helps to understand the internal mechanics. In ChronoForms, a form consists of one or more pages. Each page has a load event and a submit event. The load event usually contains everything the user should see right away: fields, containers, text blocks, spam protection, CSS, or JavaScript. The submit event contains everything that should happen after the button is clicked: validation, email, data storage, a thank-you message, a redirect, or a call to an external service.

Think of it as a mini application inside Joomla. The user only sees the finished form, but the administrator works with a chain: show the form - accept the data - process the data - show the result. If an action is placed in the wrong event, the form may look correct while producing the wrong outcome: the email may never go out, the message may appear at the wrong time, the data may not be saved, or the debug output may show an empty variable.

Views display, Actions execute

The most common beginner mistake is mixing up display elements and server-side processing. An email field, submit button, text above the form, or thank-you message are visible elements. They either render the interface or show the user a result. An Email action, database write, data lookup, PHP code, or redirect are actions. They do not necessarily display anything, but they do change state or send data somewhere else.

In a working form, order matters. If you show a thank-you message first and only then try to run validation, the user gets the wrong signal. If the Email action comes before the action that prepares the data, the email may go out without the value you need. That is why, after building a form, it helps to read the chain from top to bottom and ask: "What does the system already know at this step?"

Form alias as the connection point with Joomla

The form alias is not just for keeping things organized in the admin panel. Joomla uses it to determine which form to open from a menu item, which form alias to insert into a shortcode inside an article, and which form to display inside a module. It is best to choose a short, clear, stable alias from the start, such as contact-request, service-quote, or event-registration. You can change the alias after publication, but then you will need to check the menus, articles, and modules where that form is already in use.

Practical check: if the form opens in Preview but does not appear in an article or module, compare the form alias in the form editor with the alias used in the publishing method first. One extra character or an old alias left behind after renaming often looks like "the form is broken."

What to check before installation and first launch

Setup should not turn into a separate project, but for a form builder it matters more than it does for a decorative module. A form accepts user data, sends email, may upload files, write to the database, and connect to third-party services. A configuration error is not always visible right away: the page may open normally while the email never arrives or the record is never saved.

Joomla and environment compatibility

The Joomla directory lists ChronoForms as compatible with current Joomla branches, including Joomla 3, 4, 5, and 6. In practice, before installation you should still verify that you have a backup, the right PHP version, access to the extensions installer, and administrator permissions. If the site is older, test the extension on a copy first. Forms often depend on the template, cache plugins, mail settings, and front-end JavaScript.

Pay special attention to email. ChronoForms may build the email correctly, but actual delivery depends on the site's and server's mail configuration. If Joomla is using unsuitable mail settings, the message may end up in spam, be rejected by the recipient domain, or fail to send at all. So before launch, it makes sense to send a separate test email from Joomla and confirm that the sender, domain, and SMTP setup are aligned.

Component, plugin, and module

The official installation guide shows the main component being installed through the Joomla Extensions Installer. But how the form is published may depend on additional parts. For a standalone page, a ChronoForms menu item is usually enough. To embed the form in an article, you need the ChronoForms8 content or system plugin. To publish it in a template position, you need the ChronoForms8 module. In a comment on the official installation article, a user points out this practical difference, and the developer confirms that the component is installed first, while the plugin is required for the shortcode scenario.

• If the form should be a standalone page, plan for a menu item and check the Options tab.
• If the form should live inside an article, install and enable only one appropriate plugin variant ahead of time.
• If the form should appear in a sidebar, footer, or template position, use the module and assign it to the right menu items.
• If the form is used in multiple languages, think through aliases, text, and publishing methods for language-specific menus in advance.

Permissions, cache, and a test page

Before the first launch, create a test page that is either hidden from casual visitors or not linked from the main menu. That lets you verify the form without risking empty or duplicate submissions. If the site uses aggressive caching, exclude the test form page while you are configuring it. Forms with dynamic fields, spam protection, and custom events do not tolerate caching as well as a regular text article does.

Installation and initial verification in Joomla

Installing ChronoForms Pro in Joomla starts the standard way: the administrator opens System, goes to the extensions installer, chooses installation from the directory or package upload, and installs the component. After installation, a ChronoForms section should appear in the admin panel with a list of forms and a button to create a new one.

Do not start with a full production form. First create a short test form with one text field, one email field, and a button. That lets you validate the basic connection between the extension, Joomla, the template, and the mail setup. Once the short workflow works, it is much easier to expand it by adding messages, logging, spam protection, and conditional logic.

The first form draft

1. Open the ChronoForms component in the Joomla admin panel and create a new form.
2. Give it a clear title for the form list and a short alias without spaces.
3. Save the form so quick saves and preview become available.
4. In the Load event, add the fields the user should see: name, email, message, and a submit button.
5. In the email field settings, define a field name that will be easy to use later in shortcodes, such as email.
6. Add basic validation rules: the field is required and the value must look like an email address.
7. In the Submit event, add an Email action and a Message view with a confirmation.
8. Click Preview, submit test data, and confirm that the message appears after submission.

What counts as a successful installation

A successful installation is not just the absence of an installer error. For a form, you need to verify the entire minimum path: the form opens in admin preview, the fields accept data, validation rules trigger, the Submit event runs, the thank-you message appears, the Email action does not return an error, and if logging is enabled, the record is available through Data in the form list.

If you plan to use the form in an article, do not stop at Preview. Create a test article and insert a shortcode like {chronoforms8}form-alias{/chronoforms8}. If the form should be published as a module, publish the module only on a test page and verify the menu assignment. That helps you separate errors in the form itself from errors in the publishing method.

Detailed configuration after installation

After installation, it helps to go through the settings in a deliberate order. Start with the form structure and field names, then submission processing, then data storage, then protection, then the publishing method. If you do it in the opposite order, it is easy to end up with a form that looks good but is hard to troubleshoot.

Field names and shortcodes

Shortcodes in ChronoForms let you insert values from the form, user, session, page URL, and values returned by actions. For an everyday form, the most common need is the values submitted through the fields. That is why field names should be stable and readable: name, email, phone, message, service_type. Then it is much easier to use expressions like {data:email} in an email, message, or action without having to guess what the field was called in the builder.

Do not use random field names like field7 if the form is going to live longer than a single test. It will work technically, but a month later it will make debugging harder. This becomes especially obvious in emails, where you need to insert the sender's name, reply address, and message text.

Email action and Reply settings

The Email action is one of the key elements in the Submit event. It is worth checking the recipient address, subject, email body, reply name, and reply email. The official documentation shows that Reply settings can pull field values through shortcodes, such as the sender's name and email. That is convenient: the administrator receives a message from the site, clicks Reply in the mail client, and replies to the user rather than to the site's technical address.

The email body should be clear, not just a single variable pasted in. For a standard request, it is enough to list the submitted fields and leave a service line with the page URL or form type. If the form matters, enable data storage so the email is not the only copy of the submission.

Log Data and reviewing submissions

The form settings include a Log Data parameter. The official article notes that it is usually enabled by default, and saved records can be opened through the Data link in the Forms manager. On a real site, this is one of the most valuable safeguards: even if the email lands in spam or the mail server is temporarily unavailable, the administrator can still review the submitted data in the admin panel.

Recommendation: do not disable logging on the first version of the form until you are sure email delivery is stable and users are not running into validation issues. If the data is sensitive, think separately about retention time and which administrators should have access.

Spam protection

ChronoForms supports several protection methods: reCAPTCHA, hCaptcha, ALTCHA, Cloudflare Turnstile, dynamic questions, and honeypot. The right choice depends on your audience and privacy requirements. reCAPTCHA requires the selected version to match the keys you use. ALTCHA is added as a security view in the Load event and validated on submission; a comment on the official guide shows a common symptom: if the challenge returns a verification failed error, check the secret key in the view settings.

For a simple contact form, do not enable several complex protection methods at once. Start with one mechanism, send a few test submissions, and check it in a mobile browser and in incognito mode. If the form lives on a cached page, separately confirm that the challenge is not broken by caching or stale markup.

A small CSS adjustment without touching core files

ChronoForms allows you to add custom CSS through the relevant views or form settings. The safe approach is not to edit extension files or depend on random internal classes, but to add your own class to the form container or outer block and style only that. For example, if you wrapped the form or its HTML block in a class like cf-lead-form, you can gently improve spacing and the button appearance:

.cf-lead-form {
  max-width: 720px;
}

.cf-lead-form .form-control {
  margin-bottom: 14px;
}

.cf-lead-form button[type="submit"] {
  min-width: 180px;
  font-weight: 600;
}

Test that change on a copy of the page and in mobile view. Rolling it back is simple: disable the CSS view or remove the custom class. Do not edit Joomla core, component files, or the template just for one form if the same goal can be handled with local CSS.

Publishing the form on the site: menu, article, or module

In Joomla, the publishing method affects page behavior, headings, module assignments, caching, and ease of maintenance. ChronoForms supports three main scenarios: a menu item, a shortcode through a plugin, and a module. All three use the form alias, but each one fits a different use case.

Menu item

A menu item is the best choice when the form is a standalone page: a contact form, service request, event registration, questionnaire, or support request. In Joomla, you create a new menu item, choose the ChronoForms8 type, and specify the form alias in the settings. This method works well for SEO, breadcrumbs, module assignments, and page title control.

If the form does not open through the menu, check the Options tab, the form alias, and the menu item status. Do not confuse the menu item title with the form alias: the user sees the title, but ChronoForms looks up the form by alias.

Embedding into an article through a plugin

A shortcode inside an article is useful when the form needs to be part of a longer page, for example after a service description, at the end of a tutorial, inside an event page, or next to content. The official instructions give the format {chronoforms8}form-alias{/chronoforms8}. For this to work, the appropriate ChronoForms8 plugin must be installed and enabled. If multiple variants are enabled at the same time, confusion is possible, so the documentation recommends using just one.

The advantage of embedding in an article is content flexibility. The downside is that the form depends on Joomla content processing and third-party extensions that may filter text, cache the page, or change plugin event order. If the form is important, test it after publication in normal user mode, not only in admin preview.

ChronoForms8 module

The module is meant for forms placed in a template position: a sidebar, footer, block next to an article, or homepage area. In the module settings, you specify the form alias, publication status, and menu assignment. This works well for short callback, signup, or request forms, but it is not ideal for long questionnaires with many fields.

If the form is not visible in the module, check not only ChronoForms, but also standard Joomla settings: template position, module status, language, access level, menu assignment, and whether that position exists in the current template.

Practical example: a consultation request with email and saved data

Let us walk through a concrete scenario that can be adapted for most service websites. The goal is a "Consultation Request" form with name, email, phone, inquiry topic, message, and consent to data processing rules. After submission, the administrator receives an email, the user sees a thank-you message, and the record remains in the form data for verification.

Goal and preparation

The goal is to create a manageable form that can be published as a standalone page and tested without a public menu link. Before starting, the main ChronoForms component should be installed, Joomla email sending should be configured, and a test page or hidden menu item should already exist. If you plan to embed the form into an article, install the plugin in advance, but for the first test it is still more convenient to use Preview or a menu item.

Setup steps

1. Create a new form titled "Consultation Request" with the alias consultation-request.
2. In the Load event, add a Text field for the name with the name name and required validation.
3. Add an Email field with the name email, mark it as required, and enable email format validation.
4. Add a Text field for the phone number with the name phone. Make it required only if a phone call is actually needed.
5. Add a Dropdown or Radio field with the name topic, where the user chooses the type of inquiry.
6. Add a Textarea with the name message and a clear label so the user provides context.
7. Add a Checkbox for consent if your site and data handling policy require it.
8. Add a Button with a clear label, for example Send inside the UI if the form interface remains in English.
9. In the Submit event, add an Email action to the administrator's address.
10. Use a short data-based subject line such as New request from {data:name}.
11. In Reply settings, insert {data:name} and {data:email} so replies go to the user.
12. Add a Message view after successful processing: "Thank you, your request has been sent. We will review your message and get back to you."
13. Make sure Log Data is enabled, save the form, and submit a test request.

Verifying the result

After the test submission, check four places. The browser should show a confirmation. The administrator's inbox should contain the submitted data. If Reply settings are configured correctly, hitting Reply should address the user's email. And if logging is enabled, a record should appear in Forms manager through Data.

Details people often overlook

Do not use the user's address as the technical sender of the email if the site's mail domain does not match the user's domain. It is safer to send the message from the site's domain and insert the user's email into Reply settings. That reduces the risk of rejection by the recipient's mail policies.

If a dropdown affects who should receive the email, do not overcomplicate the first version. Start with one email to the administrator and data storage. Once the basic flow is stable, add a condition, separate Email actions, or an Event Switcher. That order saves time because you will know the issue was introduced by the new logic, not by the base email delivery.

Conditional logic, dynamic fields, and multi-page scenarios

ChronoForms Pro becomes especially useful when the form needs to react to user input. That can mean something as simple as hiding a textarea when a certain radio option is selected, loading new dropdown options after another field changes, moving the user to a different form page, or executing an action only when a condition is met.

Run Conditions for Views and Actions

Run Conditions behavior lets you enable or disable a view or action based on a condition. The official guide describes the basic setup: enable the behavior, add a condition, use a shortcode to check the value of a field, URL parameter, or action variable, and if needed specify the values that must match. This is useful when an email should only be sent for a certain request type, or a message should only be shown after successful validation.

An important detail is that the condition must rely on a value that already exists at the moment it is evaluated. If one action returns a variable later than another element tries to check it, the condition will not work. That is why, for a complex form, it helps to sketch out the processing chain and verify the order from top to bottom.

Triggers and Listeners for field behavior

Triggers and Listeners are useful for front-end interactivity. In the official example, a textarea is hidden when the page loads and shown when the user selects the required radio option. The logic has two parts: the trigger reports that an event happened, and the listener reacts to that event and performs an action such as show or hide.

You can use this model for blocks like "please explain the reason," "add a comment," "choose a delivery type," or "show company field." But do not overload the form. If the user does not understand why a field disappeared, it is better to add a short explanation or make the form steps easier to follow.

Dynamic dropdown and Reload

A dynamic dropdown updates its options after another field changes. The ChronoForms documentation describes the setup as a combination of Event Trigger, Advanced Listener, a separate page with a unique Page Group, and a PHP action that returns a JSON array with text and value keys. A similar approach is used for Reload, where a field is replaced with new content from another form page.

This is a powerful mechanism, but it needs especially careful testing. If the separate service page has the wrong alias or shares the same Page Group, the AJAX request may not get the response it needs. If the PHP action returns invalid JSON, the dropdown will not update, and the user will either see the old options or an empty list.

Integrations, data, and form security

ChronoForms Pro can do much more than send email. Official materials mention database operations, Google Sheets, PDF through TCPDF, payment actions, signature capture, camera photos, and working with user data. But you should only expand the form after the base submission flow and logging are stable.

Google Sheets and external services

Google Sheets integration requires several external steps: getting the Sheet ID and worksheet name, configuring access, enabling the Google Sheets API, creating a service account, obtaining a JSON key, and specifying its path in the ChronoForms action. This is not a one-click checkbox. The setup is helpful when managers prefer to work in a spreadsheet, but it also adds dependency on Google Cloud, access permissions, and key file security.

If you use a service account, store the JSON file outside public access, do not share it in public materials, and verify the path with a safe shortcode such as {path:root} only where that makes sense. Real keys or secrets should never be published in an article. For testing, use a separate spreadsheet, not a live document with customer data.

Database and export

For many sites, built-in logging and record review through Forms manager are enough. If you need to build a separate catalog, report, or connection to other tables, ChronoForms supports database actions. The key thing here is not to confuse storing form data with building a full business system. The more logic you move into the form, the more important it becomes to document field names, actions, conditions, and execution order.

Shortcodes support functions such as quote, encode, and join, which help prepare values for a database or arrays. But that does not mean you should write complex SQL without careful validation. If the form accepts user input, treat that input as untrusted data, use built-in actions where possible, and avoid arbitrary queries unless you are confident they are safe.

Payments, signature, photo, and files

Support for payment services, digital signatures, photos, and files expands what ChronoForms can do, but it also raises the stakes. Payment actions require separate provider-side validation and correct webhook handling. Signatures and photos may count as personal data. Files require limits on size, type, and storage location. If you need this kind of form, start on a separate test copy and verify not only successful submission, but failure paths too: wrong file, empty signature, upload error, and repeated submission.

Fields, validation, and messages: how not to break the user journey

A form can be technically correct and still work poorly for visitors. Usually the problem is not ChronoForms itself, but how the administrator defined the fields, required settings, and messages. The user should understand what is expected, why a field was rejected, and what happened after submission. This matters even more on Joomla sites with different audiences: the same component may power a service request, support request, internal questionnaire, or event registration form.

Start with the minimum amount of data. If the manager needs an email address to reply, a name for greeting, and the question text for context, do not add ten more fields just in case. The longer the form, the more abandonment you will get and the harder it becomes to troubleshoot. Extra fields are better shown conditionally: for example, if the user selects the topic "technical problem," show a page URL or order number field; if they select "partnership," show a company field.

Field names should support long-term maintenance

In ChronoForms, field names are used in shortcodes, emails, conditions, debugging, and integrations. So a field name is not just a technical string. It needs to make sense to the person who opens Form Debug a month later and tries to understand why the phone number is blank in the email. Use short English technical names without spaces: name, email, phone, topic, message, department, file_upload. The visible labels can be in Russian or another site language, but the technical names are best kept stable and neutral.

If the form is already published, change field names carefully. After renaming, you need to verify the email, Reply settings, Run Conditions, dynamic dropdown, stored data, and external integrations. The old name may still remain in the email body or a condition, and then the form will submit without the variable you need. A good practice is to write down where the field is used before making the change, then submit a test request with unique values afterward.

Validation should help, not argue with the user

A field should be required only when there is a real reason for it. Email is usually required if you need to respond, but phone can be optional if the site allows written communication. A file field should not be required if the user can first describe the issue in words. Rules that are too strict often create false errors: the user enters a phone number in a normal format, but the form only accepts one pattern; the user writes a short message, but the form requires too many characters; the user selects "other," but the extra field never appears.

ChronoForms supports standard validation rules as well as custom validation through JavaScript or PHP. The official Valid Function guide shows that a JavaScript function can return true for an acceptable value or an error string, while PHP validation runs after submission. That mechanism is useful when a built-in rule is not enough, but the code should stay small and testable. Do not add custom validation just because it looks clever. First ask: what problem does it prevent, and how will the user know what to fix?

Practical rule: if you can explain the validation rule to the user in one sentence, it is probably reasonable to add it to the form. If it takes a whole paragraph of technical conditions to explain, it is usually better to simplify the field or move that complex check to the stage where an administrator reviews the request.

The post-submission message should close the loop

The Message view after the Submit event is not a formality. It is the only place where the user gets confirmation that the action is complete. A good message answers three questions: was the request accepted, what happens next, and does the user need to do anything else? For a consultation form, something like "Thank you, your request has been sent. We will review your message and reply to the email address you provided." is enough. For a form with a file upload, mention that the attachment was received only if the file was actually processed successfully.

Do not promise timelines your team cannot support. Do not write "we will respond immediately" if requests are reviewed manually. Do not show a thank-you message before critical actions have actually completed. If the email was not sent or the data was not saved, it is better to show a clear error than to create the illusion of a successful submission. For complex forms, you can use Event Switcher or Run Conditions so different outcomes display different messages.

How to test validation

Do not test only the perfect submission. Submit the form without required fields, with an invalid email, with a long message, with Cyrillic text, from a mobile device, over a slow connection, and by resubmitting after an error. If the form has a conditional field, test both paths: when it is hidden and when it is shown. If there is an upload field, test an allowed file, an oversized file, and an unsupported file type.

Record the test results in a simple list. For each error, it should be clear where it happens: in the front end, in JavaScript validation, in PHP validation, in the Submit event, in the Email action, in data storage, or in a third-party service. This approach helps not only at launch, but also after updating Joomla, the template, or ChronoForms itself.

Multilingual forms, access control, and support on a live site

On a real Joomla site, a form rarely exists in isolation. The site may have multiple languages, different user groups, restricted sections, caching extensions, a template with its own JavaScript, and administrators with different permissions. ChronoForms Pro gives you flexibility, but for that exact reason the form needs to be maintained as part of the site, not as a separate picture inside the component.

Multilingual support and form text

The official product page points to multilingual support and shortcodes for language strings. For the administrator, that usually means two possible approaches. The first is to create separate forms for different languages if the structure, recipients, and text differ significantly. The second is to use locales and language strings inside a single form if the logic stays the same and only the labels, messages, and explanatory text change.

For a small site, it is usually easier to start with separate language-specific forms: contact-ru, contact-en, support-ru. That makes email and text testing easier. For a larger project with the same logic across languages, it is more convenient to maintain one form and move the visible text into localization carefully. In either case, do not mix languages within one user journey: field labels, error messages, and the thank-you message should match the language of the page.

Also check the publishing method. If the form is published through a menu item, use Joomla language menus. If it is embedded in an article, make sure the shortcode is inserted into the correct language version of the article. If it is published through a module, verify the module language and its menu assignment for the appropriate language menu items. Many supposed "ChronoForms bugs" on multilingual sites turn out to be Joomla assignment issues instead.

Access levels and restricted forms

Some forms should only be available to logged-in users: internal requests, member-only forms, customer support requests, or employee questionnaires. In those cases, use Joomla's standard mechanisms for access level on the page, article, or module. Do not rely on a hidden link alone. If a form accepts data that guests should not be able to submit, the restriction should exist at the publication level and, where necessary, inside the form logic as well.

Shortcodes can insert user data such as id, username, name, or email. That is convenient for prefilling or routing a request, but it requires care. User data should not be shown to unnecessary people, and emails sent to administrators should contain only the data that is actually needed for processing. If a form is restricted to authenticated users, test it in two modes: as a user in the correct group and as a guest.

Cache, template, and JavaScript

Forms with spam protection, conditional fields, dynamic dropdowns, and reload scenarios are more sensitive to caching than static pages. If the site uses page caching, JavaScript minification, or script aggregation, test the form after those optimizations are enabled. Do not assume the problem is in ChronoForms until you have checked a test page without aggressive caching.

Typical conflict symptoms include a field that should appear after selecting a radio option but does not, a dropdown that does not refresh, a captcha that fails, or a form that works in Preview but breaks on the public page. In those cases, compare three environments: Preview, the public page without caching, and the public page with caching. If the issue only appears in the last case, look for an exclusion for the form page or the protection scripts.

Documenting the form for future support

A complex form deserves a short technical note. It does not need to be full documentation. It is enough to note the alias, publishing method, list of important fields, email actions, enabled protections, external services, conditions, and the place where the administrator reviews the data. That kind of note saves hours when the site is updated or a new support person takes over.

A good note format looks like this:

• Form alias: consultation-request.
• Publishing: the "Request" menu item and a test article with the shortcode.
• Critical fields: name, email, topic, message.
• Submit event: Email action to the administrator, Message view, Log Data enabled.
• Protection: one selected captcha/security view, with keys stored in the service settings.
• Post-change check: submit a test, verify the email, Reply settings, and the record in Data.

If the form is connected to Google Sheets, PDF, payments, or a database, add a separate line for the external dependency and the responsible owner. Do not store secrets in this note. It is enough to say where they should be checked and who has access.

Common problems and troubleshooting

ChronoForms Pro troubleshooting is best approached from simple to complex. First check whether the form opens in Preview. Then verify the publishing method in Joomla. Next enable Form Debug in the form settings and inspect the data, vars, and info shown below the form. Only after that should you start changing conditions, the Email action, or third-party integrations.

The form opens in Preview but is not visible on the site

Symptom: the form works in admin preview, but nothing appears in the article, module, or menu item on the site.

Likely causes: incorrect form alias, the shortcode plugin is not enabled, the wrong menu item type was selected, the module is unpublished, the module is not assigned to this menu item, or the access level or language does not match.

What to check: compare the form alias with the alias used in the menu, shortcode, or module. For an article, confirm that the required ChronoForms8 plugin is enabled and that conflicting plugin variants are not enabled at the same time. For a module, check the template position and assignment.

How to fix it: first publish the form as a standalone menu item. If that works, the problem is in the plugin or module scenario. After fixing it, clear both page cache and browser cache.

Email does not arrive after submission

Symptom: the user sees a thank-you message, but the administrator does not receive the email.

Likely causes: incorrect recipient address, a problem with Joomla mail settings, the message is going to spam, the server is blocking delivery, or the Email action is not being executed because of a condition or because it is placed in the wrong event.

What to check: enable Form Debug, confirm that the Submit event runs, and make sure the Email action is in the correct place. Test email sending from Joomla itself, check the spam folder, and review hosting logs if they are available. Make sure Reply settings are not replacing the site's technical sender with the user's address.

How to fix it: configure proper SMTP in Joomla, use a sender address on the site's own domain, and place the user's email in Reply settings through {data:email}. While troubleshooting, temporarily disable any extra conditions around the Email action.

Data does not appear in the Data list

Symptom: the form submits, but no record is visible through the Data link in Forms manager.

Likely causes: Log Data is disabled, the form is not saving the expected fields, submission is interrupted by an error, or the administrator is looking at the data for a different form after an alias change or copy.

What to check: open the form Settings and verify Log Data. Submit a new test request with unique text. Confirm that you are opening Data for the correct form.

How to fix it: enable logging, save the form, and submit it again. If the data is sensitive, define retention and administrator access rules after troubleshooting is complete.

ALTCHA or reCAPTCHA returns an error

Symptom: the user sees a verification error, the challenge fails, or the submit process does not complete.

Likely causes: incorrect secret key, a mismatch between the reCAPTCHA version and the keys, page caching, blocked external scripts, or a domain error in the service settings.

What to check: verify the keys and the selected protection type. For reCAPTCHA, the key version must match the view version. For ALTCHA, the developer notes in a comment on the guide that a verification failed error should prompt you to check the secret key.

How to fix it: update the keys, clear the cache, test in incognito mode and on a mobile device. If the form is critical, temporarily switch to a simpler protection mechanism and restore the more complex protection after validation.

A conditional field does not appear or hide

Symptom: the selected radio option or dropdown should show an extra field, but the interface does not change.

Likely causes: the trigger and listener use different names, the listener is assigned to the wrong element, the wrong action is selected, or the form's JavaScript conflicts with the template or caching.

What to check: compare the trigger and listener names carefully, including stray spaces. Confirm that the event is actually happening, for example a value change on the intended field. Temporarily disable JavaScript minification on the test page if it is enabled.

How to fix it: simplify the scenario to one trigger and one listener, save the form, and test in Preview. Once that works, add the remaining conditions back one at a time.

A dynamic dropdown does not refresh

Symptom: the field should load new options, but it stays empty or keeps showing the old list.

Likely causes: the separate options page has the wrong Page Alias or Page Group, the PHP action returns invalid JSON, or the listener calls the wrong alias.

What to check: compare the alias in the Advanced Listener with the alias of the service page. The Page Group must be unique so the service page can be reached directly by the request. Verify the JSON format: an array of items with text and value keys.

How to fix it: first return a static test JSON from the PHP action, then connect the real data. If the dropdown works after that, the issue was in the data source rather than the listener.

How to verify a finished form before publishing

Publishing a form should be a separate stage, not an accidental click after configuration. This matters especially for forms that affect sales, support, registration, or the collection of personal data. Test the form as a normal user, not as an administrator with elevated permissions.

Minimum checklist

• Open the form on the public site, not only through Preview.
• Submit an empty form and confirm that required fields show clear errors.
• Submit a valid request and verify the thank-you message.
• Check the administrator email, Reply settings, and the spam folder.
• Open Data and confirm that the record was saved.
• Check the mobile layout and long field values.
• Check the page after clearing cache and in incognito mode.
• If spam protection is enabled, test it in a normal browser and on a mobile connection.

Verification after changes

After every meaningful change, do not repeat the entire checklist - repeat the path that could have changed. Added a new required field? Test validation, email, and stored data. Changed the alias? Test the menu, shortcode, and module. Added Run Conditions? Test both scenarios: when the condition matches and when it does not.

If the form is used on a live site, keep a short internal note: the form alias, where it is published, which Email actions send mail, which external services are connected, and which fields are required. That makes support much easier after Joomla, template, or extension updates.

When ChronoForms Pro is the right choice

ChronoForms Pro is worth using if you are ready to treat the form as a process: think through the fields, event order, email, data storage, publishing method, protection, and result verification. Its real strength is not just drag and drop, but the ability to build a form around an actual Joomla site workflow.

For the first working version, do not try to use every feature at once. Build a short form, enable logging, configure the email, verify publishing through the Joomla method you need, send several test submissions, and only then add conditional logic, dynamic fields, Google Sheets, PDF, payments, or custom code. That approach lowers risk and makes troubleshooting much clearer.

If, after testing, you realize this is exactly the kind of flexibility you need, you can get the ChronoForms Pro package and test the extension on a site copy or a separate test page. It is a strong choice when you already know the path the submission should take: from the field on the page to the email, stored data, and a clear confirmation for the user.