- Welcome to jDownloads Support Forum.
jDownloads Support Forum
Here can you get help for jDownloads!
Recent posts
#31
Suggestions - Feature Request / Batch operation for license re...
Last post by baba - 29.08.2026 08:41:33Hi there
Great Component Thanks!
My suggestion is to have a possibility to change the license type & confirm license in a batch operation.
Great Component Thanks!
My suggestion is to have a possibility to change the license type & confirm license in a batch operation.
#32
Suggestions - Feature Request / Feature request: Batch operati...
Last post by baba - 29.08.2026 08:35:12Hi there
Great Component Thanks!
My suggestion is to have a possibility to change the license type & confirm license in a batch operation.
Great Component Thanks!
My suggestion is to have a possibility to change the license type & confirm license in a batch operation.
#33
Bugs! / Wrong Itemid in multilingual d...
Last post by Andrés Restrepo - 28.08.2026 01:11:13Hi Arno,
I would like to report a multilingual routing issue in jDownloads 4.1.7.
The problem affects both the association link rendered by jDownloads and Joomla's Language Switcher module (mod_languages).
Environment:
- Joomla 6.1.3
- jDownloads 4.1.7 Stable
- Helix Ultimate 2.2.10
- Multilingual site: Spanish (es-ES, default) and English (en-GB)
- Joomla multilingual associations enabled
PROBLEM
The downloads, their categories, and the corresponding Joomla menu items are associated between Spanish and English.
For example:
Spanish download:
ID: 740
Category: 100
Language: es-ES
Correct URL:
https://alamarte.com/descargas/extensiones/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
Associated English download:
ID: 1295
Category: 142
Language: en-GB
Correct URL:
https://alamarte.com/en/downloads/extensions/plugins/helix-language-fix/download/142-plugins/1295-alamarte-helix-language-fix
However, when viewing the English download, the association generated by jDownloads was:
/downloads/extensions/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
This URL contains the Spanish download and category, but retains the English menu route:
/downloads/
The correct Spanish URL is:
/descargas/extensiones/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
The opposite happened when viewing the Spanish download.
jDownloads generated:
/en/descargas/extensiones/plugins/helix-language-fix/download/142-plugins/1295-alamarte-helix-language-fix
instead of:
/en/downloads/extensions/plugins/helix-language-fix/download/142-plugins/1295-alamarte-helix-language-fix
In other words, the generated association contained:
- the destination download ID;
- the destination category ID;
- the destination language;
- but the Itemid / menu route from the source language.
These mixed-language URLs returned HTTP 404.
TWO DIFFERENT FRONTEND OVERRIDES WERE USED TO DIAGNOSE AND WORK AROUND THE ISSUE
No jDownloads core file was modified.
Both overrides are located under the Helix Ultimate template, but they have different purposes.
1. jDOWNLOADS DOWNLOAD LAYOUT OVERRIDE
Location:
/templates/shaper_helixultimate/html/com_jdownloads/download/default.php
This override already existed on the site because the jDownloads Download Details layout is customized.
During the multilingual investigation, I added a correction to the association URL rendered by this layout.
The correction obtains the Joomla menu item associated with the destination language and replaces the incorrect source-language Itemid before routing the association URL.
This fixed the visible jDownloads:
"Also available in"
association link.
For example, from the English download, the Spanish association changed from:
/downloads/extensions/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
to the correct:
/descargas/extensiones/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
At this point the association link displayed by jDownloads was correct.
However, a crawler still found the same mixed-language 404 URLs.
I then inspected the complete generated HTML and found another source of the same incorrect URLs.
2. HELIX ULTIMATE OVERRIDE FOR JOOMLA MOD_LANGUAGES
Location:
/templates/shaper_helixultimate/html/mod_languages/default.php
This second override is specifically for Helix Ultimate.
Helix Ultimate 2.2.10 already includes this override file as a small bridge to its own language-module renderer.
The original Helix file contains essentially:
defined('JPATH_BASE') or die();
require HelixUltimate\Framework\Platform\HTMLOverride::loadTemplate();
Therefore I did not replace it with Joomla's standard mod_languages layout.
Instead, I kept Helix Ultimate's normal override mechanism intact and added the jDownloads-specific correction before:
require HelixUltimate\Framework\Platform\HTMLOverride::loadTemplate();
The correction runs only when:
option=com_jdownloads
view=download
It obtains the association route supplied by com_jdownloads, replaces its incorrect Itemid with the Joomla menu Itemid associated with the destination language, assigns the corrected route to $language->link, and then lets Helix Ultimate render mod_languages normally.
This is therefore a Helix Ultimate-specific workaround for mod_languages, not a replacement of Helix's language-selector layout.
WHY THE SECOND OVERRIDE WAS NECESSARY
After fixing the association displayed inside the jDownloads layout, Joomla's Language Switcher module still contained the incorrect URLs.
This was confirmed directly in the generated HTML.
On the English download page, mod_languages still contained:
/downloads/extensions/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
On the Spanish page, it contained:
/en/descargas/extensiones/plugins/helix-language-fix/download/142-plugins/1295-alamarte-helix-language-fix
Therefore the problem was not caused by the jDownloads layout itself.
com_jdownloads was providing the incorrect association route to Joomla's multilingual association system, and mod_languages was rendering the URL it received.
SOURCE CODE
I traced the download association generation to:
components/com_jdownloads/src/Helper/AssociationHelper.php
For a download association it calls:
RouteHelper::getDownloadRoute(
$item->id,
(int) $item->catid,
$item->language,
$layout
);
Then, in:
components/com_jdownloads/src/Helper/RouteHelper.php
getDownloadRoute() correctly adds the destination language:
if (!empty($language) && $language !== '*' && Multilanguage::isEnabled()) {
$link .= '&lang=' . $language;
}
However, the destination language is not used when the Itemid is selected.
_findItem() contains:
$language = isset($needles['language']) ? $needles['language'] : '*';
but getDownloadRoute() does not provide the destination language to the menu-item lookup.
As a consequence, _findItem() can accept the currently active jDownloads menu item from the source language.
The resulting route can therefore contain:
- destination download;
- destination category;
- destination language;
- source-language Itemid.
TEST RESULTS
Before applying the workarounds, a clean crawl consistently detected 12 mixed-language HTTP 404 URLs.
They corresponded to six Spanish/English download pairs.
After correcting:
1. the association rendered by the jDownloads download layout; and
2. the association used by mod_languages through the Helix Ultimate-specific override,
10 of the 12 incorrect URLs disappeared.
The remaining two belonged to the Spanish/English Alamarte Breadcrumbs pair.
I then discovered that those two Joomla menu items had accidentally been left without a multilingual menu association.
All the other tested menu pairs were correctly associated.
After restoring the missing Breadcrumbs menu association and running another clean crawl, the final two incorrect URLs also disappeared.
Final result:
12 of 12 mixed-language 404 URLs disappeared.
The final crawl detected no broken links related to this multilingual routing problem.
This also confirmed that, when the Joomla menu associations are correctly configured, replacing the source-language Itemid with the Itemid associated with the destination language resolves the routing problem.
RELATED OLD REPORT
I also found this older forum topic:
"Error in Itemid reference between two languages"
https://www.jdownloads.com/forum/index.php?topic=13763.0
It appears to describe a similar multilingual Itemid problem, although it concerns older Joomla and jDownloads versions.
QUESTIONS
Could you please check whether RouteHelper::getDownloadRoute() should explicitly select the Joomla menu Itemid belonging to the destination language when generating a multilingual download association?
It also seems worth reviewing whether the destination language should be taken into account by _findItem() when selecting the menu item for these association routes.
I would also be interested to know whether this routing logic has already been changed in the jDownloads 6 development branch.
If useful, I can provide:
- the original and corrected association URLs;
- the generated HTML showing the incorrect URLs received by mod_languages;
- the jDownloads download-layout workaround;
- the Helix Ultimate-specific mod_languages workaround;
- and the crawler results before and after the corrections.
Regards,
Andrés
Alamarte Ingeniería
I would like to report a multilingual routing issue in jDownloads 4.1.7.
The problem affects both the association link rendered by jDownloads and Joomla's Language Switcher module (mod_languages).
Environment:
- Joomla 6.1.3
- jDownloads 4.1.7 Stable
- Helix Ultimate 2.2.10
- Multilingual site: Spanish (es-ES, default) and English (en-GB)
- Joomla multilingual associations enabled
PROBLEM
The downloads, their categories, and the corresponding Joomla menu items are associated between Spanish and English.
For example:
Spanish download:
ID: 740
Category: 100
Language: es-ES
Correct URL:
https://alamarte.com/descargas/extensiones/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
Associated English download:
ID: 1295
Category: 142
Language: en-GB
Correct URL:
https://alamarte.com/en/downloads/extensions/plugins/helix-language-fix/download/142-plugins/1295-alamarte-helix-language-fix
However, when viewing the English download, the association generated by jDownloads was:
/downloads/extensions/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
This URL contains the Spanish download and category, but retains the English menu route:
/downloads/
The correct Spanish URL is:
/descargas/extensiones/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
The opposite happened when viewing the Spanish download.
jDownloads generated:
/en/descargas/extensiones/plugins/helix-language-fix/download/142-plugins/1295-alamarte-helix-language-fix
instead of:
/en/downloads/extensions/plugins/helix-language-fix/download/142-plugins/1295-alamarte-helix-language-fix
In other words, the generated association contained:
- the destination download ID;
- the destination category ID;
- the destination language;
- but the Itemid / menu route from the source language.
These mixed-language URLs returned HTTP 404.
TWO DIFFERENT FRONTEND OVERRIDES WERE USED TO DIAGNOSE AND WORK AROUND THE ISSUE
No jDownloads core file was modified.
Both overrides are located under the Helix Ultimate template, but they have different purposes.
1. jDOWNLOADS DOWNLOAD LAYOUT OVERRIDE
Location:
/templates/shaper_helixultimate/html/com_jdownloads/download/default.php
This override already existed on the site because the jDownloads Download Details layout is customized.
During the multilingual investigation, I added a correction to the association URL rendered by this layout.
The correction obtains the Joomla menu item associated with the destination language and replaces the incorrect source-language Itemid before routing the association URL.
This fixed the visible jDownloads:
"Also available in"
association link.
For example, from the English download, the Spanish association changed from:
/downloads/extensions/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
to the correct:
/descargas/extensiones/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
At this point the association link displayed by jDownloads was correct.
However, a crawler still found the same mixed-language 404 URLs.
I then inspected the complete generated HTML and found another source of the same incorrect URLs.
2. HELIX ULTIMATE OVERRIDE FOR JOOMLA MOD_LANGUAGES
Location:
/templates/shaper_helixultimate/html/mod_languages/default.php
This second override is specifically for Helix Ultimate.
Helix Ultimate 2.2.10 already includes this override file as a small bridge to its own language-module renderer.
The original Helix file contains essentially:
defined('JPATH_BASE') or die();
require HelixUltimate\Framework\Platform\HTMLOverride::loadTemplate();
Therefore I did not replace it with Joomla's standard mod_languages layout.
Instead, I kept Helix Ultimate's normal override mechanism intact and added the jDownloads-specific correction before:
require HelixUltimate\Framework\Platform\HTMLOverride::loadTemplate();
The correction runs only when:
option=com_jdownloads
view=download
It obtains the association route supplied by com_jdownloads, replaces its incorrect Itemid with the Joomla menu Itemid associated with the destination language, assigns the corrected route to $language->link, and then lets Helix Ultimate render mod_languages normally.
This is therefore a Helix Ultimate-specific workaround for mod_languages, not a replacement of Helix's language-selector layout.
WHY THE SECOND OVERRIDE WAS NECESSARY
After fixing the association displayed inside the jDownloads layout, Joomla's Language Switcher module still contained the incorrect URLs.
This was confirmed directly in the generated HTML.
On the English download page, mod_languages still contained:
/downloads/extensions/plugins/helix-language-fix/download/100-plugins/740-alamarte-helix-language-fix
On the Spanish page, it contained:
/en/descargas/extensiones/plugins/helix-language-fix/download/142-plugins/1295-alamarte-helix-language-fix
Therefore the problem was not caused by the jDownloads layout itself.
com_jdownloads was providing the incorrect association route to Joomla's multilingual association system, and mod_languages was rendering the URL it received.
SOURCE CODE
I traced the download association generation to:
components/com_jdownloads/src/Helper/AssociationHelper.php
For a download association it calls:
RouteHelper::getDownloadRoute(
$item->id,
(int) $item->catid,
$item->language,
$layout
);
Then, in:
components/com_jdownloads/src/Helper/RouteHelper.php
getDownloadRoute() correctly adds the destination language:
if (!empty($language) && $language !== '*' && Multilanguage::isEnabled()) {
$link .= '&lang=' . $language;
}
However, the destination language is not used when the Itemid is selected.
_findItem() contains:
$language = isset($needles['language']) ? $needles['language'] : '*';
but getDownloadRoute() does not provide the destination language to the menu-item lookup.
As a consequence, _findItem() can accept the currently active jDownloads menu item from the source language.
The resulting route can therefore contain:
- destination download;
- destination category;
- destination language;
- source-language Itemid.
TEST RESULTS
Before applying the workarounds, a clean crawl consistently detected 12 mixed-language HTTP 404 URLs.
They corresponded to six Spanish/English download pairs.
After correcting:
1. the association rendered by the jDownloads download layout; and
2. the association used by mod_languages through the Helix Ultimate-specific override,
10 of the 12 incorrect URLs disappeared.
The remaining two belonged to the Spanish/English Alamarte Breadcrumbs pair.
I then discovered that those two Joomla menu items had accidentally been left without a multilingual menu association.
All the other tested menu pairs were correctly associated.
After restoring the missing Breadcrumbs menu association and running another clean crawl, the final two incorrect URLs also disappeared.
Final result:
12 of 12 mixed-language 404 URLs disappeared.
The final crawl detected no broken links related to this multilingual routing problem.
This also confirmed that, when the Joomla menu associations are correctly configured, replacing the source-language Itemid with the Itemid associated with the destination language resolves the routing problem.
RELATED OLD REPORT
I also found this older forum topic:
"Error in Itemid reference between two languages"
https://www.jdownloads.com/forum/index.php?topic=13763.0
It appears to describe a similar multilingual Itemid problem, although it concerns older Joomla and jDownloads versions.
QUESTIONS
Could you please check whether RouteHelper::getDownloadRoute() should explicitly select the Joomla menu Itemid belonging to the destination language when generating a multilingual download association?
It also seems worth reviewing whether the destination language should be taken into account by _findItem() when selecting the menu item for these association routes.
I would also be interested to know whether this routing logic has already been changed in the jDownloads 6 development branch.
If useful, I can provide:
- the original and corrected association URLs;
- the generated HTML showing the incorrect URLs received by mod_languages;
- the jDownloads download-layout workaround;
- the Helix Ultimate-specific mod_languages workaround;
- and the crawler results before and after the corrections.
Regards,
Andrés
Alamarte Ingeniería
#34
Bugs! / Category associations not show...
Last post by Andrés Restrepo - 27.08.2026 23:27:52Hi Arno,
I found a reproducible issue in jDownloads 4.1.7 Stable when using multilingual categories.
Environment:
- Joomla 6.1.3
- jDownloads 4.1.7 Stable
- Administrator template: Atum
- Joomla multilingual associations enabled
Problem:
Category associations are correctly stored and work normally.
If I edit a category and open the Associations tab, the associated category in the other language is shown correctly.
However, in:
jDownloads → Categories
the "Associations" column remains empty.
For example:
Spanish category:
Extensiones Gratis → associated with English category "Free Extensions"
English category:
Free Extensions → associated with Spanish category "Extensiones Gratis"
The associations exist in the database and are correctly shown inside the category edit form, but they are not displayed in the Categories list.
I checked the source code in:
administrator/components/com_jdownloads/src/Model/CategoriesModel.php
The getAssoc() method contains:
$assoc = Associations::isEnabled();
if ($assoc)
{
\JLoader::register(
'JdownloadsAssociationsHelper',
JPATH_ADMINISTRATOR . '/components/com_jdownloads/src/Helper/associations.php'
);
$assoc = class_exists('JdownloadsAssociationsHelper');
}
But the actual helper class is namespaced:
JDownloads\Component\JDownloads\Administrator\Helper\JDownloadsAssociationsHelper
Therefore:
class_exists('JdownloadsAssociationsHelper')
can return false.
When that happens, getListQuery() does not add the association JOIN/count:
if ($assoc)
{
$query->select('COUNT(asso2.id)>1 as association')
->join('LEFT', '#__associations AS asso ON asso.id = a.id AND asso.context=' . $db->quote('com_jdownloads.category.item'))
->join('LEFT', '#__associations AS asso2 ON asso2.key = asso.key');
}
and the Categories layout never receives $item->association.
I confirmed this is only a display/listing problem. The category associations themselves are not lost or damaged.
As a test, I created an administrator template override for:
administrator/components/com_jdownloads/tmpl/categories/default.php
and queried the existing associations directly. The Associations column then displays correctly for all Spanish ↔ English category pairs.
So the problem appears to be in CategoriesModel::getAssoc(), not in the stored associations.
Regards,
Andrés
Alamarte Ingeniería
I found a reproducible issue in jDownloads 4.1.7 Stable when using multilingual categories.
Environment:
- Joomla 6.1.3
- jDownloads 4.1.7 Stable
- Administrator template: Atum
- Joomla multilingual associations enabled
Problem:
Category associations are correctly stored and work normally.
If I edit a category and open the Associations tab, the associated category in the other language is shown correctly.
However, in:
jDownloads → Categories
the "Associations" column remains empty.
For example:
Spanish category:
Extensiones Gratis → associated with English category "Free Extensions"
English category:
Free Extensions → associated with Spanish category "Extensiones Gratis"
The associations exist in the database and are correctly shown inside the category edit form, but they are not displayed in the Categories list.
I checked the source code in:
administrator/components/com_jdownloads/src/Model/CategoriesModel.php
The getAssoc() method contains:
$assoc = Associations::isEnabled();
if ($assoc)
{
\JLoader::register(
'JdownloadsAssociationsHelper',
JPATH_ADMINISTRATOR . '/components/com_jdownloads/src/Helper/associations.php'
);
$assoc = class_exists('JdownloadsAssociationsHelper');
}
But the actual helper class is namespaced:
JDownloads\Component\JDownloads\Administrator\Helper\JDownloadsAssociationsHelper
Therefore:
class_exists('JdownloadsAssociationsHelper')
can return false.
When that happens, getListQuery() does not add the association JOIN/count:
if ($assoc)
{
$query->select('COUNT(asso2.id)>1 as association')
->join('LEFT', '#__associations AS asso ON asso.id = a.id AND asso.context=' . $db->quote('com_jdownloads.category.item'))
->join('LEFT', '#__associations AS asso2 ON asso2.key = asso.key');
}
and the Categories layout never receives $item->association.
I confirmed this is only a display/listing problem. The category associations themselves are not lost or damaged.
As a test, I created an administrator template override for:
administrator/components/com_jdownloads/tmpl/categories/default.php
and queried the existing associations directly. The Associations column then displays correctly for all Spanish ↔ English category pairs.
So the problem appears to be in CategoriesModel::getAssoc(), not in the stored associations.
Regards,
Andrés
Alamarte Ingeniería
#35
General / Re: Malicious files being uplo...
Last post by ColinM - 27.08.2026 13:23:01Hi
Have you installed the Akeeba package 'Admin Tools' ? That package seems to cause a challenge/conflict with jDownloads!!
Colin
Have you installed the Akeeba package 'Admin Tools' ? That package seems to cause a challenge/conflict with jDownloads!!
Colin
#36
General / Malicious files being uploaded...
Last post by StevensonWay - 25.08.2026 23:55:39My web host (IONOS.co.uk) has alerted me to malicious files that have been found in the com_jdownloads/test_uploads folder. The web site is based on Joomla, is running the latest version and all passwords are complex. Currently IONOS have blocked ("parked") the web site (www.stevensonway.org.uk) and although I restored the last backup from a few days ago, the web site was blocked again after about 10 minutes.
I then tried to restore again but then ran into issues with Kickstart not being able to write to some files. I'm now stuck and I'm trying to find a way to find and delete these malicious files. So does anyone have any idea of how these files came to be in the /test_uploads folder? IONOS have very strict file checking and so I'm puzzled as to how this has come about.
I'd appreciate any ideas/help as being offline is not good!
Kind regards
Ian
I then tried to restore again but then ran into issues with Kickstart not being able to write to some files. I'm now stuck and I'm trying to find a way to find and delete these malicious files. So does anyone have any idea of how these files came to be in the /test_uploads folder? IONOS have very strict file checking and so I'm puzzled as to how this has come about.
I'd appreciate any ideas/help as being offline is not good!
Kind regards
Ian
#37
General / Re: Work good the last version...
Last post by Arno - 22.08.2026 13:57:33Hi Pedro,
Sorry, but that's not correct.
The current version 4.1.x is compatible with Joomla 5 and 6. This is also stated in the download description.
I haven't yet tested the latest update for Joomla 5 from 18 August. I'll do that later today, though.
I'll also look into the issue with the previous customisation. I'll get back to you.
QuoteMy question is, does JDownloads work correctly in Joomla 5.4.8? According to @Arno, the version for Joomla 6 is still in beta.
Sorry, but that's not correct.
The current version 4.1.x is compatible with Joomla 5 and 6. This is also stated in the download description.
I haven't yet tested the latest update for Joomla 5 from 18 August. I'll do that later today, though.
I'll also look into the issue with the previous customisation. I'll get back to you.
#38
Bugs! / Re: {cat_link} not substituted...
Last post by ColinM - 22.08.2026 13:31:48Hi
Could you also please test using 'Standard Subcategories Layout v3.9'
ColinM
Could you also please test using 'Standard Subcategories Layout v3.9'
ColinM
#39
General / Re: Work good the last version...
Last post by ArticosDesign - 20.08.2026 22:37:42Quote from: ColinM on 20.08.2026 21:25:52Hi
Probably better to update to Joomla 6.1.3, which is the current Joomla version.
If you are unsure of how to do this see article
Upgrading Joomla to Next Version -July 2026
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=322
ColinM
ColinM, thanks for the information, but updating Joomla to version 6 isn't the current problem.
My question is, does JDownloads work correctly in Joomla 5.4.8? According to @Arno, the version for Joomla 6 is still in beta.
Furthermore, I had already requested some additional features that were implemented in a previous version of JDownloads, and which worked perfectly. These features have been lost in the new updates, despite our agreement with @Arno to maintain them for future versions of JDownloads. They are currently unavailable. For example:
When you open a download link, wherever it is (for example, in the Latest Uploads sidebar or in a download list ...), it's very important that it always opens in a new browser window or tab (whether on a PC or mobile device). Many users, if they open these links or documents in the same window, don't realize they need to click the back arrow to continue where they were (I know it's difficult to understand, but that's how it works). Ideally, they should always open in a new window.
This way, if the user closes the window of the file they are viewing, they will always return to the original window without having to log in again to search for the file or document.
Best regards and thank you for your work.
Pedro
#40
General / Re:cron and special char
Last post by ColinM - 20.08.2026 21:25:52Hi
Probably better to update to Joomla 6.1.3, which is the current Joomla version.
If you are unsure of how to do this see article
Upgrading Joomla to Next Version -July 2026
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=322
ColinM
Probably better to update to Joomla 6.1.3, which is the current Joomla version.
If you are unsure of how to do this see article
Upgrading Joomla to Next Version -July 2026
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=322
ColinM