Feature #92742: Frontend-Event Feature Request - a new PSR-14 Event? - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Feature #92742

closed

Frontend-Event Feature Request - a new PSR-14 Event?

Added by Mati Sediqi about 4 years ago. Updated about 4 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Target version:

Start date:

2020-10-31

Due date:

% Done:

Estimated time:

PHP Version:

Tags:

Complexity:

easy

Sprint Focus:

Description

Hey there,

I was wondering why there's actually no frontend-event (PSR-14) actually?

Would like to avoid using any kind of middleware, since in my use case (which I'll explain right after this) there's actually no need to depend to a middleware, but more to an event, to listen when the frontend has been rendered (which would pass the output HTML code) and to do things to e.g. manipulate it - more likely the tsfe_lib-Hook for contentProc AFAIK.

So my use case is at the moment:
I started writing an independent HTML caching system, which serves static HTML files - checking their existence in the index.php.
I've added all there - and it works super fine. It'd be easier to cache the output HTML code now by listening on the (let's call it) "FrontendRenderedEvent", so it'd be possible to store that then (in my use case now) into a static file.

Another use-case would be maybe to filter-out cookie-depending HTML codes maybe - e.g. iframe-tags from 3rd-domains or any other kind of script-tags etc.

Would love to see something into that direction, as I guess it shouldn't be thaaat complex. :)

Greets,
Mati.

PS: I'm sorry if I break any rule, i'm kinda new here on forge and didn't know where rules are nor if I'm actually allowed to create an issue.

Actions

Copy link

Updated by Benni Mack about 4 years ago

Status changed from New to Needs Feedback

Hey Mati,

thanks for your feedback. And yes, this is the right place to ask such questions!

PSR-15 middlewares have been introduced in TYPO3 v9 in order to migrate away from hooks to a new system that allows to modify request + response at any given time, as you expect.

PSR-14 events have been introduced in TYPO3 v10 to slowly move away from hooks and especially SignalSlots (from Extbase) into a unified and interchange-able way across PHP frameworks and projects.

There are still a lot of hooks in TYPO3, mostly because we don't replace them "because we can" but adding new ways to modify the core behavior should be done through PSR-14 or PSR-15. PSR-15 allows to create a middleware (= and extend TYPO3's behavior) explicitly at a frontend request / response for the reason you mention. Why? Because you can avoid a lot of code execution if you don't need to. This is the right spot, and you are free to place your custom code before or after any middleware.

Hooks + PSR-14 are used across the whole system (PSR-14 more and more in favor hooks), also e.g. in the persistence layer, whereas PSR-15 can modify a request or response only.

However, adding a PSR-14 event into a PSR-15 middleware provided by TYPO3 Core actually does the opposite of giving the user more flexibility. We actually had this issue when introducing new hooks: For some people it's just one step to early / late to do their custom implementation. With middlewares, the choice is yours, and especially if you want to switch to static caching, you can choose the place where you "want to hook into" yourself.

If you want to hook into the moment once the fully created page is stored in cache, the hook you mentioned is totally fine. and "hooking into the frontend rendering" concept via a middleware is totally legit and takes less code than registering a PSR-14 event IMHO.

Does that answer your question?

Actions

Copy link