Tasks

The symfony framework comes bundled with a command line interface tool. Built-in tasks allow the developer to perform a lot of fastidious and recurrent tasks in the life of a project.

If you execute the symfony CLI without any arguments, a list of available tasks is displayed:

$ php symfony

By passing the -V option, you get some information about the version of symfony and the path of the symfony libraries used by the CLI:

$ php symfony -V

The CLI tool takes a task name as its first argument:

$ php symfony list

A task name can be composed of an optional namespace and a name, separated by a colon (:):

$ php symfony cache:clear

After the task name, arguments and options can be passed:

$ php symfony cache:clear --type=template

The CLI tool supports both long options and short ones, with or without values.

The -t option is a global option to ask any task to output more debugging information.

Available Tasks

• Global tasks
  • help
  • list
• app
  • app::routes
• cache
  • cache::clear
• configure
  • configure::author
  • configure::database
• doctrine
  • doctrine::build
  • doctrine::build-db
  • doctrine::build-filters
  • doctrine::build-forms
  • doctrine::build-model
  • doctrine::build-schema
  • doctrine::build-sql
  • doctrine::clean-model-files
  • doctrine::create-model-tables
  • doctrine::data-dump
  • doctrine::data-load
  • doctrine::delete-model-files
  • doctrine::dql
  • doctrine::drop-db
  • doctrine::generate-admin
  • doctrine::generate-migration
  • doctrine::generate-migrations-db
  • doctrine::generate-migrations-diff
  • doctrine::generate-migrations-models
  • doctrine::generate-module
  • doctrine::generate-module-for-route
  • doctrine::insert-sql
  • doctrine::migrate
• generate
  • generate::app
  • generate::module
  • generate::project
  • generate::task
• i18n
  • i18n::extract
  • i18n::find
• log
  • log::clear
  • log::rotate
• plugin
  • plugin::add-channel
  • plugin::install
  • plugin::list
  • plugin::publish-assets
  • plugin::uninstall
  • plugin::upgrade
• project
  • project::clear-controllers
  • project::deploy
  • project::disable
  • project::enable
  • project::optimize
  • project::permissions
  • project::send-emails
  • project::validate
• propel
  • propel::build
  • propel::build-all
  • propel::build-all-load
  • propel::build-filters
  • propel::build-forms
  • propel::build-model
  • propel::build-schema
  • propel::build-sql
  • propel::data-dump
  • propel::data-load
  • propel::generate-admin
  • propel::generate-module
  • propel::generate-module-for-route
  • propel::graphviz
  • propel::insert-sql
  • propel::schema-to-xml
  • propel::schema-to-yml
• symfony
  • symfony::test
• test
  • test::all
  • test::coverage
  • test::functional
  • test::unit

help

The help task displays help for a task:

$ php symfony help [--xml] [task_name]

The help task displays help for a given task:

./symfony help test:all

You can also output the help as XML by using the --xml option:

./symfony help test:all --xml

list

The list task lists tasks:

$ php symfony list [--xml] [namespace]

The list task lists all tasks:

./symfony list

You can also display the tasks for a specific namespace:

./symfony list test

You can also output the information as XML by using the --xml option:

./symfony list --xml

app

app::routes

The app::routes task displays current routes for an application:

$ php symfony app:routes  application [name]

The app:routes displays the current routes for a given application:

./symfony app:routes frontend

cache

cache::clear

The cache::clear task clears the cache:

$ php symfony cache:clear [--app[="..."]] [--env[="..."]] [--type[="..."]] 

Alias(es): cc

The cache:clear task clears the symfony cache.

By default, it removes the cache for all available types, all applications, and all environments.

You can restrict by type, application, or environment:

For example, to clear the frontend application cache:

./symfony cache:clear --app=frontend

To clear the cache for the prod environment for the frontend application:

./symfony cache:clear --app=frontend --env=prod

To clear the cache for all prod environments:

./symfony cache:clear --env=prod

To clear the config cache for all prod environments:

./symfony cache:clear --type=config --env=prod

The built-in types are: config, i18n, routing, module and template.

configure

configure::author

The configure::author task configure project author:

$ php symfony configure:author  author

The configure:author task configures the author for a project:

./symfony configure:author "Fabien Potencier <fabien.potencier@symfony-project.com>"

The author is used by the generates to pre-configure the PHPDoc header for each generated file.

The value is stored in [config/properties.ini].

configure::database

The configure::database task configure database DSN:

$ php symfony configure:database [--env[="..."]] [--name[="..."]] [--class[="..."]] [--app[="..."]] dsn [username] [password]

The configure:database task configures the database DSN for a project:

./symfony configure:database mysql:host=localhost;dbname=example root mYsEcret

By default, the task change the configuration for all environment. If you want to change the dsn for a specific environment, use the env option:

./symfony configure:database --env=dev mysql:host=localhost;dbname=example_dev root mYsEcret

To change the configuration for a specific application, use the app option:

./symfony configure:database --app=frontend mysql:host=localhost;dbname=example root mYsEcret

You can also specify the connection name and the database class name:

./symfony configure:database --name=main --class=ProjectDatabase mysql:host=localhost;dbname=example root mYsEcret

WARNING: The propel.ini file is also updated when you use a Propel database and configure for all environments with no app.

doctrine

doctrine::build

The doctrine::build task generate code based on your schema:

$ php symfony doctrine:build [--application[="..."]] [--env="..."] [--no-confirmation] [--all] [--all-classes] [--model] [--forms] [--filters] [--sql] [--db] [--and-migrate] [--and-load[="..."]] [--and-append[="..."]] 

The doctrine:build task generates code based on your schema:

./symfony doctrine:build

You must specify what you would like built. For instance, if you want model and form classes built use the --model and --forms options:

./symfony doctrine:build --model --forms

You can use the --all shortcut option if you would like all classes and SQL files generated and the database rebuilt:

./symfony doctrine:build --all

This is equivalent to running the following tasks:

./symfony doctrine:drop-db
./symfony doctrine:build-db
./symfony doctrine:build-model
./symfony doctrine:build-forms
./symfony doctrine:build-filters
./symfony doctrine:build-sql
./symfony doctrine:insert-sql

You can also generate only class files by using the --all-classes shortcut option. When this option is used alone, the database will not be modified.

./symfony doctrine:build --all-classes

The --and-migrate option will run any pending migrations once the builds are complete:

./symfony doctrine:build --db --and-migrate

The --and-load option will load data from the project and plugin data/fixtures/ directories:

./symfony doctrine:build --db --and-migrate --and-load

To specify what fixtures are loaded, add a parameter to the --and-load option:

./symfony doctrine:build --all --and-load="data/fixtures/dev/"

To append fixture data without erasing any records from the database, include the --and-append option:

./symfony doctrine:build --all --and-append

doctrine::build-db

The doctrine::build-db task creates database for current model:

$ php symfony doctrine:build-db [--application[="..."]] [--env="..."] [database1] ... [databaseN]

Alias(es): doctrine:create-db

The doctrine:build-db task creates one or more databases based on configuration in config/databases.yml:

./symfony doctrine:build-db

You can specify what databases to create by providing their names:

./symfony doctrine:build-db slave1 slave2

doctrine::build-filters

The doctrine::build-filters task creates filter form classes for the current model:

$ php symfony doctrine:build-filters [--application[="..."]] [--env="..."] [--model-dir-name="..."] [--filter-dir-name="..."] [--generator-class="..."] 

The doctrine:build-filters task creates form filter classes from the schema:

./symfony doctrine:build-filters

This task creates form filter classes based on the model. The classes are created in lib/doctrine/filter.

This task never overrides custom classes in lib/doctrine/filter. It only replaces base classes generated in lib/doctrine/filter/base.

doctrine::build-forms

The doctrine::build-forms task creates form classes for the current model:

$ php symfony doctrine:build-forms [--application[="..."]] [--env="..."] [--model-dir-name="..."] [--form-dir-name="..."] [--generator-class="..."] 

The doctrine:build-forms task creates form classes from the schema:

./symfony doctrine:build-forms

This task creates form classes based on the model. The classes are created in lib/doctrine/form.

This task never overrides custom classes in lib/doctrine/form. It only replaces base classes generated in lib/doctrine/form/base.

doctrine::build-model

The doctrine::build-model task creates classes for the current model:

$ php symfony doctrine:build-model [--application[="..."]] [--env="..."] 

The doctrine:build-model task creates model classes from the schema:

./symfony doctrine:build-model

The task read the schema information in config/doctrine/*.yml from the project and all enabled plugins.

The model classes files are created in lib/model/doctrine.

This task never overrides custom classes in lib/model/doctrine. It only replaces files in lib/model/doctrine/base.

doctrine::build-schema

The doctrine::build-schema task creates a schema from an existing database:

$ php symfony doctrine:build-schema [--application[="..."]] [--env="..."] 

The doctrine:build-schema task introspects a database to create a schema:

./symfony doctrine:build-schema

The task creates a yml file in config/doctrine

doctrine::build-sql

The doctrine::build-sql task creates SQL for the current model:

$ php symfony doctrine:build-sql [--application[="..."]] [--env="..."] 

The doctrine:build-sql task creates SQL statements for table creation:

./symfony doctrine:build-sql

The generated SQL is optimized for the database configured in config/databases.yml:

doctrine.database = mysql

doctrine::clean-model-files

The doctrine::clean-model-files task delete all generated model classes for models which no longer exist in your YAML schema:

$ php symfony doctrine:clean-model-files [--no-confirmation] 

Alias(es): doctrine:clean

The doctrine:clean-model-files task deletes model classes that are not represented in project or plugin schema.yml files:

./symfony doctrine:clean-model-files

doctrine::create-model-tables

The doctrine::create-model-tables task drop and recreate tables for specified models.:

$ php symfony doctrine:create-model-tables [--application[="..."]] [--env="..."] [models1] ... [modelsN]

The doctrine:create-model-tables Drop and recreate tables for specified models:

./symfony doctrine:create-model-tables User

doctrine::data-dump

The doctrine::data-dump task dumps data to the fixtures directory:

$ php symfony doctrine:data-dump [--application[="..."]] [--env="..."] [target]

The doctrine:data-dump task dumps database data:

./symfony doctrine:data-dump

The task dumps the database data in data/fixtures/%target%.

The dump file is in the YML format and can be reimported by using the doctrine:data-load task.

./symfony doctrine:data-load

doctrine::data-load

The doctrine::data-load task loads YAML fixture data:

$ php symfony doctrine:data-load [--application[="..."]] [--env="..."] [--append] [dir_or_file1] ... [dir_or_fileN]

The doctrine:data-load task loads data fixtures into the database:

./symfony doctrine:data-load

The task loads data from all the files found in data/fixtures/.

If you want to load data from specific files or directories, you can append them as arguments:

./symfony doctrine:data-load data/fixtures/dev data/fixtures/users.yml

If you don't want the task to remove existing data in the database, use the --append option:

./symfony doctrine:data-load --append

doctrine::delete-model-files

The doctrine::delete-model-files task delete all the related auto generated files for a given model name.:

$ php symfony doctrine:delete-model-files [--no-confirmation] name1 ... [nameN]

The doctrine:delete-model-files task deletes all files associated with certain models:

./symfony doctrine:delete-model-files Article Author

doctrine::dql

The doctrine::dql task execute a DQL query and view the results:

$ php symfony doctrine:dql [--application[="..."]] [--env="..."] [--show-sql] [--table] dql_query [parameter1] ... [parameterN]

The doctrine:dql task executes a DQL query and displays the formatted results:

./symfony doctrine:dql "FROM User"

You can show the SQL that would be executed by using the --show-sql option:

./symfony doctrine:dql --show-sql "FROM User"

Provide query parameters as additional arguments:

./symfony doctrine:dql "FROM User WHERE email LIKE ?" "%symfony-project.com"

doctrine::drop-db

The doctrine::drop-db task drops database for current model:

$ php symfony doctrine:drop-db [--application[="..."]] [--env="..."] [--no-confirmation] [database1] ... [databaseN]

The doctrine:drop-db task drops one or more databases based on configuration in config/databases.yml:

./symfony doctrine:drop-db

You will be prompted for confirmation before any databases are dropped unless you provide the --no-confirmation option:

./symfony doctrine:drop-db --no-confirmation

You can specify what databases to drop by providing their names:

./symfony doctrine:drop-db slave1 slave2

doctrine::generate-admin

The doctrine::generate-admin task generates a Doctrine admin module:

$ php symfony doctrine:generate-admin [--module="..."] [--theme="..."] [--singular="..."] [--plural="..."] [--env="..."] [--actions-base-class="..."] application route_or_model

The doctrine:generate-admin task generates a Doctrine admin module:

./symfony doctrine:generate-admin frontend Article

The task creates a module in the %frontend% application for the %Article% model.

The task creates a route for you in the application routing.yml.

You can also generate a Doctrine admin module by passing a route name:

./symfony doctrine:generate-admin frontend article

The task creates a module in the %frontend% application for the %article% route definition found in routing.yml.

For the filters and batch actions to work properly, you need to add the with_wildcard_routes option to the route:

article:
  class: sfDoctrineRouteCollection
  options:
    model:                Article
    with_wildcard_routes: true

doctrine::generate-migration

The doctrine::generate-migration task generate migration class:

$ php symfony doctrine:generate-migration [--application[="..."]] [--env="..."] [--editor-cmd="..."] name

The doctrine:generate-migration task generates migration template

./symfony doctrine:generate-migration AddUserEmailColumn

You can provide an --editor-cmd option to open the new migration class in your editor of choice upon creation:

./symfony doctrine:generate-migration AddUserEmailColumn --editor-cmd=mate

doctrine::generate-migrations-db

The doctrine::generate-migrations-db task generate migration classes from existing database connections:

$ php symfony doctrine:generate-migrations-db [--application[="..."]] [--env="..."] 

The doctrine:generate-migrations-db task generates migration classes from existing database connections:

./symfony doctrine:generate-migrations-db

doctrine::generate-migrations-diff

The doctrine::generate-migrations-diff task generate migration classes by producing a diff between your old and new schema.:

$ php symfony doctrine:generate-migrations-diff [--application[="..."]] [--env="..."] 

The doctrine:generate-migrations-diff task generates migration classes by producing a diff between your old and new schema.

./symfony doctrine:generate-migrations-diff

doctrine::generate-migrations-models

The doctrine::generate-migrations-models task generate migration classes from an existing set of models:

$ php symfony doctrine:generate-migrations-models [--application[="..."]] [--env="..."] 

The doctrine:generate-migrations-models task generates migration classes from an existing set of models:

./symfony doctrine:generate-migrations-models

doctrine::generate-module

The doctrine::generate-module task generates a Doctrine module:

$ php symfony doctrine:generate-module [--theme="..."] [--generate-in-cache] [--non-verbose-templates] [--with-show] [--singular="..."] [--plural="..."] [--route-prefix="..."] [--with-doctrine-route] [--env="..."] [--actions-base-class="..."] application module model

The doctrine:generate-module task generates a Doctrine module:

./symfony doctrine:generate-module frontend article Article

The task creates a %module% module in the %application% application for the model class %model%.

You can also create an empty module that inherits its actions and templates from a runtime generated module in %sf_app_cache_dir%/modules/auto%module% by using the --generate-in-cache option:

./symfony doctrine:generate-module --generate-in-cache frontend article Article

The generator can use a customized theme by using the --theme option:

./symfony doctrine:generate-module --theme="custom" frontend article Article

This way, you can create your very own module generator with your own conventions.

You can also change the default actions base class (default to sfActions) of the generated modules:

./symfony doctrine:generate-module --actions-base-class="ProjectActions" frontend article Article

doctrine::generate-module-for-route

The doctrine::generate-module-for-route task generates a Doctrine module for a route definition:

$ php symfony doctrine:generate-module-for-route [--theme="..."] [--non-verbose-templates] [--singular="..."] [--plural="..."] [--env="..."] [--actions-base-class="..."] application route

The doctrine:generate-module-for-route task generates a Doctrine module for a route definition:

./symfony doctrine:generate-module-for-route frontend article

The task creates a module in the %frontend% application for the %article% route definition found in routing.yml.

doctrine::insert-sql

The doctrine::insert-sql task inserts SQL for current model:

$ php symfony doctrine:insert-sql [--application[="..."]] [--env="..."] 

The doctrine:insert-sql task creates database tables:

./symfony doctrine:insert-sql

The task connects to the database and creates tables for all the lib/model/doctrine/*.class.php files.

doctrine::migrate

The doctrine::migrate task migrates database to current/specified version:

$ php symfony doctrine:migrate [--application[="..."]] [--env="..."] [--up] [--down] [--dry-run] [version]

The doctrine:migrate task migrates the database:

./symfony doctrine:migrate

Provide a version argument to migrate to a specific version:

./symfony doctrine:migrate 10

To migration up or down one migration, use the --up or --down options:

./symfony doctrine:migrate --down

If your database supports rolling back DDL statements, you can run migrations in dry-run mode using the --dry-run option:

./symfony doctrine:migrate --dry-run

generate

generate::app

The generate::app task generates a new application:

$ php symfony generate:app [--escaping-strategy="..."] [--csrf-secret="..."] app

The generate:app task creates the basic directory structure for a new application in the current project:

./symfony generate:app frontend

This task also creates two front controller scripts in the web/ directory:

web/%application%.php     for the production environment
web/%application%_dev.php for the development environment

For the first application, the production environment script is named index.php.

If an application with the same name already exists, it throws a sfCommandException.

By default, the output escaping is enabled (to prevent XSS), and a random secret is also generated to prevent CSRF.

You can disable output escaping by using the escaping-strategy option:

./symfony generate:app frontend --escaping-strategy=false

You can enable session token in forms (to prevent CSRF) by defining a secret with the csrf-secret option:

./symfony generate:app frontend --csrf-secret=UniqueSecret

You can customize the default skeleton used by the task by creating a %sf_data_dir%/skeleton/app directory.

generate::module

The generate::module task generates a new module:

$ php symfony generate:module  application module

The generate:module task creates the basic directory structure for a new module in an existing application:

./symfony generate:module frontend article

The task can also change the author name found in the actions.class.php if you have configure it in config/properties.ini:

name=blog
  author=Fabien Potencier <fabien.potencier@sensio.com>

You can customize the default skeleton used by the task by creating a %sf_data_dir%/skeleton/module directory.

The task also creates a functional test stub named %sf_test_dir%/functional/%application%/%module%ActionsTest.class.php that does not pass by default.

If a module with the same name already exists in the application, it throws a sfCommandException.

generate::project

The generate::project task generates a new project:

$ php symfony generate:project [--orm="..."] [--installer="..."] name [author]

The generate:project task creates the basic directory structure for a new project in the current directory:

./symfony generate:project blog

If the current directory already contains a symfony project, it throws a sfCommandException.

By default, the task configures Doctrine as the ORM. If you want to use Propel, use the --orm option:

./symfony generate:project blog --orm=Propel

If you don't want to use an ORM, pass none to --orm option:

./symfony generate:project blog --orm=none

You can also pass the --installer option to further customize the project:

./symfony generate:project blog --installer=./installer.php

You can optionally include a second author argument to specify what name to use as author when symfony generates new classes:

./symfony generate:project blog "Jack Doe"

generate::task

The generate::task task creates a skeleton class for a new task:

$ php symfony generate:task [--dir="..."] [--use-database="..."] [--brief-description="..."] task_name

The generate:task creates a new sfTask class based on the name passed as argument:

./symfony generate:task namespace:name

The namespaceNameTask.class.php skeleton task is created under the lib/task/ directory. Note that the namespace is optional.

If you want to create the file in another directory (relative to the project root folder), pass it in the --dir option. This directory will be created if it does not already exist.

./symfony generate:task namespace:name --dir=plugins/myPlugin/lib/task

If you want the task to default to a connection other than doctrine, provide the name of this connection with the --use-database option:

./symfony generate:task namespace:name --use-database=main

The --use-database option can also be used to disable database initialization in the generated task:

./symfony generate:task namespace:name --use-database=false

You can also specify a description:

./symfony generate:task namespace:name --brief-description="Does interesting things"

i18n

i18n::extract

The i18n::extract task extracts i18n strings from php files:

$ php symfony i18n:extract [--display-new] [--display-old] [--auto-save] [--auto-delete] application culture

The i18n:extract task extracts i18n strings from your project files for the given application and target culture:

./symfony i18n:extract frontend fr

By default, the task only displays the number of new and old strings it found in the current project.

If you want to display the new strings, use the --display-new option:

./symfony i18n:extract --display-new frontend fr

To save them in the i18n message catalogue, use the --auto-save option:

./symfony i18n:extract --auto-save frontend fr

If you want to display strings that are present in the i18n messages catalogue but are not found in the application, use the --display-old option:

./symfony i18n:extract --display-old frontend fr

To automatically delete old strings, use the --auto-delete but be careful, especially if you have translations for plugins as they will appear as old strings but they are not:

./symfony i18n:extract --auto-delete frontend fr

i18n::find

The i18n::find task finds non "i18n ready" strings in an application:

$ php symfony i18n:find [--env="..."] application

The i18n:find task finds non internationalized strings embedded in templates:

./symfony i18n:find frontend

This task is able to find non internationalized strings in pure HTML and in PHP code:

<p>Non i18n text</p>
<p><?php echo 'Test' ?></p>

As the task returns all strings embedded in PHP, you can have some false positive (especially if you use the string syntax for helper arguments).

log

log::clear

The log::clear task clears log files:

$ php symfony log:clear  

The log:clear task clears all symfony log files:

./symfony log:clear

log::rotate

The log::rotate task rotates an application's log files:

$ php symfony log:rotate [--history="..."] [--period="..."] application env

The log:rotate task rotates application log files for a given environment:

./symfony log:rotate frontend dev

You can specify a period or a history option:

./symfony log:rotate frontend dev --history=10 --period=7

plugin

plugin::add-channel

The plugin::add-channel task add a new PEAR channel:

$ php symfony plugin:add-channel  name

The plugin:add-channel task adds a new PEAR channel:

./symfony plugin:add-channel symfony.plugins.pear.example.com

plugin::install

The plugin::install task installs a plugin:

$ php symfony plugin:install [-s|--stability="..."] [-r|--release="..."] [-c|--channel="..."] [-d|--install_deps] [--force-license] name

The plugin:install task installs a plugin:

./symfony plugin:install sfGuardPlugin

By default, it installs the latest stable release.

If you want to install a plugin that is not stable yet, use the stability option:

./symfony plugin:install --stability=beta sfGuardPlugin
./symfony plugin:install -s beta sfGuardPlugin

You can also force the installation of a specific version:

./symfony plugin:install --release=1.0.0 sfGuardPlugin
./symfony plugin:install -r 1.0.0 sfGuardPlugin

To force installation of all required dependencies, use the install_deps flag:

./symfony plugin:install --install-deps sfGuardPlugin
./symfony plugin:install -d sfGuardPlugin

By default, the PEAR channel used is symfony-plugins (plugins.symfony-project.org).

You can specify another channel with the channel option:

./symfony plugin:install --channel=mypearchannel sfGuardPlugin
./symfony plugin:install -c mypearchannel sfGuardPlugin

You can also install PEAR packages hosted on a website:

./symfony plugin:install http://somewhere.example.com/sfGuardPlugin-1.0.0.tgz

Or local PEAR packages:

./symfony plugin:install /home/fabien/plugins/sfGuardPlugin-1.0.0.tgz

If the plugin contains some web content (images, stylesheets or javascripts), the task creates a %name% symbolic link for those assets under web/. On Windows, the task copy all the files to the web/%name% directory.

plugin::list

The plugin::list task lists installed plugins:

$ php symfony plugin:list  

The plugin:list task lists all installed plugins:

./symfony plugin:list

It also gives the channel and version for each plugin.

plugin::publish-assets

The plugin::publish-assets task publishes web assets for all plugins:

$ php symfony plugin:publish-assets [--core-only] [plugins1] ... [pluginsN]

The plugin:publish-assets task will publish web assets from all plugins.

./symfony plugin:publish-assets

In fact this will send the plugin.post_install event to each plugin.

You can specify which plugin or plugins should install their assets by passing those plugins' names as arguments:

./symfony plugin:publish-assets sfDoctrinePlugin

plugin::uninstall

The plugin::uninstall task uninstalls a plugin:

$ php symfony plugin:uninstall [-c|--channel="..."] [-d|--install_deps] name

The plugin:uninstall task uninstalls a plugin:

./symfony plugin:uninstall sfGuardPlugin

The default channel is symfony.

You can also uninstall a plugin which has a different channel:

./symfony plugin:uninstall --channel=mypearchannel sfGuardPlugin

./symfony plugin:uninstall -c mypearchannel sfGuardPlugin

Or you can use the channel/package notation:

./symfony plugin:uninstall mypearchannel/sfGuardPlugin

You can get the PEAR channel name of a plugin by launching the plugin:list task.

If the plugin contains some web content (images, stylesheets or javascripts), the task also removes the web/%name% symbolic link (on *nix) or directory (on Windows).

plugin::upgrade

The plugin::upgrade task upgrades a plugin:

$ php symfony plugin:upgrade [-s|--stability="..."] [-r|--release="..."] [-c|--channel="..."] name

The plugin:upgrade task tries to upgrade a plugin:

./symfony plugin:upgrade sfGuardPlugin

The default channel is symfony.

If the plugin contains some web content (images, stylesheets or javascripts), the task also updates the web/%name% directory content on Windows.

See plugin:install for more information about the format of the plugin name and options.

project

project::clear-controllers

The project::clear-controllers task clears all non production environment controllers:

$ php symfony project:clear-controllers  

The project:clear-controllers task clears all non production environment controllers:

./symfony project:clear-controllers

You can use this task on a production server to remove all front controller scripts except the production ones.

If you have two applications named frontend and backend, you have four default controller scripts in web/:

index.php
frontend_dev.php
backend.php
backend_dev.php

After executing the project:clear-controllers task, two front controller scripts are left in web/:

index.php
backend.php

Those two controllers are safe because debug mode and the web debug toolbar are disabled.

project::deploy

The project::deploy task deploys a project to another server:

$ php symfony project:deploy [--go] [--rsync-dir="..."] [--rsync-options[="..."]] server

The project:deploy task deploys a project on a server:

./symfony project:deploy production

The server must be configured in config/properties.ini:

host=www.example.com
  port=22
  user=fabien
  dir=/var/www/sfblog/
  type=rsync

To automate the deployment, the task uses rsync over SSH. You must configure SSH access with a key or configure the password in config/properties.ini.

By default, the task is in dry-mode. To do a real deployment, you must pass the --go option:

./symfony project:deploy --go production

Files and directories configured in config/rsync_exclude.txt are not deployed:

.svn
/web/uploads/*
/cache/*
/log/*

You can also create a rsync.txt and rsync_include.txt files.

If you need to customize the rsync*.txt files based on the server, you can pass a rsync-dir option:

./symfony project:deploy --go --rsync-dir=config/production production

Last, you can specify the options passed to the rsync executable, using the rsync-options option (defaults are -azC --force --delete --progress):

./symfony project:deploy --go --rsync-options=-avz

project::disable

The project::disable task disables an application in a given environment:

$ php symfony project:disable  env [app1] ... [appN]

The project:disable task disables an environment:

./symfony project:disable prod

You can also specify individual applications to be disabled in that environment:

./symfony project:disable prod frontend backend

project::enable

The project::enable task enables an application in a given environment:

$ php symfony project:enable  env [app1] ... [appN]

The project:enable task enables a specific environment:

./symfony project:enable frontend prod

You can also specify individual applications to be enabled in that environment:

./symfony project:enable prod frontend backend

project::optimize

The project::optimize task optimizes a project for better performance:

$ php symfony project:optimize  application [env]

The project:optimize optimizes a project for better performance:

./symfony project:optimize frontend prod

This task should only be used on a production server. Don't forget to re-run the task each time the project changes.

project::permissions

The project::permissions task fixes symfony directory permissions:

$ php symfony project:permissions  

The project:permissions task fixes directory permissions:

./symfony project:permissions

project::send-emails

The project::send-emails task sends emails stored in a queue:

$ php symfony project:send-emails [--application[="..."]] [--env="..."] [--message-limit[="..."]] [--time-limit[="..."]] 

The project:send-emails sends emails stored in a queue:

php symfony project:send-emails

You can limit the number of messages to send:

php symfony project:send-emails --message-limit=10

Or limit to time (in seconds):

php symfony project:send-emails --time-limit=10

project::validate

The project::validate task finds deprecated usage in a project:

$ php symfony project:validate  

The project:validate task detects deprecated usage in your project.

./symfony project:validate

The task lists all the files you need to change before switching to symfony 1.4.

propel

propel::build

The propel::build task generate code based on your schema:

$ php symfony propel:build [--application[="..."]] [--env="..."] [--no-confirmation] [--all] [--all-classes] [--model] [--forms] [--filters] [--sql] [--db] [--and-load[="..."]] [--and-append[="..."]] 

The propel:build task generates code based on your schema:

./symfony propel:build

You must specify what you would like built. For instance, if you want model and form classes built use the --model and --forms options:

./symfony propel:build --model --forms

You can use the --all shortcut option if you would like all classes and SQL files generated and the database rebuilt:

./symfony propel:build --all

This is equivalent to running the following tasks:

./symfony propel:build-model
./symfony propel:build-forms
./symfony propel:build-filters
./symfony propel:build-sql
./symfony propel:insert-sql

You can also generate only class files by using the --all-classes shortcut option. When this option is used alone, the database will not be modified.

./symfony propel:build --all-classes

The --and-load option will load data from the project and plugin data/fixtures/ directories:

./symfony propel:build --db --and-load

To specify what fixtures are loaded, add a parameter to the --and-load option:

./symfony propel:build --all --and-load="data/fixtures/dev/"

To append fixture data without erasing any records from the database, include the --and-append option:

./symfony propel:build --all --and-append

propel::build-all

The propel::build-all task generates Propel model and form classes, SQL and initializes the database:

$ php symfony propel:build-all [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [-F|--skip-forms] [-C|--classes-only] [--phing-arg="..."] 

The propel:build-all task is a shortcut for five other tasks:

./symfony propel:build-all

The task is equivalent to:

./symfony propel:build-model
./symfony propel:build-forms
./symfony propel:build-filters
./symfony propel:build-sql
./symfony propel:insert-sql

See those tasks' help pages for more information.

To bypass confirmation prompts, you can pass the no-confirmation option:

./symfony propel:buil-all --no-confirmation

To build all classes but skip initializing the database, use the classes-only option:

./symfony propel:build-all --classes-only

propel::build-all-load

The propel::build-all-load task generates Propel model and form classes, SQL, initializes the database, and loads data:

$ php symfony propel:build-all-load [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [-F|--skip-forms] [-C|--classes-only] [--phing-arg="..."] [--append] [--dir="..."] 

The propel:build-all-load task is a shortcut for two other tasks:

./symfony propel:build-all-load

The task is equivalent to:

./symfony propel:build-all
./symfony propel:data-load

See those tasks' help pages for more information.

To bypass the confirmation, you can pass the no-confirmation option:

./symfony propel:buil-all-load --no-confirmation

propel::build-filters

The propel::build-filters task creates filter form classes for the current model:

$ php symfony propel:build-filters [--connection="..."] [--model-dir-name="..."] [--filter-dir-name="..."] [--application[="..."]] [--generator-class="..."] 

The propel:build-filters task creates filter form classes from the schema:

./symfony propel:build-filters

The task read the schema information in config/*schema.xml and/or config/*schema.yml from the project and all installed plugins.

The task use the propel connection as defined in config/databases.yml. You can use another connection by using the --connection option:

./symfony propel:build-filters --connection="name"

The model filter form classes files are created in lib/filter.

This task never overrides custom classes in lib/filter. It only replaces base classes generated in lib/filter/base.

propel::build-forms

The propel::build-forms task creates form classes for the current model:

$ php symfony propel:build-forms [--connection="..."] [--model-dir-name="..."] [--form-dir-name="..."] [--application[="..."]] [--generator-class="..."] 

The propel:build-forms task creates form classes from the schema:

./symfony propel:build-forms

The task read the schema information in config/*schema.xml and/or config/*schema.yml from the project and all installed plugins.

The task use the propel connection as defined in config/databases.yml. You can use another connection by using the --connection option:

./symfony propel:build-forms --connection="name"

The model form classes files are created in lib/form.

This task never overrides custom classes in lib/form. It only replaces base classes generated in lib/form/base.

propel::build-model

The propel::build-model task creates classes for the current model:

$ php symfony propel:build-model [--phing-arg="..."] 

The propel:build-model task creates model classes from the schema:

./symfony propel:build-model

The task read the schema information in config/*schema.xml and/or config/*schema.yml from the project and all installed plugins.

You mix and match YML and XML schema files. The task will convert YML ones to XML before calling the Propel task.

The model classes files are created in lib/model.

This task never overrides custom classes in lib/model. It only replaces files in lib/model/om and lib/model/map.

propel::build-schema

The propel::build-schema task creates a schema from an existing database:

$ php symfony propel:build-schema [--application[="..."]] [--env="..."] [--connection="..."] [--xml] [--phing-arg="..."] 

The propel:build-schema task introspects a database to create a schema:

./symfony propel:build-schema

By default, the task creates a YML file, but you can also create a XML file:

./symfony --xml propel:build-schema

The XML format contains more information than the YML one.

propel::build-sql

The propel::build-sql task creates SQL for the current model:

$ php symfony propel:build-sql [--phing-arg="..."] 

The propel:build-sql task creates SQL statements for table creation:

./symfony propel:build-sql

The generated SQL is optimized for the database configured in config/propel.ini:

propel.database = mysql

propel::data-dump

The propel::data-dump task dumps data to the fixtures directory:

$ php symfony propel:data-dump [--application[="..."]] [--env="..."] [--connection="..."] [--classes="..."] [target]

The propel:data-dump task dumps database data:

./symfony propel:data-dump > data/fixtures/dump.yml

By default, the task outputs the data to the standard output, but you can also pass a filename as a second argument:

./symfony propel:data-dump dump.yml

The task will dump data in data/fixtures/%target% (data/fixtures/dump.yml in the example).

The dump file is in the YML format and can be re-imported by using the propel:data-load task.

By default, the task use the propel connection as defined in config/databases.yml. You can use another connection by using the connection option:

./symfony propel:data-dump --connection="name"

If you only want to dump some classes, use the classes option:

./symfony propel:data-dump --classes="Article,Category"

If you want to use a specific database configuration from an application, you can use the application option:

./symfony propel:data-dump --application=frontend

propel::data-load

The propel::data-load task loads YAML fixture data:

$ php symfony propel:data-load [--application[="..."]] [--env="..."] [--append] [--connection="..."] [dir_or_file1] ... [dir_or_fileN]

The propel:data-load task loads data fixtures into the database:

./symfony propel:data-load

The task loads data from all the files found in data/fixtures/.

If you want to load data from specific files or directories, you can append them as arguments:

./symfony propel:data-load data/fixtures/dev data/fixtures/users.yml

The task use the propel connection as defined in config/databases.yml. You can use another connection by using the --connection option:

./symfony propel:data-load --connection="name"

If you don't want the task to remove existing data in the database, use the --append option:

./symfony propel:data-load --append

If you want to use a specific database configuration from an application, you can use the application option:

./symfony propel:data-load --application=frontend

propel::generate-admin

The propel::generate-admin task generates a Propel admin module:

$ php symfony propel:generate-admin [--module="..."] [--theme="..."] [--singular="..."] [--plural="..."] [--env="..."] [--actions-base-class="..."] application route_or_model

The propel:generate-admin task generates a Propel admin module:

./symfony propel:generate-admin frontend Article

The task creates a module in the %frontend% application for the %Article% model.

The task creates a route for you in the application routing.yml.

You can also generate a Propel admin module by passing a route name:

./symfony propel:generate-admin frontend article

The task creates a module in the %frontend% application for the %article% route definition found in routing.yml.

For the filters and batch actions to work properly, you need to add the with_wildcard_routes option to the route:

article:
  class: sfPropelRouteCollection
  options:
    model:                Article
    with_wildcard_routes: true

propel::generate-module

The propel::generate-module task generates a Propel module:

$ php symfony propel:generate-module [--theme="..."] [--generate-in-cache] [--non-verbose-templates] [--with-show] [--singular="..."] [--plural="..."] [--route-prefix="..."] [--with-propel-route] [--env="..."] [--actions-base-class="..."] application module model

The propel:generate-module task generates a Propel module:

./symfony propel:generate-module frontend article Article

The task creates a %module% module in the %application% application for the model class %model%.

You can also create an empty module that inherits its actions and templates from a runtime generated module in %sf_app_cache_dir%/modules/auto%module% by using the --generate-in-cache option:

./symfony propel:generate-module --generate-in-cache frontend article Article

The generator can use a customized theme by using the --theme option:

./symfony propel:generate-module --theme="custom" frontend article Article

This way, you can create your very own module generator with your own conventions.

You can also change the default actions base class (default to sfActions) of the generated modules:

./symfony propel:generate-module --actions-base-class="ProjectActions" frontend article Article

propel::generate-module-for-route

The propel::generate-module-for-route task generates a Propel module for a route definition:

$ php symfony propel:generate-module-for-route [--theme="..."] [--non-verbose-templates] [--singular="..."] [--plural="..."] [--env="..."] [--actions-base-class="..."] application route

The propel:generate-module-for-route task generates a Propel module for a route definition:

./symfony propel:generate-module-for-route frontend article

The task creates a module in the %frontend% application for the %article% route definition found in routing.yml.

propel::graphviz

The propel::graphviz task generates a graphviz chart of current object model:

$ php symfony propel:graphviz [--phing-arg="..."] 

The propel:graphviz task creates a graphviz DOT visualization for automatic graph drawing of object model:

./symfony propel:graphviz

propel::insert-sql

The propel::insert-sql task inserts SQL for current model:

$ php symfony propel:insert-sql [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [--phing-arg="..."] 

The propel:insert-sql task creates database tables:

./symfony propel:insert-sql

The task connects to the database and executes all SQL statements found in config/sql/*schema.sql files.

Before execution, the task will ask you to confirm the execution as it deletes all data in your database.

To bypass the confirmation, you can pass the --no-confirmation option:

./symfony propel:insert-sql --no-confirmation

The task read the database configuration from databases.yml. You can use a specific application/environment by passing an --application or --env option.

You can also use the --connection option if you want to only load SQL statements for a given connection.

propel::schema-to-xml

The propel::schema-to-xml task creates schema.xml from schema.yml:

$ php symfony propel:schema-to-xml  

The propel:schema-to-xml task converts YML schemas to XML:

./symfony propel:schema-to-xml

propel::schema-to-yml

The propel::schema-to-yml task creates schema.yml from schema.xml:

$ php symfony propel:schema-to-yml  

The propel:schema-to-yml task converts XML schemas to YML:

./symfony propel:schema-to-yml

symfony

symfony::test

The symfony::test task launches the symfony test suite:

$ php symfony symfony:test [-u|--update-autoloader] [-f|--only-failed] [--xml="..."] [--rebuild-all] 

The test:all task launches the symfony test suite:

./symfony symfony:test

test

test::all

The test::all task launches all tests:

$ php symfony test:all [-f|--only-failed] [--xml="..."] 

The test:all task launches all unit and functional tests:

./symfony test:all

The task launches all tests found in test/.

If some tests fail, you can use the --trace option to have more information about the failures:

./symfony test:all -t

Or you can also try to fix the problem by launching them by hand or with the test:unit and test:functional task.

Use the --only-failed option to force the task to only execute tests that failed during the previous run:

./symfony test:all --only-failed

Here is how it works: the first time, all tests are run as usual. But for subsequent test runs, only tests that failed last time are executed. As you fix your code, some tests will pass, and will be removed from subsequent runs. When all tests pass again, the full test suite is run... you can then rinse and repeat.

The task can output a JUnit compatible XML log file with the --xml options:

./symfony test:all --xml=log.xml

test::coverage

The test::coverage task outputs test code coverage:

$ php symfony test:coverage [--detailed] test_name lib_name

The test:coverage task outputs the code coverage given a test file or test directory and a lib file or lib directory for which you want code coverage:

./symfony test:coverage test/unit/model lib/model

To output the lines not covered, pass the --detailed option:

./symfony test:coverage --detailed test/unit/model lib/model

test::functional

The test::functional task launches functional tests:

$ php symfony test:functional [--xml="..."] application [controller1] ... [controllerN]

The test:functional task launches functional tests for a given application:

./symfony test:functional frontend

The task launches all tests found in test/functional/%application%.

If some tests fail, you can use the --trace option to have more information about the failures:

./symfony test:functional frontend -t

You can launch all functional tests for a specific controller by giving a controller name:

./symfony test:functional frontend article

You can also launch all functional tests for several controllers:

./symfony test:functional frontend article comment

The task can output a JUnit compatible XML log file with the --xml options:

./symfony test:functional --xml=log.xml

test::unit

The test::unit task launches unit tests:

$ php symfony test:unit [--xml="..."] [name1] ... [nameN]

The test:unit task launches unit tests:

./symfony test:unit

The task launches all tests found in test/unit.

If some tests fail, you can use the --trace option to have more information about the failures:

./symfony test:unit -t

You can launch unit tests for a specific name:

./symfony test:unit strtolower

You can also launch unit tests for several names:

./symfony test:unit strtolower strtoupper

The task can output a JUnit compatible XML log file with the --xml options:

./symfony test:unit --xml=log.xml