Strange "Faults" - Did you know that...

This article is a collection of odds and ends that may help solve strange or apparently non reproducible problems.  Some are seemingly simple - when you know the answer!

Several of these 'incidents' were not jDownloads related 'challenges' but due to things outside jDownloads but they may appear to be a jD problem!

As other such problems are found then they will be added to this article.

The site seemed OK but the Download button was not working.

Problem turned out that the example plugin had been activated in error.  Disabling it solved the problem.

A site seemed to be very slow when several Categories were added to a regular article using the jD Content Plugin.  User had a very high internet bandwith so it should not be slow.  Also had a delay when switching between jDownloads regular views such as, for example, between a Downloads listing and a Downloads Detail view.
 
Most of the Downloads were unchanged.  So it seemed a possible solution was that increasing the cache size might help.  But this did not solve the problem.  And in any case increased cache size does not help first time or occaisional users.

The site had high security and was using IP blocking with Akeeba Tools.  Now that meant extensive IP checks were being done on every page load.  As it was the Downloads that really needed the protection then the IP blocking was switched to the jDownloads option 'Activate IP Blocking' in the Options tab Security.  This IP blocking only operates when attempting to download a file.

This also speeds up the general switching between jDownloads views say from a Downloads Listing to a Downloads Detail or Summary view.

So speed problem solved and security maintained.

The Categories and Downloads were not visible in the frontend.

This looked like it was a view Access level or possibly a Permissions problem. But no, all was well on those fronts.

But even the super user could not see, even when added to every view Access level. The problem was traced to the ECR plugin (this is not Easy Content Reader but Easy Content Restriction).

The plugin, which is embedded in the articles, is very flexible. It works by requiring a password associated with the article or by blocking specific usergroups to see the content.  But this is not compatible with the jDownloads.

Disabling the Plugin resolved the problem.

UPDATE It is understood that an updated plugin is available from the ECR developer.

An error 500 appeared after updating to jD 3.9. If this occurs it may be related to updating MySQL to version 5.7 from an earlier version. It seems this 'changed' the absolute path settings in jDownloads- Options - Path Settings tab - 'Upload Directory path' and also in Joomla! System - Configuration - Server - 'Path to Temp Folder' and System - Configuration - System - 'Path to Log Folder'. There are many ways to find the absolute path including contacting your web hosting service. This solution was first posted by user LoMa in this Forum Posting.

The font colour used by jDownloads in the Frontend views is taken from the active Joomla! template!

One of the facilities in DP Calendar is the ability to add descriptions.  This may include adding the jD Content plugin to allow a user to download more details, which is obviously desirable in many situations.

However sometimes this goes wrong! 

Investigation determined that problems only occured when the content plugin was added for a Download in the first line of the Description.

So a line like below where the content plugin, which has been slightly highlighted for clarity, is in the first line of the DP Calandar description:
"Here you may download additional information "
will cause 'challenges' with symptons such as other modules 'vanishing' and no further calandar events being shown.

However if the DP Calendar description is like:
"You will find some additional information
by clicking on the download  "
All then works OK 
NB the DP Calendar people are aware of this 'challenge' so it may have been fixed.

 A really stange sympton occured when it seemed that a Categories view appeared just once when first created but then did not seem to appear when the page was refreshed.  Strange!

The symptom is that a change has been made to a web page, say perhaps an article has had a content pluging item added or a module has been added using a 'modules anywhere' plugin.  The view then appears when the edit is completed.  But it fails to appear when re-entering the page.

This sort of symptom is consistent with having caching active.  It could be the Joomla cache, or perhaps the Browser cache.  But clearing those caches may not solve the problem!

Some web modems, particularly those working with a satellite, also have a significant cache.  So it may be necessary to reboot your web modem in order to clear its cache.

The challenge here was that this worked AOK in jD 3.2.  It also worked in jD 3.9 when SEF was turned off but failed when SEF was turned ON.

The solution was a careful reading of the Components Anywhere documentation as things seemed to have changed with SEF in Joomla! 3.9.

In particular check out the Component Anywhere tutorial sections 'Using Menu Item...' and 'Component Parameters'.

The link was formerly
{component index.php?option=com_jdownloads&view=category&catid=XXX}   where XXX is the relevant catid.

Now to be independant of the SEF status, the link style requires the menu item as well so that the structure is shown below, where YYY is the id of the relevant menu item.
{component index.php?option=com_jdownloads&view=category&catid=XX&Itemid=YYY}

jD Views appear twice!