BUG: content.resources.fal returns an empty array in version 7.1.0

[RKlingler]

I have checked that the bug exists in the dev-development branch Yes

I have checked that there are no already open issues or recently closed issues about this bug Yes

Describe the bug {v:content.resources.fal(field: 'someImageField')} returns an empty array after upgrading to vhs 7.1.0. Up until version 7.0.7 it returned an array with all the image properties such as id, name, url, etc, which could be used to display the image.

To reproduce Steps to reproduce the behavior:

1. Create a flux template with the following field: <flux:field.inline.fal name="someImageField" label="Some Image" />
2. Put <f:debug>{v:content.resources.fal(field: 'someImageField')}</f:debug> in the frontend template part.
3. Create a new content element using the flux template and view it in the frontend.

Expected behavior f:debug should output an array of arrays with the image name, id etc. as it did before.

Additional context In the preview part of the template the ViewHelper still works as before. The difference is, that I'm adding a record parameter here, as described by the documentation: {v:content.resources.fal(field: 'someImageField', record: record)} In fact, if I do this in the frontend template part too, it works again. According to the documentation it should work without the record parameter.

Is this a bug introduced by 7.1.0? Or are we expected to now always provide the record parameter when using v:content.resources.fal?

[pointslab]

@RKlingler To provide the record parameter fixed this problem for us, too.

[hannesbochmann]

Maybe I can give some more information. I ran into the problem in a TYPO3 11.5 instance. The Problem seems to be that FluidTYPO3\Vhs\Utility\ContentObjectFetcher::resolve() (called in FluidTYPO3\Vhs\ViewHelpers\Resource\Record\AbstractRecordResourceViewHelper::getActiveRecord()) returns the cObj property of the TypoScriptFrontendController which in my case contains the current page data and not the current content element data. Therefore fetching the file reference fails.

Setting the record argument solves the problem for me, too.

[NamelessCoder]

The underlying cause is that content object data resolving has become very inconsistent since storing TSFE and cObj within the Request attributes, as well as delivering those objects through various other means (ConfigurationManager, etc.). Since these are now unpredictable, no consistent fix can be made in VHS and a workaround has to be used.

Long term, the capability of the FAL ViewHelpers will likely just be changed to require the record argument, thus removing any resolving logic. The workaround then becomes the required usage. Until such a time, use the record argument in every place you use one of the FAL ViewHelpers!

[RKlingler]

Okay, thank you for clarifying. I will then continue to add the record arguments every time I use the ViewHelper. You just have to know to do it, I guess. Are there any plans to include a hint to this behavior in the documentation? I think that would be helpful.