Bug #91995

It's not possible to handle the case "no site config yaml found" for a domain like an error (e.g. 404 or 503)

Added by Stefan P over 1 year ago. Updated about 1 month ago.

Status:
Accepted
Priority:
Should have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Target version:
-
Start date:
2020-08-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Yes
Sprint Focus:

Description

We have a big TYPO3 setup with hundreds of domains, all configured via site config yaml files.

If - by whatever accidental reason - a domain is pointing to the TYPO3 system that was NOT configured as a site yaml, then the first "pseduo site" is used instead (which usually is the first is_siteroot = 1 found in the page tree). Then this domain displays totally unrelated and random content.

It's OK to show the first site from the page tree if NO yaml exists at all (to make life easier for beginners or small setups). But as soon as site config yamls exist, a domain that was not configured should not start displaying some random content from a totally arbitrary place in the page tree (which can even change if moving nodes around).

In our case we'd like to show the action configured in [FE][pageNotFound_handling].

It must be posible to handle unconfigured domains somehow.

I flagged this as regression because with ext:realurl this was possible. Realurl then exited at least with a 500 error because the resolution of the rootpage id was ambigious.


Related issues

Related to TYPO3 Core - Task #88376: Remove legacy "pageNotFound_handling" optionsClosedBenni Mack2019-05-16

Actions
#1

Updated by Stefan P over 1 year ago

  • Subject changed from It's not possible to handle erors (like 404) if no site config was found to It's not possible to handle errors (like 404) if no site config was found for a domain
#2

Updated by Stefan P over 1 year ago

  • Subject changed from It's not possible to handle errors (like 404) if no site config was found for a domain to It's not possible to handle the case "no site config yaml found" for a domain like an error (e.g. 404 or 503)
#3

Updated by Georg Ringer over 1 year ago

  • Related to Task #88376: Remove legacy "pageNotFound_handling" options added
#4

Updated by Georg Ringer over 1 year ago

  • Status changed from New to Accepted

With #88376 the pagenotfound handling has been dropped but for sure a correct error should be thrown. this can only happen for 11.

I propose to use middleware for checking the site and return a custom error to fix it in the meantime for you

#5

Updated by Stefan P over 1 year ago

this can only happen for 11.

Why? v9 is still LTS and marketed as an "enterprise CMS". Most big setups (the ones that are affected by such behaviour most) are starting just now to migrate now from 8 to 9 - hundreds-of-domain setups with loads of stakeholders and budgets of several 100k can't simply "early-adopt" or "upgarde to next version". The release schedule and time span for giving this kind of feedback for real-life setups (with a chance of fixing/implementing) of TYPO3 got way to tight lateley...

#6

Updated by Stefan P about 2 months ago

  • TYPO3 Version changed from 9 to 10

Still valid in v10. However, v10 at least shows an error instead of the first random site found. It would still be nice to be able to easily configure a global fallback in this case, to show a static page.

#7

Updated by Stefan P about 1 month ago

The workround is to implement a custom Middleware between these two:

'after' => [
    'typo3/cms-frontend/site'
],
'before' => [
    'typo3/cms-frontend/maintenance-mode'
]

In this Middleware you have to check whether you have a NullSite and react accordingly:

public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
    if (!$request->getAttribute('site') instanceof \TYPO3\CMS\Core\Site\Entity\NullSite) {
        return $handler->handle($request);
    }

    return new \TYPO3\CMS\Core\Http\Response(
        'path/to/404.file',
        404
    );
}

Still, I don't get why the core can't do this small step by itself anymore (only maybe after the redirect middleware in the general case)!? You could simply have returned the setting in FE|pageNotFound_handling whenever there is a NullSite instead of removing these settings and exit with an "Ooops". Why were these settings dropped, then, if a Middleware can handle them flawlessly? The changelogs sound like this was not possible anymore, that's what made me write this ticket in the first place. But it turns out, it's still possible with not much effort.

Also available in: Atom PDF