Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
RKlingler opened this issue Mar 4, 2025 · 2 comments
Open

Comments

@RKlingler
Copy link

RKlingler commented Mar 4, 2025

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
Copy link

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

@hannesbochmann
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants