The commands in this reference are shown with their full command identifiers.
On your system you can use shorter identifiers, whose availability depends
on the commands available in total (to avoid overlap the shortest possible
identifier is determined during runtime).

To see the shortest possible identifiers on your system as well as further
commands that may be available, use:

./flowhelp

The following reference was automatically generated from code on 2016-07-28

The warm up caches command initializes and fills – as far as possible – all
registered caches to get a snappier response on the first following request.
Apart from caches, other parts of the application may hook into this command
and execute tasks which take further steps for preparing the app for the big
rush.

This will apply pending code migrations defined in packages to all
packages that do not yet have those migration applied.

For every migration that has been run, it will create a commit in
the package. This allows for easy inspection, rollback and use of
the fixed code.
If the affected package contains local changes or is not part of
a git repository, the migration will be skipped. With the –force
flag this behavior can be changed, but changes will only be committed
if the working copy was clean before applying the migration.

If set, execute only the migration with the given version (e.g. “20150119114100”)

--verbose

If set, notes and skipped migrations will be rendered

--force

By default packages that are not under version control or contain local changes are skipped. With this flag set changes are applied anyways (changes are not committed if there are local changes though)

The shell command runs Flow’s interactive shell. This shell allows for
entering commands like through the regular command line interface but
additionally supports autocompletion and a user-based command history.

Convert the database schema to use the given character set and collation (defaults to utf8mb4 and utf8mb4_unicode_ci).

This command can be used to convert the database configured in the Flow settings to the utf8mb4 character
set and the utf8mb4_unicode_ci collation (by default, a custom collation can be given). It will only
work when using the pdo_mysql driver.

Make a backup before using it, to be on the safe side. If you want to inspect the statements used
for conversion, you can use the $output parameter to write them into a file. This file can be used to do
the conversion manually.

The main purpose of this is to fix setups that were created with Flow 2.3.x or earlier and whose
database server did not have a default collation of utf8mb4_unicode_ci. In those cases, the tables will
have a collation that does not match the default collation of later Flow versions, potentially leading
to problems when creating foreign key constraints (among others, potentially).

If you have special needs regarding the charset and collation, you can override the defaults with
different ones. One thing this might be useful for is when switching to the utf8mb4mb4 character set, see:

Note: This command is not a general purpose conversion tool. It will specifically not fix cases
of actual utf8mb4 stored in latin1 columns. For this a conversion to BLOB followed by a conversion to the
proper type, charset and collation is needed instead.

If $diffAgainstCurrent is TRUE (the default), it generates a migration file
with the diff between current DB structure and the found mapping metadata.
Otherwise an empty migration skeleton is generated.

Only includes tables/sequences matching the $filterExpression regexp when
diffing models and existing schema. Include delimiters in the expression!
The use of

–filter-expression ‘/^acme_com/’

would only create a migration touching tables starting with “acme_com”.

Note: A filter-expression will overrule any filter configured through the
Neos.Flow.persistence.doctrine.migrations.ignoredTables setting

This function marks a package as frozen in order to improve performance
in a development context. While a package is frozen, any modification of files
within that package won’t be tracked and can lead to unexpected behavior.

File monitoring won’t consider the given package. Further more, reflection
data for classes contained in the package is cached persistently and loaded
directly on the first request after caches have been flushed. The precompiled
reflection data is stored in the Configuration directory of the
respective package.

By specifying all as a package key, all currently frozen packages are
frozen (the default).

Refreezes a currently frozen package: all precompiled information is removed
and file monitoring will consider the package exactly once, on the next
request. After that request, the package remains frozen again, just with the
updated data.

By specifying all as a package key, all currently frozen packages are
refrozen (the default).

This command checks the resource registry (that is the database tables) for orphaned resource objects which don’t
seem to have any corresponding data anymore (for example: the file in Data/Persistent/Resources has been deleted
without removing the related Resource object).

If the Neos.Media package is active, this command will also detect any assets referring to broken resources
and will remove the respective Asset object from the database when the broken resource is removed.

This command will ask you interactively what to do before deleting anything.

This command copies all resources from one collection to another storage identified by name.
The target storage must be empty and must not be identical to the current storage of the collection.

This command merely copies the binary data from one storage to another, it does not change the related
Resource objects in the database in any way. Since the Resource objects in the database refer to a
collection name, you can use this command for migrating from one storage to another my configuring
the new storage with the name of the old storage collection after the resources have been copied.

If the privilege target has parameters those can be specified separated by a colon
for example “parameter1:value1” “parameter2:value2”.
But be aware that this only works for parameters that have been specified in the policy

Generates Schema documentation (XSD) for your ViewHelpers, preparing the
file to be placed online and used by any XSD-aware editor.
After creating the XSD file, reference it in your IDE and import the namespace
in your Fluid template by adding the xmlns:* attribute(s):
<html xmlns=”http://www.w3.org/1999/xhtml” xmlns:f=”http://typo3.org/ns/Neos/Fluid/ViewHelpers” …>

Generates an Action Controller with the given name in the specified package.
In its default mode it will create just the controller containing a sample
indexAction.

By specifying the –generate-actions flag, this command will also create a
set of actions. If no model or repository exists which matches the
controller name (for example “CoffeeRepository” for “CoffeeController”),
an error will be shown.

Likewise the command exits with an error if the specified package does not
exist. By using the –generate-related flag, a missing package, model or
repository can be created alongside, avoiding such an error.

By specifying the –generate-templates flag, this command will also create
matching Fluid templates for the actions created. This option can only be
used in combination with –generate-actions.

The default behavior is to not overwrite any existing code. This can be
overridden by specifying the –force flag.

This command generates a new domain model class. The fields are specified as
a variable list of arguments with field name and type separated by a colon
(for example “title:string” “size:int” “type:MyType”).