Project

General

Profile

Actions

Bug #82498

closed

getPagesTSconfigPreInclude signal must not alter pre cached PageTS

Added by Alexander Schnitzler about 7 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend API
Start date:
2017-09-17
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.0
Tags:
Complexity:
Is Regression:
Sprint Focus:

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 issues 2 (0 open2 closed)

Related to TYPO3 Core - Task #59703: Add hook to BackendUtility::getPagesTSconfig()Closed2014-06-20

Actions
Related to TYPO3 Core - Task #82497: Streamline \TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfigClosedAlexander Schnitzler2017-09-17

Actions
Actions #1

Updated by Alexander Schnitzler about 7 years ago

  • Related to Task #59703: Add hook to BackendUtility::getPagesTSconfig() added
Actions #2

Updated by Alexander Schnitzler about 7 years ago

  • Related to Task #82497: Streamline \TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfig added
Actions #3

Updated by Susanne Moog almost 7 years ago

  • Target version changed from 9.0 to 9.2
Actions #4

Updated by Susanne Moog over 6 years ago

  • Target version changed from 9.2 to Candidate for patchlevel
Actions #5

Updated by Benni Mack over 4 years ago

  • 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?

Actions #6

Updated by Benni Mack about 4 years ago

  • 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.

Actions

Also available in: Atom PDF