Bug #82498
closed
getPagesTSconfigPreInclude signal must not alter pre cached PageTS
Added by Alexander Schnitzler over 6 years ago.
Updated over 3 years ago.
Description
https://review.typo3.org/#/c/30921/ introduced the getPagesTSconfigPreInclude signal, which made altering the PageTS possible before it's cached.
Despite many arguments against introducing that signal there, it has been merged anyway. As a result, getPagesTSconfig is not indempotent any more and can create compromised PageTS cache entries.
Also the use of signals in that part of the core feels plain wrong as we rely on a mechanism brought by Extbase rather than using regular hooks like throughout the rest of the core.
Possible solution:
Instead of modifying the PageTS before it get's cached, I'd place the signal after the caching, making the cache entries indempotent.
We need to have a look at who is using that signal in what way and if modifying it must be considered breaking.
- Related to Task #59703: Add hook to BackendUtility::getPagesTSconfig() added
- Related to Task #82497: Streamline \TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfig added
- Target version changed from 9.0 to 9.2
- Target version changed from 9.2 to Candidate for patchlevel
- Status changed from New to Needs Feedback
We moved this to a PSR-14 event, but also before it is cached.
The main idea behind all the use cases (EXT:themes etc) is to add PageTS depending on e.g. a site, which makes sense to have it cached as well.
We now have to separate classes doing two things:
- PageTsLoader()
- PageTsParser()
Having a parser and then add things to the parser makes quite some sense IMHO. But that would be a new hook, right? What would be the use case for adding dynamically parsed PageTS during runtime?
- Status changed from Needs Feedback to Closed
This is now solved differently, will close this issue now due to lack of feedback. In my opinion this is clearly streamlined.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by