unique alias cache misses are not resolved

[dneuge]

If the unique alias table does not contain an entry for an alias during lookup, the resulting secondary lookup done by lookUpTranslation fails if a transformation (strtolower/spaceCharacter) would have to be applied, resulting in 404 for valid URLs. There is no cache miss handling yet.

We created a new feature branch on our fork which allows multiple strategies for cache miss resolution (currently only one provided): feature_1x_unique_cache_miss

One way to populate the alias table is to call a page which contains the failing link. For tt_news this could be a page containing a LIST view, linking to the SINGLE view (which contains aliases in the URL and thus may fails lookup). We implemented that strategy called "fetchPagesAndRetry", see our commit message for details on the problem, the solution and how to configure it: https://github.com/glutrot/typo3-realurl/commit/630917f29009c84f3fbf1e5c4ff240583f156f8c

Another way to resolve the cache miss could be to perform a fuzzy check for any possible matches by converting to lowercase and replacing all special characters with wildcards on query (e.g. /news/single/the-alias-to-test-for-4/ => LOWER(field_alias) LIKE 'the%alias%to%test%for%').

However, the advantage of generating only those aliases actually being linked to (such as by our fetchPagesAndRetry strategy) is that invalid aliases can still fail and report a 404 reply. This is a wanted behaviour for tt_news if multiple configurations (archived, non-archived, by year, ...) are being used.

Note that our implementation has only been tested on a multilingual 4.5 site so far; testing on 6.2 will happen in a few days. Plus, I'm not sure if the possible race condition of multiple cache misses running clearPageCacheMgm while page calls (cache repopulation) are being performed may cause any issues (however, that race condition also exists if an admin clears caches via BE).

[dmitryd]

Thank you, I will have a look soon.