- Welcome to jDownloads Support Forum.
jDownloads Support Forum
Here can you get help for jDownloads!
Recent posts
#31
Bugs! / Re: {cat_link} not substituted...
Last post by incolor - 19.08.2026 19:02:09correction: one unresolved {cat_link} anchor per subcategory
#32
Bugs! / Re: {cat_link} not substituted...
Last post by incolor - 19.08.2026 18:56:30I should mention that this was using the "Standard Bootstrap 5 Subcategories Layout - Multiple Column List v4.1" layout.
#33
Bugs! / {cat_link} not substituted in ...
Last post by incolor - 19.08.2026 18:52:58SUMMARY
On a Category view, the Sub-Categories block emits five literal {cat_link}
placeholders as anchor tags before each subcategory, instead of substituting
the category URL. The placeholder appears in both the link text and the href.
This reproduces on three different layouts, including two stock ones, so it
does not appear to be a layout customization problem.
ENVIRONMENT
jDownloads: [4.1.7]
Joomla: [6.1.3]
PHP: [8.3.33]
Installation: Fresh install of jDownloads. I think Joomla was a fresh install from 6.x (but unsure).
Template: YOOtheme Pro
SEF URLs: On
STEPS TO REPRODUCE
1. Fresh jDownloads installation.
2. Create a parent category, and several subcategories beneath it.
3. Assign a Category-type layout that includes the Sub-Categories block.
4. View the parent category on the front end.
5. View source, or inspect the Sub-Categories area.
EXPECTED
Each subcategory renders with its own resolved URL, for example:
/download-library/category/5-analyzer-apis
ACTUAL
Five anchors per subcategory are emitted with the placeholder unresolved:
/{cat_link}
The site root is prepended, but {cat_link} itself is passed through verbatim.
So the substitution is not running at all, rather than resolving to an empty
value.
THE PRECISE SHAPE OF IT
This seems the most diagnostic part. Within EACH subcategory block:
5 anchors contain the unresolved {cat_link} placeholder
2 anchors - the folder icon and the subcategory title - resolve
correctly to the real category URL
So the same page substitutes the category link correctly in two places and
fails to substitute it in five others, inside the same repeated block. That
suggests the placeholder is valid in one context of the layout and not in
another, rather than being globally broken or misspelled.
The count scales exactly with the number of subcategories:
7 subcategories -> 35 unresolved anchors
8 subcategories -> 40 unresolved anchors
WHAT IT IS NOT
Ruled out by testing, so these should not need to be asked:
- Not a custom layout. First seen on a customized Category layout, then
reproduced on the stock default layout, then again on a second, older
stock layout. Three layouts, identical output.
- Not a single category. Every subcategory in the list is affected, and it
recurred after the category set was changed and re-sorted.
- Not an upgrade artifact. This is a fresh installation, not carried forward
from an earlier jDownloads series.
- Not template-related as far as can be determined. The surrounding markup
renders correctly, and the two working links sit in the same block.
IMPACT
Cosmetically, visitors see repeated /{cat_link} text above every subcategory.
More seriously, each one is a live anchor pointing at a URL that does not
exist, so:
- search engines crawl and index broken links
- screen readers announce five meaningless links before every category
- the page fails link validation
A CSS rule hides them from sighted visitors:
a[href$="{cat_link}"] { display: none; }
But they remain in the served HTML, so that is a workaround rather than a fix.
POSSIBLE CAUSE
Offered tentatively, having not read the code: {cat_link} may be a placeholder
that is only resolved within one section of a layout type, while the
Sub-Categories block is rendered by a different handler that does not process
it. The two anchors that do work in the same block would then be built from a
different variable rather than from this placeholder.
If that is right, the stock Category layout is shipping {cat_link} in a
section where it cannot resolve.
Reported by In Color - https://incolor.dev
On a Category view, the Sub-Categories block emits five literal {cat_link}
placeholders as anchor tags before each subcategory, instead of substituting
the category URL. The placeholder appears in both the link text and the href.
This reproduces on three different layouts, including two stock ones, so it
does not appear to be a layout customization problem.
ENVIRONMENT
jDownloads: [4.1.7]
Joomla: [6.1.3]
PHP: [8.3.33]
Installation: Fresh install of jDownloads. I think Joomla was a fresh install from 6.x (but unsure).
Template: YOOtheme Pro
SEF URLs: On
STEPS TO REPRODUCE
1. Fresh jDownloads installation.
2. Create a parent category, and several subcategories beneath it.
3. Assign a Category-type layout that includes the Sub-Categories block.
4. View the parent category on the front end.
5. View source, or inspect the Sub-Categories area.
EXPECTED
Each subcategory renders with its own resolved URL, for example:
/download-library/category/5-analyzer-apis
ACTUAL
Five anchors per subcategory are emitted with the placeholder unresolved:
/{cat_link}
The site root is prepended, but {cat_link} itself is passed through verbatim.
So the substitution is not running at all, rather than resolving to an empty
value.
THE PRECISE SHAPE OF IT
This seems the most diagnostic part. Within EACH subcategory block:
5 anchors contain the unresolved {cat_link} placeholder
2 anchors - the folder icon and the subcategory title - resolve
correctly to the real category URL
So the same page substitutes the category link correctly in two places and
fails to substitute it in five others, inside the same repeated block. That
suggests the placeholder is valid in one context of the layout and not in
another, rather than being globally broken or misspelled.
The count scales exactly with the number of subcategories:
7 subcategories -> 35 unresolved anchors
8 subcategories -> 40 unresolved anchors
WHAT IT IS NOT
Ruled out by testing, so these should not need to be asked:
- Not a custom layout. First seen on a customized Category layout, then
reproduced on the stock default layout, then again on a second, older
stock layout. Three layouts, identical output.
- Not a single category. Every subcategory in the list is affected, and it
recurred after the category set was changed and re-sorted.
- Not an upgrade artifact. This is a fresh installation, not carried forward
from an earlier jDownloads series.
- Not template-related as far as can be determined. The surrounding markup
renders correctly, and the two working links sit in the same block.
IMPACT
Cosmetically, visitors see repeated /{cat_link} text above every subcategory.
More seriously, each one is a live anchor pointing at a URL that does not
exist, so:
- search engines crawl and index broken links
- screen readers announce five meaningless links before every category
- the page fails link validation
A CSS rule hides them from sighted visitors:
a[href$="{cat_link}"] { display: none; }
But they remain in the served HTML, so that is a workaround rather than a fix.
POSSIBLE CAUSE
Offered tentatively, having not read the code: {cat_link} may be a placeholder
that is only resolved within one section of a layout type, while the
Sub-Categories block is rendered by a different handler that does not process
it. The two anchors that do work in the same block would then be built from a
different variable rather than from this placeholder.
If that is right, the stock Category layout is shipping {cat_link} in a
section where it cannot resolve.
Reported by In Color - https://incolor.dev
#34
General / Re: License in batch for all d...
Last post by ColinM - 19.08.2026 12:02:57Hi
Is you problem solved?
ColinM
Is you problem solved?
ColinM
#35
General / Re: License in batch for all d...
Last post by ServiceVerkoop.eu - 18.08.2026 23:08:41 #36
General / Re:cron and special char
Last post by ColinM - 18.08.2026 22:34:50Hi
Have you read article 'Including a license in a Download -July 2026'
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=277
Also Article 'Batch Processing'
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=268
Have you read article 'Including a license in a Download -July 2026'
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=277
Also Article 'Batch Processing'
https://www.jdownloads.net/administrator/index.php?option=com_content&view=article&layout=edit&id=268
#37
General / License in batch for all downl...
Last post by baba - 18.08.2026 11:48:32Hello,
i am on jDownloads Version 4.1.7 Stable and want to assign a licence and make it "must accept" for all existing download in batch. Is there a way to do this? Because i server a lot of files it must be in batch mode!
Thank You - Any help is highly appreciated!
i am on jDownloads Version 4.1.7 Stable and want to assign a licence and make it "must accept" for all existing download in batch. Is there a way to do this? Because i server a lot of files it must be in batch mode!
Thank You - Any help is highly appreciated!
#38
Suggestions - Feature Request / Re: appoint a folder and subfo...
Last post by ServiceVerkoop.eu - 14.08.2026 23:29:29The version you sent me solved the problem of skipping files while scanning as they are now being scanned 
#39
Suggestions - Feature Request / Re: appoint a folder and subfo...
Last post by ServiceVerkoop.eu - 14.08.2026 16:55:13Quote from: Arno on 07.08.2026 23:44:53Do you mean that monitoring should allow selecting a specific folder (including subfolders), and then scan/import only that part instead of the entire download directory?Hi, Thank you for replying.
That is what i mean yes!
I will tryout the version you sent and come back when tested
#40
Bugs! / Re: Smart Index Error
Last post by ColinM - 09.08.2026 13:05:17Hi
Your analysis is absolutely correct: in CLI context there is no menu object like in normal web requests, so calling getMenu() directly can fail. Your workaround with method_exists() is a valid approach.
So We have implemented this fix on our side in both code lines:
jDownloads 4.x
jDownloads 6.x
Many thanks
ColinM
Your analysis is absolutely correct: in CLI context there is no menu object like in normal web requests, so calling getMenu() directly can fail. Your workaround with method_exists() is a valid approach.
So We have implemented this fix on our side in both code lines:
jDownloads 4.x
jDownloads 6.x
Many thanks
ColinM