Project

General

Profile

Actions

Bug #102892

open

RuntimeException when using redirects with record link targets

Added by Christian Gebing 12 months ago. Updated 20 days ago.

Status:
Accepted
Priority:
Must have
Assignee:
Category:
Link Handling & Redirect Handling
Target version:
-
Start date:
2024-01-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
8.1
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

I get the following exception for redirects with record links targets after the site is stored in the cache:

(1/1) #1666513645 RuntimeException

Setup array has not been initialized. This happens in cached Frontend scope where full TypoScript is not needed by the system.
Steps to reproduce:
  1. Flush caches via the maintanance tool
  2. Add a new redirect with a record link target (e.g. t3://record?identifier=example&uid=1)
  3. Follow the redirect
  4. Open the start page or any other page on the current site
  5. Attempt to follow the redirect again

Tested on a minimal TYPO3 ddev setup: https://github.com/cgebing/typo3_record_link_test


Files

2024-01-22_18-57.png (66.3 KB) 2024-01-22_18-57.png Redirect Christian Gebing, 2024-01-22 17:58
record-linkbuilder-missing-typoscript-fix.diff (2.18 KB) record-linkbuilder-missing-typoscript-fix.diff Ramon Zöllner, 2024-11-20 10:56

Related issues 2 (2 open0 closed)

Related to TYPO3 Core - Bug #104512: Redirect targets with individual linkHandler not workingNew2024-07-31

Actions
Related to TYPO3 Core - Task #105648: POC for broken redirect handling to record link targetsNew2024-11-20

Actions
Actions #1

Updated by Stefan Bürk 12 months ago

  • Assignee set to Stefan Bürk
Actions #2

Updated by Armin Vieweg 10 months ago

I can reconstruct this issue.
It disappears, when clearing the frontend cache, then the redirects work as expected.

But as soon as I call the front page (the first page in rootLine, which contains the TypoScript setup) and this page gets cached, the redirect break, with the exception from above.

I tried several TYPO3 versions. This issue seems to occure since 12.4.2. In 12.4.1 I am not able to reconstruct the issue, by calling the first page in rootLine (the front page). There, the redirections always work.

Actions #3

Updated by Armin Vieweg 10 months ago

A quick fix is, to disable caching on the first page in rootLine, with e.g.

# Quick fix for https://forge.typo3.org/issues/102892
[traverse(page, "uid") == 1]
config.no_cache = 1
[end]

Absolutely not ideal or recommended, but this solves the issue, which only occures when the first page is being cached.

Actions #4

Updated by Armin Vieweg 10 months ago

I also found the commit, which causes the issue:
https://git.typo3.org/typo3/typo3/-/commit/bd4980f237bf844939b959d0a83909aa7a44b0e0

The issue only occures when the feature toggle "Security: frontend enforce content security policy" [security.frontend.enforceContentSecurityPolicy] is disabled.

Actions #5

Updated by Oliver Hader 10 months ago

I don't think this is related to CSP, but more related to cached TypoScript (I might look into this during the next few days/weeks):
https://github.com/TYPO3/typo3/blob/a085e88596eacb3f2e12bdd49d2f3e7a47faed2c/typo3/sysext/core/Classes/TypoScript/FrontendTypoScript.php#L132-L138

Actions #6

Updated by Benni Mack 10 months ago

Some more notes:

This is related to a fully cached page not having TypoScript anymore, see another issue / bugfix which happened in adminpanel on a fully cached page:

https://review.typo3.org/c/Packages/TYPO3.CMS/+/82396

Actions #7

Updated by Armin Vieweg 10 months ago

@Oliver Hader So, when CSP is on the page cache does not work anymore? Sounds a little bit like that.

@Benni Mack Caching and providing the rendered Typoscript configuration, could solve this, maybe?

Or the redirect Middleware must get enabled to parse the Typoscript, when being triggered and when the target starts with "t3:".

But maybe there are other edge cases, like redirects, which require the parsed Typoscript config.

Actions #8

Updated by Ole Trenner 3 months ago

We are currently running into the same issue. Has there been any progress in fixing this? Or are there approaches to prevent the issue from happening? Thanks!

Actions #9

Updated by Ramon Zöllner 3 months ago

We also ran into this issue with redirects to news records.
All redirects to news records result in a 503.

As a workaround we patched frontend/Classes/Typolink/DatabaseRecordLinkBuilder, catching the runtime exception and force generating the full typoscript.

This solution seems less then ideal to me as it handles the issue downstream and also circumvents caching.

Actions #10

Updated by Bernhard Eckl about 2 months ago

Same here when linking to records.
@Ramon Zöllner would you share your solution please?

Actions #11

Updated by Bernhard Eckl about 2 months ago

  • Related to Bug #104512: Redirect targets with individual linkHandler not working added
Actions #12

Updated by Torben Hansen about 2 months ago

  • Priority changed from Should have to Must have
Actions #13

Updated by Torben Hansen about 2 months ago

  • Related to Task #105648: POC for broken redirect handling to record link targets added
Actions #15

Updated by Torben Hansen about 2 months ago

@Ramon Zöllner Note, that the patch only provides a workaround for TYPO3 v12. I documented the whole topic in #105648 and discussed it with members of the core team, so we at some point can provide a core bugfix for the isssue.

Actions #16

Updated by J. Peter M. Schuler about 2 months ago · Edited

FWIW: This affects Page Error Handler as well - if you site config configure e.g. 404 handling with "Show content from page" and select a page it will have a setting like t3://page?uid=41140 Thus, running into the same problem.
Current situation is that all 404s are now 503 :/-

If you have a Page Error Handler pointing to a page using record handler, the patch in #14 doesn't resolve this.
Will look into that

Actions #17

Updated by Torben Hansen about 2 months ago

@J. Peter M. Schuler I can not confirm, that this affects the page error handler and the t3:// syntax in that place. Please check, if the target 404 page contains any links handled by a record handler.

Actions #18

Updated by Bernhard Eckl about 2 months ago

Ramon Zöllner wrote in #note-14:

@Bernhard Eckl sure. I appended the patch.

Thank you!

Actions #19

Updated by J. Peter M. Schuler about 2 months ago

Torben Hansen wrote in #note-17:

@J. Peter M. Schuler I can not confirm, that this affects the page error handler and the t3:// syntax in that place. Please check, if the target 404 page contains any links handled by a record handler.

Just one text-only element, but the page itself uses some complex fluid for the navigation with custom f:typolink; then it must be that.
Sorry, thought as the 404 page itself is properly cached and has no problems, it is the error handler itself, not the target page.

Thx for the pointer, sry for the hassle.

Actions #20

Updated by Torben Hansen 20 days ago · Edited

  • Status changed from New to Accepted
  • Assignee changed from Stefan Bürk to Torben Hansen

In general, the record link calculation should be decoupled from TypoScript as a dependency, since this not only fails for the redirect service but also in some places in backend context.

I spent some hours on debugging und came up with the following patches, which I also will submit to gerrit.

Bugfix for v13

Index: typo3/sysext/redirects/Classes/Service/RedirectService.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/typo3/sysext/redirects/Classes/Service/RedirectService.php b/typo3/sysext/redirects/Classes/Service/RedirectService.php
--- a/typo3/sysext/redirects/Classes/Service/RedirectService.php    (revision e20f00fbd1e29c1c4b58439e2e81434bdb85c8e6)
+++ b/typo3/sysext/redirects/Classes/Service/RedirectService.php    (date 1735123103958)
@@ -417,7 +417,7 @@
             $this->typoScriptCache,
         );
         $frontendTypoScript = $this->frontendTypoScriptFactory->createSetupConfigOrFullSetup(
-            false,
+            true,
             $frontendTypoScript,
             $site,
             $pageInformation->getSysTemplateRows(),

Bugfix for v12 (additionally fixes #99797)

Index: typo3/sysext/redirects/Classes/Service/RedirectService.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/typo3/sysext/redirects/Classes/Service/RedirectService.php b/typo3/sysext/redirects/Classes/Service/RedirectService.php
--- a/typo3/sysext/redirects/Classes/Service/RedirectService.php    (revision 1578898640ae3940645c475e4f8d4dfa821528ec)
+++ b/typo3/sysext/redirects/Classes/Service/RedirectService.php    (date 1735149803147)
@@ -23,6 +23,7 @@
 use Psr\Log\LoggerAwareInterface;
 use Psr\Log\LoggerAwareTrait;
 use TYPO3\CMS\Core\Context\Context;
+use TYPO3\CMS\Core\Context\TypoScriptAspect;
 use TYPO3\CMS\Core\Domain\Repository\PageRepository;
 use TYPO3\CMS\Core\Exception\SiteNotFoundException;
 use TYPO3\CMS\Core\Http\Uri;
@@ -403,11 +404,16 @@
                 ->withAttribute('site', $site)
                 ->withAttribute('siteLanguage', $site->getDefaultLanguage());
         }
+
+        // Set typoscript aspect with $forcedTemplateParsing (required for TypoScript setup initialization)
+        GeneralUtility::makeInstance(Context::class)
+            ->setAspect('typoscript', GeneralUtility::makeInstance(TypoScriptAspect::class, true));
+
         $controller = GeneralUtility::makeInstance(
             TypoScriptFrontendController::class,
             GeneralUtility::makeInstance(Context::class),
             $site,
-            $site->getDefaultLanguage(),
+            $originalRequest->getAttribute('language', $site->getDefaultLanguage()),
             new PageArguments($site->getRootPageId(), '0', []),
             $originalRequest->getAttribute('frontend.user')
         );
Actions

Also available in: Atom PDF