FAQs

Most of the Anti-Spam features use a random identifier being created when the form is loaded, a copy of this is saved in the User session, and is checked when the form is submitted. If the page containing the form has been cached then the identifier will never match and the Anti-spam check will always fail. This is true for ChronoForms Captcha; Security Questions; and the Security Token. The HoneyPot Trap and ReCaptcha use different approaches and will probably work correctly.

Any form that passes variable data in hidden inputs may fail - because the data in the cached copy will not be the value created by the current user. You can avoid this problem by saving variable data in the User Session instead of using hidden inputs.

1. Insert the form inside a module then load the module using the "Load module position" plugin, this gives you the same effect but its extra 1 step.
2. Disable the "Relative URL" setting in your form, its under the HTML action settings in v5, and under the form Edit page in v4
3. Don't include the form inside an article, use a menu item of type Chronoforms instead.
4. Disable the Cache completely if you are fine with that ?

You can force Joomla! to clear the cache by adding this code to a Custom Code action in the OnLoad event of your form:

<?php
$cache = JFactory::getCache('com_chronoforms');
$cache->clean();
?> 

But this will only work if the form is loaded from a URL that includes 'option=com_chronoforms' that is; from the form URL, or from a ChronoForms menu item. In both cases you should check that it is working correctly as SEF URLs can cause problems.

If you are using the ChronoForms Module or Plug-in then this will have no effect.

There are some Joomla! extensions that will allow you more control over the way caching works and, for example, let you exclude certain module locations from the cached page. See this JED page for more information.

If you avoid using the Anti-Spam techniques described above; and your form is fairly simple then you should be able to get it working with caching turned on even using the ChronoForms plug-in. If you have a more complicated form then consider having a simple 'starter' form embedded in an article that opens up the full form in a separate page, or in a modal window so that you can use the cache clearing approach to avoid problems.

The most obvious one is that you may get spam submissions on your forms; you can usually filter most of these out with ServerSide Validation to stop you getting too many junk emails.

There is a risk that your form could be hi-jacked and open to a XSS (Cross-Site Scripting) attack where some remote site submits potentially malicious data to your form. The Anti-spam and Security Token feature block this by checking that the form is submitted by the same user as loaded it. This is the check that caching 'turns-off'.