09/01 2017
Flux 8.0.0 released

Features full workspaces support which was kindly sponsored by Chicago's Museum of Science and Industry. Check their site at http://www.msichicago.org/ - it too was built with FluidTYPO3.

Dear developers,

Before we start out the list of changes in Flux 8.0.0 I'd like to take a bit of time and space to throw a big THANK YOU to Chicago's Museum of Science and Industry who have sponsored an important piece of work for Flux - it is thanks to MSI that we can now proudly claim full workspaces compatibility. MSI needed workspaces support for their FluidTYPO3-based web site, http://www.msichicago.org/, and made the open source spirited decision to sponsor work on Flux compatibility.

What's new?

An automated full change list can be found at this permanent link: 

<link github.com/FluidTYPO3/flux/blob/development/Documentation/Changelog/8.0.0.md - external-link-new-window>https://github.com/FluidTYPO3/flux/blob/development/Documentation/Changelog/8.0.0.md</link>

But to name the most important changes:

  • Flux is now compatible with TYPO3 8.4+ which includes 8.5
  • Flux is now compatible with the workspaces system extension
  • We have dropped support for PHP below version 7.0 (also when installing on 7.6 LTS)
  • Some deprecated options and methods have been removed (see change log for details)
  • The Provider pattern has been significantly cleaned up; a cleanup which involves an interface change which is part of the reason why we needed to bump version to 8.0.0
  • Several important bug fixes have been made, among other things to improve performance and avoid issues with PHP7+

Two noteworthy changes should be mentioned here. First, the new Flux feature to allow a Fluid template file (containing a Flux form) to be registered directly for use as a new content type (with a custom CType value!). All this requires is:

  • A call in your provider extension's ext_localconf.php file to FluidTYPO3\Flux\Core::registerTemplateAsContentType with just two arguments: your provider extension's Vendor.ExtensionName formatted key and either an absolute, relative or EXT:-prefixed path to your template.
  • The presence of a ContentController in your provider extension (in the default location) which contains an action named according to your template file (e.g. if your template file name is MyTemplate.html then your controller must have a myTemplateAction method). 

The usual options for content such as icon, label, sorting etc. are all supported. Of course, nested content areas is equally supported just like you would use it in fluidcontent or fluidpages. With this feature, those creators who prefer custom CTypes instead of the shared Ctype of fluidcontent can create custom content element types completely without the need for fluidcontent. The controller class and methods may at some point become optional, but at the current time, it is a hard requirement.

It is possible that fluidcontent will at some point be replaced by this simpler feature - if and when that happens, a migration tool will be provided to let you kickstart a controller and register your old fluidcontent elements as new CTypes, using this new API.

Secondly, we have added support for using Flux Outlets (a part of the Form pattern) as a way to define actions which must be taken when submitting an f:form to a special "outlet" action. This feature makes it possible to define a complete mini-plugin as a collection of Fluid sections to render a form, an error or a success, and a series of Pipes that are attached to Flux Outlets. When the f:form is submitted, Flux accepts the input, validates it and passes the data through the Pipes you defined.

You can find an example template file which implements a tiny contact form with validation, error reporting, email sending and success view, kindly prepared by Marc Neuhaus, at <link gist.github.com/mneuhaus/9a8cff9f5b47ad8872eebae2808c54e7 - external-link-new-window>https://gist.github.com/mneuhaus/9a8cff9f5b47ad8872eebae2808c54e7</link>.

It is our hope that for the majority of simple use cases such as custom contact forms, this feature of Flux can be used as a reasonable replacement for creating a complete Extbase plugin. Controllers are supported, but not required - if you need special handling of the Request you can create a controller action to receive, but if you don't, the default controller will handle the Request using a default routine of validating and routing data through your Pipes.

Kind regards,
The FluidTYPO3 Team

PS: This release will be followed up shortly by new fluidcontent and fluidpages releases which will also be compatible with TYPO3 8.4+