TYPO3 Core

This makes cms-redirects pretty much unusable if you are working across multiple environments. The current behaviour does not make any sense, because you basically select a site whose domain then is stored in the DB. It also does not reflect any change to the site domain.

Christian Spoo wrote:

This makes cms-redirects pretty much unusable if you are working across multiple environments. The current behaviour does not make any sense, because you basically select a site whose domain then is stored in the DB. It also does not reflect any change to the site domain.

Thanks for your comment, however it does not add anything useful in order to enhance the situation.
Looking forward to reading your suggestion on how to address this issue in particular. Thx!

Sure. To my mind the best solution would be storing the site ID instead of the domain in sys_redirects. The RedirectService should then determine the correct site domain depending on the ID in order to check whether there was a matching redirect record. The tuple (site ID, site domain) is nothing that should be kept across two requests since the result of resolving the defined conditions may vary from one request to another one.

My comment above refers to the fact that cms-redirects is not a 3rd-party extension but part of TYPO3 itself. Therefore - to be honest - it surprised me that someone thought that storing hardwired references to a site domain was a good idea. Maybe he or she was unaware of the fact that it is possible to override site domains through conditions. Or (almost) nobody uses cms-redirects and sites together. :-)
I'll leave that up to everyone's own interpretation.

it surprised me that someone thought that storing hardwired references to a site domain was a good idea

This information has to be non-normalized, because it is historic data. Compare this Shop Systems where you do not reference Payment and Shipping/Billing Data, but rather write a fully denormalized row into the database, because you have to ensure that this information will never change.

Think of a situation, where i change a Site's Base from example.net to example.org.
TYPO3 should generate a redirect for each page in the page tree beginning at the Site's rootPageId.
You need the source domain to restrict redirects to that specific part of the page tree (otherwise the redirect will affect other page trees with different domains, too).
When referencing the Site you loose the information about the previous domain and the redirect will not work for the URL it was originally generated for.

The bottom line is: Denormalization is required and no evil (in this case). But that's not the point.
The point is, that TYPO3 does not generate these Redirects.

Site configurations can change in 2 different ways:
1. A Backend User changed something in the Site Configuration Module
2. Someone with file system access changed the file on disk (this includes deployments)

TYPO3 can easily detect changes in case 1 and knows the former configuration to properly set source_host.
Case 2 is a bit more difficult. TYPO3 can detect the change based on a a file hash (contents hash), but has to compute if any domain or URL-relevant part changed and remember, how the configuration looked before the change. A Cache must not be used for this. Maybe sys_registry can store a Site Identifier to Site Domain Mapping?
When processing a Site the Hash must be verified. If there is a mismatch, TYPO3 has to check if there are any differences and create redirects respectively.

This information has to be non-normalized, because it is historic data.

I agree that there are valid cases in which redirects originate from historic data. Of course, I also know about the common principle of freezing historical data in e-Commerce applications and they are valid, too.

However, one must not completely forget about the cases in which redirects are simply used to provide shortcuts to pages. It is very common to have such redirects in order to provide URL shortening e.g. for advertising purposes. Even if one argues that they might as well be replaced by shortcut pages (which would IMO apply to the case of a moved page as well), I'd rather consider the redirects extension as the way to go here. Redirects are handled much earlier in the request pipeline and their use definitely improves the overall site performance.

Compare that to an installation in which you would handle all such shortened URL by shortcut pages. I am absolutely sure that you could tell the difference in terms of the number of issued DB queries and the time needed to answer requests. :-)

What about the following suggestion (which would cover both cases)?
Why don't we enable the module to match either against a site OR a fixed hostname? If the editor wants to pin the hostname to be checked against to one of a configured site, we can greet him with an appropriate select box whose value could be overridden.
We already bother them with the possibility to use regexes so I doubt the added complexity to pose much of a problem.

I admit that this does not solve the problem of a move page which needed to be solved, too. In previous TYPO3 versions we happened to create https://github.com/marketing-factory/restructure_redirect to mitigate that but I'd prefer an "official" solution here if it was for one.