System Plugin supports Cache Control for Forms
Avoiding problems when Joomla! caching is enabled.
There have been multiple reports of forms used in many plugins, modules and components not working if a site is using the Joomla! cache. That is this is not something specific to jDownloads. The Caching Rules option in the jDownloads System Plugin has been included to resolve any such problem with forms used within the jDownloads suite. This option provides the ability to turn caching off selectively, thus ensuring jDownloads may be made immune to this problem. Just for background the Joomla! caching system operates by saving the html pages generated that provide the view on the user screen. If the same html page is about to be re-generated Joomla! transmits the one from its cache instead thus making the system far more responsive. But it sometimes will cause a 'challenge' if it is a form with prestored, and usually 'hidden', data.
A typical situation in many forms is the use of a hidden field that is poulated by the originating software with a random identifier as a security check. A copy of the identifier is saved, probably somewhere in the user session information, so when the completed form is submitted by the user the identifier is used to confirm it is the same form that was sent. If the form has been cached then it will be returned with a previous identifier and so will never match. Such a situation is not uncommon with Captcha, with login forms and similar. So a failure occurs because the page was cached .The scheme implemented in the jDowloads System Plugin is inspired by the CacheControl plugin from Crosstec GmbH.
One of the lessons then is to test your site with Caching turned off. If all is well but things go awry in jDownloads when you put caching on then you need to use the Caching Rules option in the jDownloads System Plugin, which could be described as a selective "cache prevention" scheme.
Suppose for instance you have an article that includes one of the jDownloads modules in an article by using say the loadposition plugin, such as for example, or perhaps the article refers to one of the jDownloads plugins, such as the Search one. If you are using the Joomla cache then it may go wrong. To emphasise the point the sequence carried out by Joomla! is indicated below. Maybe one day perhaps Joomla will incorporate an article parameter to say 'do not cache me'.
- the article is loaded;
- Joomla! replaces the placeholder with the relevant html code generated by the plugin and the module it may have used;
- the Joomla! Cache records what the page looks like and saves it in the cache;
- This means that the page will never reload the plugin, and the selected module will never run as it should. Essentially the previous results will be displayed because the appearance but not the functionality is stored in the cache.
How do we solve that problem? One solution is of course to disable Joomla! caching but for performance reasons that is not generally a good idea. The better alternative is to use the jDownloads Caching Rule option.
Because of the way the cache prevention works you need to find the 'hard' url reference to the relevant page. By 'hard' this means the non-seo style url. Finding this is quite straightforward.
First make a single article menu item that links to the page that should not be cached. To repeat, you will need the non-SEF link which is always something like index.php?option=com_content&view=article&id=nnn where nnn is some numeric value such as 123.
Next copy the part starting at option= , that is for example option=com_content&view=article&id=123
This option=... part is the url you need to put in the Caching Rules. Of course the menu item can be discarded if it is not needed for other purposes. You can also find the id directly in the Article Manager and construct the link manually but I find it 'safer' to actually create the menu link just in case the Joomla! mechanism has changed!.
The initial Caching Rules setup is
|This now becomes|
Normally it would of course be unwise to remove the "option=com_jdownloads" rule unless you are certain of the effects. However that having been said it seems that the most frequent caching 'challenge' in the jDownloads context are pages showing the Summary and pages showing the Search form. The summary page cahing appears to be those situations where a Captcha or a password are requested.
If it is only these pages then current testing indicates that the Caching Rules could be just set to the following
Note that the situation may change as new features are added and existing ones improved.
Colin Mercer December 2014