Bug #95650
Updated by Sybille Peters over 2 years ago
h2. versions * I noticed this in 10.4.21 * but could also reproduce it in current "master" "master". For me, redirects:checkintegrity is not really useful because of this problem. h2. Problem redirects:checkintegrity reports "false positives": redirect problems which are not problems. h2. Causes of this problem Problem occurs, if the "source_path" of a redirect is the same slug as a translated page. But this is not an actual redirects conflict: the source_path of the redirect does not affect any page (because e.g. /de/ is prepended to the slug of translated page). It looks like redirects:checkintegrity does not consider the language correctly. h2. Reproduce # Create a page with one slug and translation with a different slug, e.g. "language-alt" EN (default language): slug=/language [421] DE: slug=/language-alt, effective URL is /de/language-alt 2. Now create redirect using the slug on the translation page as source and pointing to target page: <pre> /language-alt > t3://page?uid=421 </pre> So, we are redirecting a slug which currently does not map to a page at all to an existing page. 4. result is: checkintegrity "detects" this as error <pre> Redirect (Host: t3coredev, Path: /language-alt) conflicts with /language-alt </pre> This is wrong. All URLs work and the redirect works: * http://t3coredev/language-alt ==> http://t3coredev/language * http://t3coredev/de/language-alt h2. DB *pages:* <pre> +-----+-----+------------------+-------------+---------------+ | uid | pid | sys_language_uid | l10n_parent | slug | +-----+-----+------------------+-------------+---------------+ | 421 | 420 | 0 | 0 | /language | | 422 | 420 | 2 | 421 | /language-alt | +-----+-----+------------------+-------------+---------------+ </pre> *sys_redirect:* <pre> +---------------+-------------------+ | source_path | target | +----------------------------------------------+-------------------+ | /language-alt | t3://page?uid=421 | +---------------+-------------------+ </pre> h2. Impact of problem It is not easily possible to detect "redirect chains" or other real problems. *These occur on a regular basis* . You can't leave the site unmaintained because editors can't fix them themselves and you can't give editors access to redirects module because they would have access to all redirects. After running with TYPO3 v10 for about 6 months: * 5000 redirects * redirects:checkintegrity reports : 124 entries *