Flow 6.2

This minor release of Flow brings a few bigger features and a lot of modernisation of the existing code base.

Upgrade Instructions

This section contains instructions for upgrading your Flow 6.1 based applications to Flow 6.2.

In general just make sure to run the following commands:

./flow flow:cache:flush --force
./flow flow:core:migrate
./flow database:setcharset
./flow doctrine:migrate
./flow resource:publish

If you are upgrading from a lower version than 6.1, be sure to read the upgrade instructions from the previous Release Notes first.

Upgrading your Packages

Upgrading existing code

There have been major API changes in Flow 6.0 which require your code to be adjusted. As with earlier changes to Flow that required code changes on the user side we provide a code migration tool.

Given you have a Flow system with your (outdated) package in place you should run the following before attempting to fix anything by hand:

./flow core:migrate --package-key Acme.Demo

The package key is optional, if left out it will work on all packages it finds (except for library packages and packages prefixed with “Neos.*”) - for the first run you might want to limit things a little to keep the overview, though.

Make sure to run:

./flow help core:migrate

to see all the other helpful options this command provides.

Also make sure to read the changes below.

Inside core:migrate

The tool roughly works like this:

  • Collect all code migrations from packages

  • Collect all files from all packages (except Framework and Libraries) or the package given with --package-key

  • For each migration and package

    • Check for clean git working copy (otherwise skip it)

    • Check if migration is needed (looks for Migration footers in commit messages)

    • Apply migration and commit the changes

Afterwards you probably get a list of warnings and notes from the migrations, check those to see if anything needs to be done manually.

Check the created commits and feel free to amend as needed, should things be missing or wrong. The only thing you must keep in place from the generated commits is the migration data in composer.json. It is used to detect if a migration has been applied already, so if you drop it, things might get out of hands in the future.

What has changed

FEATURE: Configurable UsernamePassword fields and UsernamePasswordTokeninterface

Allows to configure the argument names for username and password to make interoperability with other services easier. The new options can be set for a specific provider with the following configuration:

            provider: PersistedUsernamePasswordProvider
                usernamePostField: 'some.argument'
                passwordPostField: 'some.other.argument'

FEATURE: Array Debugger tolerates iterables

This change lets the debug-array-renderer use the pseudo type iterable (Array or Traversable) instead of array. That way all foreachachble objects are rendered as an array. This replaces the previous exceptions for ArrayObjects and DoctrineCollections and will also enable to properly debug other Traversable objects as well.

FEATURE: Improve 304 response handling

For responses that match the following conditions a 304 status is returned: - The request method is GET or HEAD. - The response status is 200 status. - The response has ETag header that matches one of the If-None-Match headers of the request.

!!! The generation of the Etag header is not part of this change and is the job of the application.

Other changes: - 304 responses now have an empty body - Only GET and HEAD Requests will receive 304 status based on ETag and Last-Modified headers

FEATURE: Virtual Object Configuration

The Flow Object Management has been built with the idea of virtual “object names”. But so far it was not possible to have an object configuration with a name that is not equal to the class name. With this feature it is possible to create configurations for “virtual objects” within the Objects.yaml:

# the colon ":" makes this a virtual object
  className: Psr\\Log\\LoggerInterface
  scope: singleton
  factoryObjectName: Neos\\Flow\\Log\\PsrLoggerFactoryInterface
  factoryMethodName: get
      value: systemLogger

  className: Psr\\Log\\LoggerInterface
  scope: singleton
  factoryObjectName: Neos\\Flow\\Log\\PsrLoggerFactoryInterface
  factoryMethodName: get
      value: securityLogger

..and to inject them:

* @Flow\\Inject(name="Some.Package:SystemLogger")
* @var LoggerInterface
protected $systemLogger;

* @Flow\\Inject(name="Some.Package:SecurityLogger")
* @var LoggerInterface
protected $securityLogger;

Or configure them in factories:


someLoggerClassName: ‘Some.Package:SystemLogger’

FEATURE: Add EEL Helper File.exists(filename)

The EEL helper determines if a file exists. This is eg helpful, if file like templates are generated, and should only be rendered, if the template file exists, for example for generated favicon templates like this:

prototype(Neos.Neos:Page) {
  head.favicons = Neos.Fusion:Template {
    resource = ${'resource://' + site.context.currentSite.siteResourcesPackageKey + '/Private/Templates/Page/Favicon.html'}
     templatePath = ${this.resource}
     @if.fileExists = ${File.exists(this.resource)}

FEATURE: Allow configuring static factory methods in Objects.yaml

This change allows to configure static factory methods in Objects.yaml by only specifying a factoryMethodName and leaving out factoryObjectName.


  factoryMethodName: Acme\\My\\Class::fromStatic
      setting: Acme.My.Class.ConfigurableValue

Before this would have required to create of a non-static factory method inside a dedicated factory class (to avoid cyclic instantiation).

FEATURE: Run garbage collection of configured caches

In order to run garbage collection the following command has been introduced

./flow cache:collectgarbage

which will iterator over all configured caches and run the corresponding collectGarbage method.

You can also run garbage collection on a single cache by definined the cache identifier

./flow cache:collectgarbage –cache-identifier Flow_Monitor

FEATURE: Resolve authentication token by simple name

The documentation has long been showing that you can define a security token by it’s simple name, if in the Neos.Flow package.

This has not been really true, since there was no resolving from the simple string, similar to how providers has been resolved.

This change brings the same resolving functionality as the provider.

FEATURE: Emit a signal when view is resolved

In order for a package to interact with the rendering views available variables a signal is being emitted upon resolving of the view.

The variables will be available in the view in the MVC context only