Bug #95174
closed
pageNotFoundAction not working properly in Extbase with feature toggle subrequestPageErrors turned on
100%
Description
When the feature toggle subrequestPageErrors is turned on, the subrequest does not properly fetch the configured page uid of the error handler and return an "empty" (just some basic TYPO3 HTML available) page instead.
How to reproduce:
Ensure that the TYPO3 page error handler is configured to show the content of a TYPO3 page and that that page contains some content to be shown.
The most easy way to reproduce the problem is to test it in TYPO3 core ext:felogin, which is an Extbase extension with a frontend plugin. Add the plugin "Frontend Login" to a page in the pagetree and open the page in the frontend. The login form should be shown.
Now in TYPO3\CMS\FrontendLogin\Controller\LoginController::loginAction add the following code to the start of the action:
$response = GeneralUtility::makeInstance(\TYPO3\CMS\Frontend\Controller\ErrorController::class)->pageNotFoundAction(
$this->request,
'Object not found.'
);
throw new \TYPO3\CMS\Core\Http\PropagateResponseException($response, 1631261423);
With subrequestPageErrors feature toggle turned off, the content of the configured error page is shown. When the feature flag is turned on, only a blank page is shown.
Updated by Torben Hansen over 2 years ago
- Related to Bug #94402: Don't issue second HTTP request for error handling added
Updated by Simon Schaufelberger over 2 years ago
- Target version set to 11 LTS
I can confirm this strange behavior when throwing this exception within an extbase action and I also tried throwing an ImmediateResponseException action with the same result:
I don't see the content of the subrequest even though it is fetched in \TYPO3\CMS\Core\Error\PageErrorHandler\PageContentErrorHandler->handlePageError()
but for some reason the result of the stashEnvironment method does NOT contain the 404 page content but the "login" page content in my case which is wrong but the 404 page url is resolved and passed correctly in this line:
$subRequest = $request->withQueryParams([])->withUri(new Uri($resolvedUrl))->withMethod('GET');
$resolvedUrl = http://typo3-core.test/404
How to debug:
(string)$subResponse->getBody();
shows the login page content instead of the 404 page content.
The actual bug lies in \TYPO3\CMS\Frontend\Middleware\PrepareTypoScriptFrontendRendering->process in line `$this->controller->getFromCache($request);`
where `$this->controller` is still the controller from the outer request with the initially requested page id which is not overwritten with the subrequest pageid.
The thing is that the DI Container still holds a reference to the old TSFE object with the old page id.
Updated by Gerrit Code Review over 2 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71084
Updated by Gerrit Code Review over 2 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71084
Updated by Simon Schaufelberger over 2 years ago
- Related to Task #95253: Make in-process subrequests opt-in added
Updated by Gerrit Code Review over 2 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71084
Updated by Anonymous over 2 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 7159ff8aaeb5a0b771ce013862241cb33727b7df.
Updated by
Updated by Benjamin Franzke over 2 years ago
- Related to Task #96273: Remove TypoScriptFrontendController container entry added