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+

 

Archive

09/01 2017
09/11 2016
09/06 2016
21/12 2015
07/12 2015
25/11 2015
25/09 2015
22/09 2015
01/08 2015
10/03 2015
03/03 2015
12/02 2015
25/11 2014
01/11 2014
16/10 2014
02/10 2014
02/10 2014
19/09 2014
18/09 2014
05/09 2014
22/08 2014
02/08 2014
27/06 2014
06/06 2014
13/04 2014
27/03 2014
12/03 2014
11/03 2014
05/02 2014
25/01 2014
17/12 2013
08/12 2013
03/12 2013
04/11 2013
Flux 7.0 Teaser
06/08 2013
21/07 2013
10/06 2013
04/06 2013
01/06 2013
27/05 2013
19/05 2013
19/05 2013
11/05 2013
26/04 2013
30/03 2013
19/03 2013
17/03 2013
13/03 2013
10/03 2013
10/03 2013
05/03 2013
04/03 2013
03/03 2013
02/03 2013
01/03 2013
28/02 2013
27/02 2013
25/02 2013
24/02 2013
24/02 2013
23/02 2013
10/02 2013
03/02 2013
03/02 2013
27/01 2013
Asset management in Fluid
20/01 2013
16/01 2013
13/01 2013
08/01 2013
16/12 2012
25/11 2012
18/11 2012
08/11 2012
07/11 2012
05/11 2012
04/11 2012
28/10 2012
22/10 2012
14/10 2012
13/08 2012
08/08 2012
31/07 2012
30/07 2012
25/07 2012
29/04 2012
29/04 2012
22/04 2012
16/04 2012
21/03 2012
Flux 1.4.0 released
08/03 2012
Flux 1.3.0 released
04/03 2012
03/03 2012
28/02 2012
19/02 2012
A Sneaky Sneak Preview of the next version of Flux
13/02 2012
12/02 2012
06/02 2012
30/01 2012
27/01 2012
15/01 2012
26/12 2011
24/12 2011
11/12 2011
11/12 2011
10/12 2011
04/12 2011
04/12 2011
30/11 2011
26/11 2011
25/11 2011