Bug #91995
open
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 S P over 4 years ago.
Updated over 1 year ago.
Category:
Site Handling, Site Sets & Routing
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.
- 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
- 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)
- Related to Task #88376: Remove legacy "pageNotFound_handling" options added
- 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
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...
- 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.
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.
For TYPO3 Core: We'd need to have a custom error handler within the SiteResolver middleware when no site was found. Question is how to configure it in a flexible way like we do with site configurations?
- Sprint Focus set to On Location Sprint
- Sprint Focus deleted (
On Location Sprint)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by