Flow 8.1

This release of Flow comes with some great new features, bugfixes and a lot of modernisation of the existing code base.

As usual, we worked hard to keep this release as backwards compatible as possible but, since it’s a major release, some of the changes might require manual adjustments. So please make sure to carefully read the upgrade instructions below.

New Features

FEATURE: Add method askQuestion to console output that accepts a Question object

The other question methods take arrays or strings as arguments which is easy and convenient however the underlying symfony console offers more flexibility. This pr adds the method askQestion that accepts a smfony console question object and thus allows the full flexibility at the price of complexity.

In addition the method getQuestionHelper is made public to make this as accessible as the getProgressBar method.

Review instructions

I chose not to allow Question objects in the ask method because this method has a default argument that only makes sense when the question is passed as array or string.

FEATURE: typed env variable replacements in Settings

With this change, the type of environment variables can be specified in Configuration files:

`yaml someSetting: %env(int):SOME_ENVIRONMENT_VARIABLE%` `

This will cast the corresponding value to the specified type (and to the base value of the type when referring to undefined environment variables).

Supported types and their base value are:

  • int: 0

  • bool: false

  • float: 0.0

  • string: “” (empty string)

Related issue: #2872

FEATURE: Support object serialization without var annotation

This change introduces support for PHP 7.4 style class property type declarations for objects to be serialized by Flow. Previously, a @var annotation had to be specified for each class property, in order to communicate the type to Flow’s serialization mechanism.

Related issue: #2843

Upgrade Instructions

This section contains instructions for upgrading your Flow 8.0 based applications to Flow 8.1.

In general just make sure to run the following commands:

To clear all file caches:

./flow flow:cache:flush --force

If you have additional cache backends configured, make sure to flush them too.

To apply core migrations:

./flow flow:core:migrate <Package-Key>

For every package you have control over (see Upgrading existing code below).

To validate/fix the database encoding, apply pending migrations and to (re)publish file resources:

./flow database:setcharset
./flow doctrine:migrate
./flow resource:publish

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

Upgrading existing code

There have been major API changes in Flow 8.1 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 Acme.Demo

This will adjust the package code automatically and/or output further information. Read the output carefully and manually adjust the code if needed.

To see all the other helpful options this command provides, make sure to run:

./flow help core:migrate

Also make sure to read about the `Potentially breaking changes`_ below.

Inside core:migrate

The tool roughly works like this:

  • Collect all code migrations from packages

  • Collect all files from the specified package

  • For each migration

    • 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.