- Welcome to jDownloads Support Forum.
jDownloads Support Forum
Here can you get help for jDownloads!
Recent posts
#1
Bugs! / SOLVED - JDownloads 4.x – Cate...
Last post by INsane_dod - Yesterday at 01:54:39This is a Solved issue.
I'm posting this to help anyone who runs into similar issues.
On dodbits.com (My main domain in the hosted files), JDownloads 4.x suddenly broke after a hosting change + Joomla update, while my other site sturmbot.org (same setup) worked fine.
Symptoms...
Categories auto‑unpublished
"Folder not found" warnings
Empty ZIP downloads
Scan tool creating duplicate categories/files
Some categories saved, others failed
Files visible in FTP but not detected by JDownloads
Root Cause
This was not a JDownloads bug.
My host compared dodbits.com with sturmbot.org and found two environment differences:
open_basedir did not include the JDownloads folders
Some folders under /public_html had incorrect ownership after migration
PHP‑FPM could not access the JDownloads directory, so JDownloads behaved as if folders were missing.
Fix
Host updated:
open_basedir to include /public_html/dods/jdownloads/
Ownership to match the correct PHP user
After that, JDownloads immediately worked normally. However, more had to be done in the JDownloads back end.
Cleanup
Renamed a few category folders (In public_html/<joomla install folder name>/jdownloads) to match category names exactly in the "JDownloads: Edit Category" screen, Some had a "_" where there should have been a space.
Published categories again
Saved each category
Warning - Ran Scan tool → deleted duplicate files → deleted duplicate categories (But... be careful as it can make duplicate categories and even downloads if that is done when the ownership of the folders isn't correct)
Everything is now stable.
Conclusion
This was caused when I migrated to a new host AND upgraded from Joomla 5X to version 6.1.3. The secondary domain was not affected by these issues, however the main domain had many issues when updating to Joomala ver 6, then the issues with JDownloads happened after that.
If JDownloads shows folder errors, empty ZIPs, or duplicate categories and permissions look correct, get your hosting team to check:
open_basedir
folder ownership
PHP‑FPM pool configuration
This solved the issue completely.
I hope this helps others.
I'm posting this to help anyone who runs into similar issues.
On dodbits.com (My main domain in the hosted files), JDownloads 4.x suddenly broke after a hosting change + Joomla update, while my other site sturmbot.org (same setup) worked fine.
Symptoms...
Categories auto‑unpublished
"Folder not found" warnings
Empty ZIP downloads
Scan tool creating duplicate categories/files
Some categories saved, others failed
Files visible in FTP but not detected by JDownloads
Root Cause
This was not a JDownloads bug.
My host compared dodbits.com with sturmbot.org and found two environment differences:
open_basedir did not include the JDownloads folders
Some folders under /public_html had incorrect ownership after migration
PHP‑FPM could not access the JDownloads directory, so JDownloads behaved as if folders were missing.
Fix
Host updated:
open_basedir to include /public_html/dods/jdownloads/
Ownership to match the correct PHP user
After that, JDownloads immediately worked normally. However, more had to be done in the JDownloads back end.
Cleanup
Renamed a few category folders (In public_html/<joomla install folder name>/jdownloads) to match category names exactly in the "JDownloads: Edit Category" screen, Some had a "_" where there should have been a space.
Published categories again
Saved each category
Warning - Ran Scan tool → deleted duplicate files → deleted duplicate categories (But... be careful as it can make duplicate categories and even downloads if that is done when the ownership of the folders isn't correct)
Everything is now stable.
Conclusion
This was caused when I migrated to a new host AND upgraded from Joomla 5X to version 6.1.3. The secondary domain was not affected by these issues, however the main domain had many issues when updating to Joomala ver 6, then the issues with JDownloads happened after that.
If JDownloads shows folder errors, empty ZIPs, or duplicate categories and permissions look correct, get your hosting team to check:
open_basedir
folder ownership
PHP‑FPM pool configuration
This solved the issue completely.
I hope this helps others.
#2
Bugs! / Leftovers from the obsolete jD...
Last post by Pete - 31.08.2026 16:03:30Hello Arno,
while auditing a long-running Joomla site (migrated from Joomla 2.5 through to 5.4, jDownloads installed and updated throughout), I came across leftovers related to the obsolete jDownloads search plugin for the old Joomla search component (com_search, removed from core in Joomla 4):
The plugin folder plugins/search/jdownloads/ no longer exists (correct, since the plugin is obsolete).
However, its language files were still present in administrator/language/de-DE/: de-DE.plg_search_jdownloads.ini and de-DE.plg_search_jdownloads.sys.ini. They were never removed by any jDownloads update, and with the plugin gone they are orphaned files.
Request 1: Could a future jDownloads update script remove these orphaned plg_search_jdownloads language files (all language variants), so that long-migrated sites get cleaned up automatically?
Two smaller, related observations from the same audit:
The current jDownloads still installs its language files into the global language folders using the legacy language-prefix naming scheme (e.g. administrator/language/de-DE/de-DE.com_jdownloads.ini). This format has been deprecated since Joomla 4 and support for it is announced to be removed in Joomla 6 — only the prefix-less format (com_jdownloads.ini) or per-extension language/ folders will be loaded then. It would be great to see jDownloads switch to the new naming before Joomla 6 lands.
The update process appears to leave *.ini.old backup copies behind (e.g. de-DE.com_jdownloads.ini.old in both language/de-DE/ and administrator/language/de-DE/). These are never loaded by Joomla and could be removed by the update script as well.
Environment: Joomla 5.4, PHP 8.x, current jDownloads 4.x.
Thanks a lot for maintaining jDownloads all these years!
while auditing a long-running Joomla site (migrated from Joomla 2.5 through to 5.4, jDownloads installed and updated throughout), I came across leftovers related to the obsolete jDownloads search plugin for the old Joomla search component (com_search, removed from core in Joomla 4):
The plugin folder plugins/search/jdownloads/ no longer exists (correct, since the plugin is obsolete).
However, its language files were still present in administrator/language/de-DE/: de-DE.plg_search_jdownloads.ini and de-DE.plg_search_jdownloads.sys.ini. They were never removed by any jDownloads update, and with the plugin gone they are orphaned files.
Request 1: Could a future jDownloads update script remove these orphaned plg_search_jdownloads language files (all language variants), so that long-migrated sites get cleaned up automatically?
Two smaller, related observations from the same audit:
The current jDownloads still installs its language files into the global language folders using the legacy language-prefix naming scheme (e.g. administrator/language/de-DE/de-DE.com_jdownloads.ini). This format has been deprecated since Joomla 4 and support for it is announced to be removed in Joomla 6 — only the prefix-less format (com_jdownloads.ini) or per-extension language/ folders will be loaded then. It would be great to see jDownloads switch to the new naming before Joomla 6 lands.
The update process appears to leave *.ini.old backup copies behind (e.g. de-DE.com_jdownloads.ini.old in both language/de-DE/ and administrator/language/de-DE/). These are never loaded by Joomla and could be removed by the update script as well.
Environment: Joomla 5.4, PHP 8.x, current jDownloads 4.x.
Thanks a lot for maintaining jDownloads all these years!
#3
Bugs! / PHP Warning in error log - und...
Last post by TonyMJ - 31.08.2026 12:16:24PHP 8.3, latest version of Jdownloads
Undefined array key 1 in /home/xxxxxx/public_html/components/com_jdownloads/src/Helper/JDHelper.php on line 2990
Undefined array key 1 in /home/xxxxxx/public_html/components/com_jdownloads/src/Helper/JDHelper.php on line 2990
#4
Suggestions - Feature Request / Re: Batch operation for licens...
Last post by ColinM - 29.08.2026 16:37:19Hi
I do not think this is feasible. Please see articles
Batch Processing
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=268
and
Including a license in a Download
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=277
It would involve multiple detailed changes. Perhaps it may be reasonable at a later date in jDownloads 6 when released
Best wishes
Colin
I do not think this is feasible. Please see articles
Batch Processing
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=268
and
Including a license in a Download
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=277
It would involve multiple detailed changes. Perhaps it may be reasonable at a later date in jDownloads 6 when released
Best wishes
Colin
#5
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.
#6
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.
#7
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
#8
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
#9
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
#10
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