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.
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.
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:
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:
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+