- Welcome to jDownloads Support Forum.
jDownloads Support Forum
Here can you get help for jDownloads!
Recent posts
#11
General / "Select all files" no longer w...
Last post by LinaG - 04.05.2026 17:42:51Hello!
I had activated the "Compact Files layout with Checkboxes 3.9" plugin to allow downloading multiple files at the same time. In this version 4.1.3, the "Select all files" button appears but doesn't select any files. How do I get it working again?
Thanks
I had activated the "Compact Files layout with Checkboxes 3.9" plugin to allow downloading multiple files at the same time. In this version 4.1.3, the "Select all files" button appears but doesn't select any files. How do I get it working again?
Thanks
#12
Bugs! / Re: Unauthorized access to Dow...
Last post by Arno - 04.05.2026 15:05:18Hi Pierre,
the SQL issue in the User Group Settings is already fixed in the current development state.
I will send you a prerelease package (via PM) so you can test that part directly.
This fix is for the known database error in the User Group Settings.
It may or may not affect the separate download / Registered issue, so it would be helpful if you test both again afterwards.
Thanks.
the SQL issue in the User Group Settings is already fixed in the current development state.
I will send you a prerelease package (via PM) so you can test that part directly.
This fix is for the known database error in the User Group Settings.
It may or may not affect the separate download / Registered issue, so it would be helpful if you test both again afterwards.
Thanks.
#13
Bugs! / Re: Unauthorized access to Dow...
Last post by jpierre - 04.05.2026 14:23:02Hi Arno,
Thanks for your detailed feedback, and i understand your analysis.
I can btw confirm that anything is working well from your Demo site, and that it's something on my environment then.
I will check the Database Fix and let you know. (Unfortunately not before the start of Next Week as i need to leave for a business trip). This is indeed the first thing to test.
Even if this is not related, do yo know if there could be an easy fix to apply to bypass the Field 'form_fieldset' doesn't have a default value problem ? I'd like to access the User Group Settings panel and check if something may be visible there ?
In anycase, I will update here any new information / solution as soon as i can work again on that subject.
Best Regards,
Thanks for your detailed feedback, and i understand your analysis.
I can btw confirm that anything is working well from your Demo site, and that it's something on my environment then.
I will check the Database Fix and let you know. (Unfortunately not before the start of Next Week as i need to leave for a business trip). This is indeed the first thing to test.
Even if this is not related, do yo know if there could be an easy fix to apply to bypass the Field 'form_fieldset' doesn't have a default value problem ? I'd like to access the User Group Settings panel and check if something may be visible there ?
In anycase, I will update here any new information / solution as soon as i can work again on that subject.
Best Regards,
#14
Bugs! / Re: Unauthorized access to Dow...
Last post by Arno - 04.05.2026 13:42:14Hi Pierre,
thanks again for all the testing and for the screenshots.
At this point I think we can narrow it down a bit more:
The problem does not seem to be the access level itself.
It looks more like something is wrong in the original Registered user group branch on your site.
The main clue is this:
users and groups connected to the existing Registered branch cannot download,
but when those same users/groups are moved under a newly created Registered-style group, the downloads work again.
I also made a first comparison test on the 4.1.3 demo site with the same basic setup, and there the download works normally.
So at the moment I cannot reproduce this as a general jDownloads 4.1.3 bug.
You can test the same frontend case directly here:
https://jd40.jdownloads.org
Login: TestUser
Password: TestUser
Then open this test category:
https://jd40.jdownloads.org/downloads/category/86-test_debug_category.html
With that test user, the category access and the download should work.
As a next step on your own site, I would also recommend running Joomla Database Fix once and then repeating exactly the same test again with the original Registered branch.
Note:
With the login above you can check the frontend test case directly.
If you want to compare the backend setup as well, just let me know again. That is no problem.
That means the current indication is:
this is more likely a site-specific ACL / inheritance issue in the original Registered group path on your installation, not a general problem with the Registered access level itself.
That said, I do not want to leave it there.
If you want, I can still help you narrow it down further on your site.
If the same test still fails afterwards, we can check the Joomla ACL / asset data for the test category and test download more closely.
So for now, the workaround with the new Registered-style group seems valid, but I would still like to understand what is different in the old Registered branch on your installation.
Even if the Registered group seems to work normally elsewhere in Joomla, this can still be limited to how ACL inheritance affects the jDownloads category/download assets on this installation.
thanks again for all the testing and for the screenshots.
At this point I think we can narrow it down a bit more:
The problem does not seem to be the access level itself.
It looks more like something is wrong in the original Registered user group branch on your site.
The main clue is this:
users and groups connected to the existing Registered branch cannot download,
but when those same users/groups are moved under a newly created Registered-style group, the downloads work again.
I also made a first comparison test on the 4.1.3 demo site with the same basic setup, and there the download works normally.
So at the moment I cannot reproduce this as a general jDownloads 4.1.3 bug.
You can test the same frontend case directly here:
https://jd40.jdownloads.org
Login: TestUser
Password: TestUser
Then open this test category:
https://jd40.jdownloads.org/downloads/category/86-test_debug_category.html
With that test user, the category access and the download should work.
As a next step on your own site, I would also recommend running Joomla Database Fix once and then repeating exactly the same test again with the original Registered branch.
Note:
With the login above you can check the frontend test case directly.
If you want to compare the backend setup as well, just let me know again. That is no problem.
That means the current indication is:
this is more likely a site-specific ACL / inheritance issue in the original Registered group path on your installation, not a general problem with the Registered access level itself.
That said, I do not want to leave it there.
If you want, I can still help you narrow it down further on your site.
If the same test still fails afterwards, we can check the Joomla ACL / asset data for the test category and test download more closely.
So for now, the workaround with the new Registered-style group seems valid, but I would still like to understand what is different in the old Registered branch on your installation.
Even if the Registered group seems to work normally elsewhere in Joomla, this can still be limited to how ACL inheritance affects the jDownloads category/download assets on this installation.
#15
Bugs! / MOVED: Bug Report: 404 Error a...
Last post by Arno - 04.05.2026 12:14:28 #16
General / Re: Bug Report: 404 Error afte...
Last post by Arno - 04.05.2026 12:13:37Hi,
thank you very much for the clarification and for taking the time to track this down.
So the actual cause was not the front-end template or a general jDownloads redirect bug, but the Joomla mail configuration.
The upload itself was processed correctly, but the failed notification email interrupted the remaining workflow.
I have therefore kept only a small hardening fix on our side so that a failed upload notification email should no longer break an already saved front-end upload.
Thank you again for the detailed follow-up. This information is very helpful for us and for other users who may see a similar symptom.
Best regards
Arno
thank you very much for the clarification and for taking the time to track this down.
So the actual cause was not the front-end template or a general jDownloads redirect bug, but the Joomla mail configuration.
The upload itself was processed correctly, but the failed notification email interrupted the remaining workflow.
I have therefore kept only a small hardening fix on our side so that a failed upload notification email should no longer break an already saved front-end upload.
Thank you again for the detailed follow-up. This information is very helpful for us and for other users who may see a similar symptom.
Best regards
Arno
#17
Bugs! / Re: Unauthorized access to Dow...
Last post by jpierre - 04.05.2026 09:46:38Hi Arno,
Thanks a lot for your reply.
Here are the infos i got :
This is by the way what i did as a workaround :
- create a new 'Registered_BCK' group with sign in access at the same level than 'Registered'
- move all my sub groups from Registered to Registered_BCK
- change any access level using Registered to Registered_BCK
- and all is accessible again, like it was for the other native groups like Super Users ...
- Note that any of my permissions are Inherited.
- the permissions of one affected category : --> 20250504_Category_Permissions.png, all Inherited
- the permissions of one affected download: --> 20250504_Download_Permissions.png, all Inherited
- user creation --> 20250504_Test_User_Creation.png
- ACL Creation --> 20250504_ACL_Creation.png
- Category Creation --> 20250504_Category_Creation.png
- Category Permission --> 20250504_Category_Permissions.png
- Download Creation --> 20250504_Download_Creation.png
- Download Permission --> 20250504_Download_Permissions.png
And the test from Front End :
- Accessing the download --> 20250504_TestDownloadFrontEnd_1.png
- after clicking on download -- >20250504_TestDownloadFrontEnd_2.png
- Check DataBase Table
- Reset Permissions
But not yet the Database Fix from Joomla.
I joined as well the Update log so that you wan see what process has been followed up.
(In PM to be able to join the files)
Pierre
Thanks a lot for your reply.
Here are the infos i got :
Quote1. Which exact Joomla user group is affected?Any Group (or direct User) inheriting from Registered, if those Users / Groups are moved to a 'new Registered' group with standard settings, all downloads become functional again.
This is by the way what i did as a workaround :
- create a new 'Registered_BCK' group with sign in access at the same level than 'Registered'
- move all my sub groups from Registered to Registered_BCK
- change any access level using Registered to Registered_BCK
- and all is accessible again, like it was for the other native groups like Super Users ...
- Note that any of my permissions are Inherited.
Quote2. Does the problem affect all downloads, or only some categories / downloads?Yes the problem affect all downloads. They are still visible according to ACL, user can click on Download and then get an Unauthorized message (see below for screenshots 20250504_TestDownloadFrontEnd_2.png).
Quote3. Please post screenshots of:- the affected jDownloads user group settings : --> Not accessible, see 20250504_UserGroupSettings_KO.png
- the permissions of one affected category : --> 20250504_Category_Permissions.png, all Inherited
- the permissions of one affected download: --> 20250504_Download_Permissions.png, all Inherited
Quote4. Please test one simple case:see the following process :
- user creation --> 20250504_Test_User_Creation.png
- ACL Creation --> 20250504_ACL_Creation.png
- Category Creation --> 20250504_Category_Creation.png
- Category Permission --> 20250504_Category_Permissions.png
- Download Creation --> 20250504_Download_Creation.png
- Download Permission --> 20250504_Download_Permissions.png
And the test from Front End :
- Accessing the download --> 20250504_TestDownloadFrontEnd_1.png
- after clicking on download -- >20250504_TestDownloadFrontEnd_2.png
Quote5. If possible, please also tell me whether anything changes after:We did indeed those action from jdownloads Tools menu:
- Check DataBase Table
- Reset Permissions
But not yet the Database Fix from Joomla.
I joined as well the Update log so that you wan see what process has been followed up.
(In PM to be able to join the files)
Pierre
#18
General / Re: Bug Report: 404 Error afte...
Last post by musicasampler - 04.05.2026 00:32:06Hi Arno,
I have an important update regarding this issue and I would like to apologize for the confusion. I discovered that the problem was not actually a bug in jDownloads, but rather a configuration issue with my Joomla Mail Settings.
Technical Root Cause:
After several tests, I found that when a member uploaded a MIDI file, the file was being processed and saved correctly in the database and folder. However, because the Joomla global mail system was failing to send the "New Upload" notification, the process was being interrupted. This interruption prevented the final redirection, resulting in the 404 error (ID=0).
The Solution:
Once I fixed the SMTP/Mail settings in Joomla's Global Configuration, everything returned to normal. The notifications are now being sent correctly, and jDownloads redirects the user to the success page without any errors.
Important Note for the Community:
If anyone experiences a 404 error after a successful upload, I recommend checking your Joomla mail configuration first. If the notification fails to send, it may break the redirection flow even if the file was received perfectly.
Thank you again for your quick support and for providing version 4.1.4. It turns out the component is working perfectly!
Best regards,
I have an important update regarding this issue and I would like to apologize for the confusion. I discovered that the problem was not actually a bug in jDownloads, but rather a configuration issue with my Joomla Mail Settings.
Technical Root Cause:
After several tests, I found that when a member uploaded a MIDI file, the file was being processed and saved correctly in the database and folder. However, because the Joomla global mail system was failing to send the "New Upload" notification, the process was being interrupted. This interruption prevented the final redirection, resulting in the 404 error (ID=0).
The Solution:
Once I fixed the SMTP/Mail settings in Joomla's Global Configuration, everything returned to normal. The notifications are now being sent correctly, and jDownloads redirects the user to the success page without any errors.
Important Note for the Community:
If anyone experiences a 404 error after a successful upload, I recommend checking your Joomla mail configuration first. If the notification fails to send, it may break the redirection flow even if the file was received perfectly.
Thank you again for your quick support and for providing version 4.1.4. It turns out the component is working perfectly!
Best regards,
#19
General / Re: Bug Report: 404 Error afte...
Last post by Arno - 04.05.2026 00:07:22Hello,
I have now added a first fix for the front-end upload redirect flow (please use the new version 4.1.4 that I'll send you via PM).
The issue looked less like a template problem and more like a save/redirect problem after creating a new front-end download:
the upload file could already be written successfully, but the redirect could still fall back to an empty form state with id=0.
I have adjusted the redirect handling so that after a successful new front-end upload, the saved item ID is used correctly instead of falling back to a_id=0. I also hardened the return-link handling a bit.
Please test again with the same workflow and let us know:
1. whether the upload still ends on a 404 page
2. whether the redirect now opens the created download/edit page correctly
3. whether this changes with SEF on or off
Thanks!
I have now added a first fix for the front-end upload redirect flow (please use the new version 4.1.4 that I'll send you via PM).
The issue looked less like a template problem and more like a save/redirect problem after creating a new front-end download:
the upload file could already be written successfully, but the redirect could still fall back to an empty form state with id=0.
I have adjusted the redirect handling so that after a successful new front-end upload, the saved item ID is used correctly instead of falling back to a_id=0. I also hardened the return-link handling a bit.
Please test again with the same workflow and let us know:
1. whether the upload still ends on a 404 page
2. whether the redirect now opens the created download/edit page correctly
3. whether this changes with SEF on or off
Thanks!
#20
General / Re: Bug Report: 404 Error afte...
Last post by Arno - 03.05.2026 19:55:01Hello,
thank you for the report. If the upload itself succeeds but the redirect ends with id=0 or a_id=0, then this looks like a real bug in the front-end upload/save or redirect flow, not a template styling issue.
So the likely problem is that after saving the upload, no valid download ID is passed into the redirect URL.
Please tell us:
1. Does the uploaded entry appear in the database table #__jdownloads_files?
2. Does this happen for every front-end upload or only for specific files?
3. Does it also happen with SEF disabled?
This should help us determine whether the record is not saved correctly or whether only the redirect URL is built incorrectly afterwards.
thank you for the report. If the upload itself succeeds but the redirect ends with id=0 or a_id=0, then this looks like a real bug in the front-end upload/save or redirect flow, not a template styling issue.
So the likely problem is that after saving the upload, no valid download ID is passed into the redirect URL.
Please tell us:
1. Does the uploaded entry appear in the database table #__jdownloads_files?
2. Does this happen for every front-end upload or only for specific files?
3. Does it also happen with SEF disabled?
This should help us determine whether the record is not saved correctly or whether only the redirect URL is built incorrectly afterwards.