Information for developers about what to expect in Flux 7.2 in terms of new and deprecated features.
As usual, here is a small article about which changes and features you as a developer should expect in Flux 7.2 and how your projects can be improved when you use the new version.
Obviously, Flux 7.2 and associated extensions are compatible with TYPO3 CMS 7.x. As usual we make an effort to always support the most recently released TYPO3 version as well as the most recent LTS version.
We have removed support for the long deprecated legacy TypoScript registration methods which Flux has contained ever since the FED days. This means that:
Although this is not a change in Flux itself it is done to homogenise the template path setups that Flux consumes. The relevant commits are:
If you are upgrading a project that uses these legacy registrations and your templates already exist in a Provider Extension, migration is easy - simply switch to the new way of registering all your templates by extension key: https://fluidtypo3.org/documentation/templating-manual/templating/provider-extension/registration-in-php.html.
If the project is old enough that your templates are located in for example fileadmin, you need to create a Provider Extension and move your template files into it. Choose the same extension key for your Provider Extension as was the name of your collection in TypoScript so you don't have to migrate database records! To learn more about generating a Provider Extension, see <link https: fluidtypo3.org documentation templating-manual templating provider-extension generating-extensions.html>fluidtypo3.org/documentation/templating-manual/templating/provider-extension/generating-extensions.html.
One of the new features is a unified support for ways to configure template paths in TypoScript. Since TYPO3 CMS 6.2 the new templateRootPaths (note the "s") configuration options to define multiple paths have become available, but Flux until now had retained it's support for "overlays" configured like EXT:view.
The new change means that all of the following configuration methods are now supported transparently without a need for migration:
And of course the corresponding locations for partialRootPath(s) and layoutRootPath(s).
The new preferred way of defining template paths is to use the TYPO3 core's preferred way - which is the plugin.tx_myext.view.templateRootPaths way containing an array of paths, all of which are checked when Fluid tries to find a template file.
A new Flux field type has been added which (re-)introduces the support for creating the "group" TCEforms field type - which basically is a multi-value field that can contain references to not just multiple records, but multiple records from multiple tables.
The rendering type of this field is slightly different - most importantly, it includes the browse feature that opens a popup window with a page tree enabled browse component. Many users prefer this UX over the single relation field type which lacks this browse feature (but had a less capable alternative in the form of Wizards).
In short: if your UX goals would imply a "group" type field in TCA then you may want to try using flux:field.multiRelation in your Flux Form to get as close to that as possible.
We have replaced the way Flux generates previews when a Grid is involved. Before, Flux would render the Grid from the Fluid template file which means the template had to be parsed (or loaded from compiled cache) and then rendered, involving a significant amount of processing. The content element container areas are now rendered by a special View class, significantly increasing performance when working with multiple nested elements.
The new behaviour:
Basically, we sacrifice the rarely used template replacement feature for increased performance in very frequently executed code.
To make it easier to define options previously defined using <flux:form ... options="{}" /> we have added ViewHelpers that can be used as children of flux:form to define options:
<flux:form ...>
<flux:form.option name="icon" value="..." />
<flux:form.option name="group" value="MyElements" />
<flux:form.option name="preview" value="{mode: 'append'}" />
<flux:form.option name="Fluidcontent" value="{sorting: 123}" />
</flux:form>
And so on with all supported options. Although now a major new feature, it does allow you to avoid very large options arrays on flux:form - and it allows us and you to create dedicated ViewHelpers that define individual options.
Hint: any options, including custom ones that you yourself define, <link https: fluidtypo3.org documentation templating-manual advanced-provider-extensions custom-flux-controllers controller-actions.html>can be retrieved from a Flux-enabled controller's actions via the Provider associated with the controller. All thanks to the presence of $this->provider and the methods you can call on it.
Behind the slightly generic title lies a common problem: Flux supports placing parts of each Form in one or more Partial templates which can then be overridden by an integrator/developer to let her change the fields. However, when doing this, the original extension context is retained which means that any automatic labels for the form fields would be attempted fetched from the original extension instead of the one containing the Partial template.
To let you have complete control over that behavior, we have added (or rather, exposed - because it was already there) the extensionName property on every Form Component. Setting this property on a flux:form.field.* or flux:form.sheet or any other component causes Flux to look in that extension when generating automatic label references.
This has the additional impact that on flux:form.field.controllerActions, the argument formerly known as extensionName which defined the extension to look in when determining available controller actions, is now known as controllerExtensionName - and the old argument now behaves as described above.
Rather than requiring you to define the (optional) icon file that gets associated with each template and displayed in the new content wizard, page layout selectors etc., we have added a feature that lets you simply place the icon file at an expected location in your Provider Extension and Flux will then use that file as icon.
If for example your template file is located in EXT:myext/Resources/Private/Templates/Content/MyContent.html then the expected icon file location will be EXT:myext/Resources/Public/Icons/Content/MyContent.png (.gif extension also supported).
The icon that gets resolved is always resolved based on the extension context (note: the previous section is also relevant here!) and file subfolder. Basically, overriding a Flux template and giving it another extensionName to use as context, makes Flux look for the icon in that other extension instead.
If a convention-based icon file exists, Flux can avoid costly calls to retrieve the icon setting from within the template file thus further increasing the backend's performance in daily use.
Although this feature is still on the drawing board and cannot be described in detail, it's worth mentioning here. We are working on a way to let integrators override options and composition of Flux forms by using TypoScript - which will for example allow the integrator to use TypoScript to control which page/content template may be used, as well as selectively override settings like the sorting value of Fluidcontent elements or the allowed content types inside a Fluidpages-enabled page template's Grid.
Essentially, TypoScript overrides for Flux Forms which can be used as an alternative to overriding and changing the template file that contains the Flux Form definition. With the added benefit that these options can be overridden anywhere in the page tree - something which you until now had to manually support via the {settings} array and conditions in Fluid.
More information will follow about the TypoScript overrides as the feature gets built - stay tuned!
Kind regards,
The FluidTYPO3 Team