Project

General

Profile

Actions

Bug #102018

open

URL suffix is not taken into account in ‪TYPO3\CMS\Core\Routing\PageSlugCandidateProvider::‪getCandidatesForPath()

Added by Stefan Maischner 7 months ago. Updated 7 months ago.

Status:
New
Priority:
Should have
Assignee:
Category:
Link Handling, Site Handling & Routing
Target version:
-
Start date:
2023-09-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
8.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

I am updating a multi domain + multi language website from TYPO3 8 to 11.

The language fallbacks are set up properly: if a page is not translated the fallback (language 0) should be the candidate to show.
Nevertheless a 404 is thrown.

I dived into the core code and found out, that the variable $slugCandidate did not use the configured suffix /
It is even removed. In TYPO 12 the behaviour is the same as I can see.

The code in TYPO3\CMS\Core\Routing\PageSlugCandidateProvider::‪getCandidatesForPath():

$slugCandidate = '/' . trim($candidate['slug'], '/');
..
if ($urlPath === $slugCandidate) {

My config.yaml:

languages:
  -
..
    languageId: 1
    fallbackType: fallback
    fallbacks: '0'
..
routeEnhancers:
  PageTypeSuffix:
    type: PageType
    default: /
    suffix: /
    index: ''
    map:
      /: 0
..

If I add the suffix to the $slugCandidate quick & dirty, the behaviour is as expected and I can move forward with the next challenges.

$slugCandidate = '/' . trim($candidate['slug'], '/') . '/';

Thanks for fixing this.


Related issues 1 (1 open0 closed)

Related to TYPO3 Core - Story #101565: Frontend related translation issuesNew2023-08-03

Actions
Actions #1

Updated by Stefan Maischner 7 months ago

Addition: I had to extend my quick fix a bit so that the XML sitemaps and root pages still work:

$slugCandidate = '/' . trim($candidate['slug'], '/') . ( strpos( $urlPath, '.xml' ) === false && $candidate['slug'] != '/' ? '/' : '' );
Actions #2

Updated by Stefan Maischner 7 months ago

A crucial detail to add, why the fallback may not have worked either:
We do not use the language function with classical languages, but with branches. Specifically: there is no main language with its own domain, but only the branches (language > 0) have a domain and should be filled from the content of language 0 in general cases.

config.yaml

languages:
  -
    base: ''    
    languageId: 0
  -
    base: 'https://branch1.com'
    languageId: '1'
  -
    base: 'https://branch2.com'
    languageId: '2'

Actions #3

Updated by Stefan Bürk 7 months ago

  • Category set to Link Handling, Site Handling & Routing
  • Assignee set to Stefan Bürk
Actions #4

Updated by Stefan Bürk 7 months ago

Basically, this is a configuration error.

1. a base should not be empty (neither main nor of a language. It should at least be `/` - but also kind of `unique`
2. if should end in `/` even if a full domain is given.

At least, the SiteConfiguration UI does not allow to add and save a empty base (for a language). That's mentioned in the label for the fields.

However, I will look into it - and eventually fix it. TBH - personally I would through a \Runtime exception for a wrong configuration.

However, you don't need to wait for bugfix on that and instead correct your configuration.

Actions #5

Updated by Stefan Maischner 7 months ago

Thanks four your assessment.

I had also tried it with a slash - with the same inadequate result.
So a configuration error can be excluded here. So I can't correct this configuration either.

The desired setup is basically understandable?
I would very much appreciate it if TYPO3 could also map more complex issues and not just pure textbook cases.

A headless approach is also conceivable, in which no typical languages are used, but language 1 is web (web.brand.com), language 2 is app (app.brand.com) and so on. - and if a "language" is not filled, "language" 0 is used (to which no domain is assigned).

And in conclusion: If configured suffixes are not taken into account at all when routing (at least in the place I found), then that is probably a bug in my eyes. I really hope this can be fixed and I am confident if even I could solve this with a one-liner.

Thank you very much.

Actions #6

Updated by Astrid Haubold 7 months ago

  • Related to Story #101565: Frontend related translation issues added
Actions

Also available in: Atom PDF