TYPO3 Core

I think this is a good suggestion and a useful improvement. However, I am currently working on the opposite: make it possible to ignore some specific link targets. In our site it is much more a problem, that some URLs are always reported as broken even though they are not. A lot of this are pages with login, but there are also other reasons.

I had 3 ideas how to solve that and am currently working on a solution where you have an "ignore button": https://review.typo3.org/c/Packages/TYPO3.CMS/+/66608

Any feedback on that would be welcome.

I also had the idea to just add the to-be-ignored URLs to the TSconfig but this is more flexible - it can be made available to editors or not, it could be imported from a file etc.

You requirement could be done in a similar way. But I am currently not sure, how it should be implemented. Maybe you can think about this some more and comment how you would implement it.

Currently, I see at least 2 fields that would be required:

- URL (link target), this can be external, but also a page, file, email etc.
- a reason
- And for each reason, text to display as error - ideally make it possible to translate. We could also provide some standard texts which could be used, e.g. "Do not link to this URL for legal reasons", "Use page links to link to site", "The site will be shut down" etc.

The reason could just be a code and we have some standard texts for that. Alternatively we might make it possible to add your own custom reasons.

I have some more comments:

- for some cases, I would prefer to catch these kind of errors early, e.g. when the URL is entered (though - of course you will still need to find existing cases), e.g. in the Link Browser or on RTE transformations

Find all External Links that are indeed pointing to the site itself in order to replace them for internal links

I think this is a very common usecase. We also have this a lot (editors use external URLs to link to pages on the site). Georg Ringer recently created an extension, which takes care of this partly, but not for rich text fields. We are currently looking into the possibility of funding a solution which will do that - either in the core or as separate extension. If you want to help to fund this, please contact me.

So, I would currently wait how that pans out.