0
votes

I have been using FluidTYPO3 (flux and vhs) to run TYPO3 web pages for many years now. With TYPO3 10, I face a major problem. I'll quickly write about my use case, how I solved it so far, and then what the problem with 10 LTS is.

Use case:
I want to have a content element template for a timeline using FluidTYPO3/flux. Each "point" on the timeline should have a heading, some text, and optionally some images. All in all, pretty basic (or so I thought).

Solution so far (TYPO3 <= 9):
Timeline elements are sections. Images are using flux:field.file.

Simplified example of the form:

    <flux:form id="timeline" label="timeline">
        <flux:form.section name="timeline" label="Timeline">
            <flux:form.object name="element" label="Element">
                <flux:field.input name="title" label="Heading" />
                <flux:field.text name="label" label="Text" enableRichText="TRUE" />
                <flux:field.file name="images" label="Pictures" allowed="jpg,png,svg" multiple="TRUE" maxItems="50" size="5" showThumbnails="TRUE"
                />
            </flux:form.object>
        </flux:form.section>
    </flux:form>

With this, multiple elements can be created on the timeline and each of them can have its own set of images.

Problem in TYPO3 10:
The technology (TCA group fields to select files) that flux:field.file relies on was deprecated in TYPO3 9 and removed in TYPO3 10, see this notice. That is one of the reasons why flux:field.file was also marked deprecated and is going to be removed in TYPO3 10.

The TYPO3 deprecation notice says to use FAL relations instead. Of course, flux can also do this with flux:field.inline.fal. However, you can only have one FAL field per FlexForm. This precludes its usage in sections, since all sections would share the same images. This limitation is known for some time - see this bug report for example - but has never been fixed. It is also why I initially chose not to use FAL fields. Using bare file fields was the recommended workaround at the time.

Question:

So - how is everyone doing it? How to add multiple image fields to a flexform in TYPO3 10? EDIT: More specifically, how to add an image field as part of a Flexform section that can contain multiple child records (resulting in multiple image fields)?

Note: I know that I can get a "file-like" field back by using an input field with inputLink renderType (like this), but as far as I can tell it does not allow to link multiple images.

3

3 Answers

0
votes

It seems the only workaround with TYPO3 core onboard methods is to go for a Flux-Container having a single column containing simple default "Text with image" or "text with media" elements and then to just ignore additional options of those elements and to just render the necessary fields.

With Gridelements this is called a "functional container", since the container determines the behaviour and appearance of those elements, while the elements themselves don't have to be custom elements at all.

Additionally this makes access to the content of those elements - i.e. while doing a search query - much easier.

1
votes

I've found another workaround that might be appropriate for some use cases:

It is still possible to use flux:field.file fields if the useFalRelation parameter set to true, even on TYPO3 v10 LTS and in repeatable FlexForm sections. This will then put sys_file record IDs separated by comma into the field instead of raw filenames. They can be used as src argument for, e.g., f:image just as well as the filename, so the CE templates itself do not have to be modified. All existing CEs that had useFalRelation set to false need to be migrated though so that the filenames are replaced with sys_file UIDs.

This is a bit better than the inputLink workaround since it allows multiple images.

0
votes

The bug report you mentioned already contains the solutions, since the actual problem described there is that FAL fields in a flexform are using the same name.

So instead of

image

according to the bug report there should be

settings.foreground.image

which is of course not working, since the dot is part of the path but not of the name. But actually replacing the dot with an underscore and using some suffixes within the same flexform tab should do the trick:

settings.foreground.settings_foreground_image
settings.foreground.settings_foreground_image2

This way you make sure that

  1. The field names within your flexform are unique
  2. The actual field name within the sys_file_reference entry already contains the full path information
  3. You can use that information to fetch images i.e. within a DataProcessor and still know the FlexForm field they actually belong to

Sitll I would recommend to fully move away form FlexForms (and thus Flux too) in favor of "real" fields in the database table.