BUG: v:content.info must have contentUid argument outside tt_content context after Upgrade from 7.0.7 to 7.1.0

[eckonator]

Describe the bug User v:content.info in EXT:news list and detail view. With version 7.0.7 this works pretty fine. After upgrade to version 7.1.0 i got this error: v:content.info must have contentUid argument outside tt_content context

To Reproduce Steps to reproduce the behavior:

1. Upgrade 7.0.7 to 7.1.0
2. Use v:content.info in EXT:news templates:

<div class="news" id="c{v:content.info(field: 'uid')}">
	<f:render section="content" />
</div>

Perhaps also affected in normal content elements

4. See error message in frontend.

[ulrike-cosmoblonde]

I can confirm the error for version 7.1.0. A fix would be highly appreciated.

Thanks!

[ulrike-cosmoblonde]

Any news on this issue? For a TYPO3 v13 project the new version 7.1.0 has to be used. A downgrade to 7.0.7 is no option. The error still exists. Thank you!

[cstrizzolo]

I can confirm this issue also with version 7.1.1 on TYPO3 v12.

[ulrike-cosmoblonde]

This issue also exists on TYPO3 v13 projects where a downgrade to 7.0.7 is not possible. Would you please let me know if a bugfix can be expected soon.

[cstrizzolo]

The problem persists also in version 7.1.2 on TYPO3 v12

[JanStorm]

We also ran into this issue. TYPO3: 12.4.31 VHS: 7.1.3 PHP: 8.2.12

[sterborg]

How about adding the argument contentUid to the viewHelper call? In news list that would be {contentObjectData.uid}. In normal content elements it should not be an isssue as the error messages states "outside tt_content context". In custom extensions you can provide the tt_content.uid on your own.

[neufeind]

TL,DR: In my case providing "contentUid: data.uid" helped.

Briefly discussed the "internals" of this issue with Claus Due. Providing contentUid is the way to go since it avoids "magic", which under certain conditions didn't work "consistent" dependent of which context (rendering a page or an email) or whether in cached/uncached contexts etc.

[...] "So in order to make it predictable, the UID should be provided explicitly. In fact, that may be better altogether to remove the current magic resolving and always demand a record UID as argument. Usually, the ID would be available through {data.uid} if context is FSC, or {record.uid} if context is Flux. If context is a custom plugin you may need to assign the record or UID (assigning the record would be more efficient than depending on v:content.info if you already have a controller action available to edit)." [...]

[christophrunkel]

I also have this Issue in typo3 13.4.15 and VHs 7.1.3. In my case adding data.uid does not make sense, because i do not have access here. If i had i would not need this view helper at all.