pageTSconfig subpage level is not considered in Linkvalidator
Currently, linkvalidator is highly configurable, the settings can be applied via TSconfig for a page / user / group.
When checking links however, only the page TSconfig of the current start page is considered. Different page TSconfig on a subpage is not considered. It does not override the settings.
Steps to Reproduce¶
- Create 2 pages with 1 tt_content element each, with a broken link each in in tt_content.header and tt_content.bodytext. I page is parent of the other
- Set the TSconfig on the first page to scan bodytext and header
- Set the TSconfig of the child page to only scan bodytext
- Start "Check links" from the parent page and view report
- Start "Check links" from the child page and view report
Get same number of broken links for child page: 1 (only bodytext)
If "Check links" is started on child page, the result is correct.
If "Check links" is started on parent page, the result is 2 links for child page (not correct)
- keep current behaviour and document this (I think having a different configuration on a subpage is highly unlikely to ever be required)
- change behaviour to check for configuration on subpages
#6 Updated by Oliver Bartsch about 2 months ago
I had a look into this. It's currently not possible by design as the
LinkAnalyzer gets initialised only once with the page TSconfig of the currently selected page and then traverses over all configured searchFields (table=>fields pairs) and tries to find broken links on all relevant pages (current page and subpages respecting configured depth) matching the table=>fields pairs.
To provide this functionality we had to change the
LinkAnalyzer so that we traverse the pages list, get the TSconfig for the page and afterwards traverse over the
searchFields for every single page. Also keep in mind that we then have to deal with a special case as pages itself is usually included in the
searchFields which may need a different lookup then. In my opinion this may have a huge performance impact for generating results on root pages with hundreds of sub pages which all must be evaluated individually.
As you already said, it's very unlikely that this is a real use-case as one can still use different configurations by running the analyzation on the desired pages directly. I think we should document this properly and close this issue. What do you think?
#7 Updated by Sybille Peters about 2 months ago
@Oliver, I would also opt to not make it more complicated. Especially, if it comes with a performance impact.
I personally think the configuration can be made globally for entire installation or per site, so we would not need to override the configuration on a subpage.
I think it just needs to be made clear in the docs. I would opt to check that and possibly add it there.
P.S. Thanks for taking care of these issues :)