Is details.registerProperties messing up the register stack?

[kitzberger]

Bug Report

I might be wrong here, but I believe that rendering the news detail view is interfering with TSFEs register stack.

Current Behavior

Using the TypoScript setting registerProperties (which is the default!) is putting properties of the currently rendered news record onto the register stack of TSFE, for later rendering to benefit from it.

This is possible because only LOAD_REGISTER is being rendered in EXT:news but no RESTORE_REGISTER afterwards.

Problem is that any RESTORE_REGISTER after the news plugin is removing the wrong array from the register stack! And that later RR is breaking the whole idea behind that feature anyway: a later data = register:newsTitle cannot be sure those news properties are still on the stack.

Expected behavior/output

The TSFE register stack is the same as it was before rendering the news detail plugin.

Environment

• TYPO3 version(s): 11
• news version: 11.4

Possible Solution

Rework that feature to work without messing with the register stack at all. Some sort of alternative "global" variables.

I do like the idea of not having to fetch the news records data manually again from the DB, but maybe there's a better way of making those infos available for later rendering?

[kitzberger]

In EXT:news there's several points that fetch the single views news record:

• NewsController->detailAction
• AddNewsToMenuProcessor (uses a querybuilder to fetch the record)

Instead of loading the same thing twice (or even more), how about this idea: we introduce a new middleware to load the single views news record and all other components (detailAction, AddNewsToMenuProcessor, TypoScript, etc.) can access that (once loaded) record without accessing the DB again.

[georgringer]

i tend more to remove all the TS register stuff (or do feature flags for it)? the middleware might sound nice in the beginning but I am not sure if it brings more troubles which are hard to debug.
what do you think?