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-all
  • doctrine::build-all-load
  • doctrine::build-all-reload
  • doctrine::build-all-reload-test-all
  • doctrine::build-db
  • doctrine::build-filters
  • doctrine::build-forms
  • doctrine::build-model
  • doctrine::build-schema
  • doctrine::build-sql
  • doctrine::data-dump
  • doctrine::data-load
  • doctrine::dql
  • doctrine::drop-db
  • doctrine::generate-admin
  • doctrine::generate-migration
  • doctrine::generate-migrations-db
  • doctrine::generate-migrations-models
  • doctrine::generate-module
  • doctrine::generate-module-for-route
  • doctrine::insert-sql
  • doctrine::migrate
  • doctrine::rebuild-db
• 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::freeze
  • project::permissions
  • project::unfreeze
  • project::upgrade1.1
  • project::upgrade1.2
• propel
  • 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::init-admin
  • propel::insert-sql
  • propel::schema-to-xml
  • propel::schema-to-yml
• test
  • test::all
  • test::coverage
  • test::functional
  • test::unit

help

The help task displays help for a task:

$ php symfony help  [task_name]

Alias(es): h

list

The list task lists tasks:

$ php symfony list  [namespace]

The list task lists all tasks:

./symfony list

You can also display the tasks for a specific namespace:

./symfony list test

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, clear-cache

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=sfDoctrineDatabase 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-all

The doctrine::build-all task generates Doctrine model, SQL and initializes the database:

$ php symfony doctrine:build-all [--application[="..."]] [--env="..."] [--no-confirmation] [--skip-forms|-F] 

Alias(es): doctrine-build-all

The doctrine:build-all task is a shortcut for four other tasks:

./symfony doctrine:build-all

The task is equivalent to:

./symfony doctrine:build-model
./symfony doctrine:build-sql
./symfony doctrine:insert-sql

See those three tasks help page for more information.

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

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

doctrine::build-all-load

The doctrine::build-all-load task generates Doctrine model, SQL, initializes database, and loads fixtures data:

$ php symfony doctrine:build-all-load [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [--skip-forms|-F] [--dir="..."] 

Alias(es): doctrine-build-all-load

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

./symfony doctrine:build-all-load

The task is equivalent to:

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

The task takes an application argument because of the doctrine:data-load task. See doctrine:data-load help page for more information.

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

./symfony doctrine:build-all-load --no-confirmation

doctrine::build-all-reload

The doctrine::build-all-reload task generates Doctrine model, SQL, initializes database, and load data:

$ php symfony doctrine:build-all-reload [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [--skip-forms|-F] [--dir="..."] 

Alias(es): doctrine-build-all-reload

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

./symfony doctrine:build-all-reload

The task is equivalent to:

./symfony doctrine:drop-db
./symfony doctrine:build-db
./symfony doctrine:build-model
./symfony doctrine:insert-sql
./symfony doctrine:data-load

doctrine::build-all-reload-test-all

The doctrine::build-all-reload-test-all task generates Doctrine model, SQL, initializes database, load data and run all tests:

$ php symfony doctrine:build-all-reload-test-all [--application[="..."]] [--env="..."] [--append] [--dir="..."] [--force] 

Alias(es): doctrine-build-all-reload-test-all

The doctrine:build-all-reload task is a shortcut for four other tasks:

./symfony doctrine:build-all-reload-test-all frontend

The task is equivalent to:

./symfony doctrine:drop-db
./symfony doctrine:build-db
./symfony doctrine:build-model
./symfony doctrine:insert-sql
./symfony doctrine:data-load
./symfony test-all

The task takes an application argument because of the doctrine:data-load task. See doctrine:data-load help page for more information.

doctrine::build-db

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

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

Alias(es): doctrine-build-db

The doctrine:build-db task creates the database:

./symfony doctrine:build-db

The task read connection information in config/doctrine/databases.yml:

doctrine::build-filters

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

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

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

./symfony doctrine: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 doctrine connection as defined in config/databases.yml. You can use another connection by using the --connection option:

./symfony doctrine: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.

doctrine::build-forms

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

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

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

./symfony doctrine: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 doctrine connection as defined in config/databases.yml. You can use another connection by using the --connection option:

./symfony doctrine: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.

doctrine::build-model

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

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

Alias(es): doctrine-build-model

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 installed 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="..."] 

Alias(es): doctrine-build-schema

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="..."] 

Alias(es): doctrine-build-sql

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::data-dump

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

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

Alias(es): doctrine-dump-data

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 frontend

doctrine::data-load

The doctrine::data-load task loads data from fixtures directory:

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

Alias(es): doctrine-load-data

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

./symfony doctrine:data-load frontend

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

If you want to load data from other directories, you can use the --dir option:

./symfony doctrine:data-load --dir="data/fixtures" --dir="data/data" frontend

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

./symfony doctrine:data-load --append frontend

doctrine::dql

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

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

Alias(es): doctrine-dql

The doctrine:data-dql task executes a DQL query and display the formatted results:

./symfony doctrine:dql "FROM User u"

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

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

doctrine::drop-db

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

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

Alias(es): doctrine-drop-db

The doctrine:drop-db task drops the database:

./symfony doctrine:drop-db

The task read connection information in config/doctrine/databases.yml:

doctrine::generate-admin

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

$ php symfony doctrine:generate-admin [--module="..."] [--theme="..."] [--singular="..."] [--plural="..."] [--env="..."] 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 wildcard 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="..."] name

Alias(es): doctrine-generate-migration

The doctrine:generate-migration task generates migration template

./symfony doctrine:generate-migration

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="..."] 

Alias(es): doctrine-generate-migrations-db, doctrine-gen-migrations-from-db

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

./symfony doctrine:generate-migration

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="..."] 

Alias(es): doctrine-generate-migrations-models, doctrine-gen-migrations-from-models

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

./symfony doctrine:generate-migration

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="..."] application module model

Alias(es): doctrine-generate-crud, doctrine:generate-crud

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.

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="..."] 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="..."] 

Alias(es): doctrine-insert-sql

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/*.php files.

doctrine::migrate

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

$ php symfony doctrine:migrate [--application[="..."]] [--env="..."] [version]

Alias(es): doctrine-migrate

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

./symfony doctrine:migrate

doctrine::rebuild-db

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

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

Alias(es): doctrine-rebuild-db

The doctrine:rebuild-db task creates the database:

./symfony doctrine:rebuild-db

The task read connection information in config/doctrine/databases.yml:

generate

generate::app

The generate::app task generates a new application:

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

Alias(es): init-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.

You can enable output escaping (to prevent XSS) by using the escaping-strategy option:

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

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

generate::module

The generate::module task generates a new module:

$ php symfony generate:module  application module

Alias(es): init-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  name

Alias(es): init-project

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.

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 propel, 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  

Alias(es): log-purge

The log:clear task clears all symfony log files:

./symfony log:clear

log::rotate

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

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

Alias(es): log-rotate

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 --history=10 --period=7 log:rotate frontend dev

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 [--stability|-s="..."] [--release|-r="..."] [--channel|-c="..."] [--install_deps|-d] [--force-license] name

Alias(es): plugin-install

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  

Alias(es): 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] [--symfony-lib-dir="..."] 

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.

plugin::uninstall

The plugin::uninstall task uninstalls a plugin:

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

Alias(es): plugin-uninstall

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 [--stability|-s="..."] [--release|-r="..."] [--channel|-c="..."] name

Alias(es): plugin-upgrade

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  

Alias(es): 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

Alias(es): sync

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):

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

project::disable

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

$ php symfony project:disable  application env

Alias(es): disable

The project:disable task disables an application for a specific environment:

./symfony project:disable frontend prod

project::enable

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

$ php symfony project:enable  application env

Alias(es): enable

The project:enable task enables an application for a specific environment:

./symfony project:enable frontend prod

project::freeze

The project::freeze task freezes symfony libraries:

$ php symfony project:freeze  symfony_data_dir

Alias(es): freeze

The project:freeze task copies all the symfony core files to the current project:

./symfony project:freeze /path/to/symfony/data/directory

The task takes a mandatory argument of the path to the symfony data directory.

The task also changes config/config.php to switch to the embedded symfony files.

project::permissions

The project::permissions task fixes symfony directory permissions:

$ php symfony project:permissions  

Alias(es): permissions, fix-perms

The project:permissions task fixes directory permissions:

./symfony project:permissions

project::unfreeze

The project::unfreeze task unfreezes symfony libraries:

$ php symfony project:unfreeze  

Alias(es): unfreeze

The project:unfreeze task removes all the symfony core files from the current project:

./symfony project:unfreeze

The task also changes config/config.php to switch to the old symfony files used before the project:freeze command was used.

project::upgrade1.1

The project::upgrade1.1 task upgrade a symfony project to the 1.1 symfony release:

$ php symfony project:upgrade1.1  

The project:upgrade1.1 task upgrades a symfony project based the 1.0 release to the 1.1 symfony release.

./symfony project:upgrade1.1

Please read the UPGRADE_TO_1_1 file to have information on what does this task.

project::upgrade1.2

The project::upgrade1.2 task upgrade a symfony project to the 1.2 symfony release (from 1.1):

$ php symfony project:upgrade1.2  

The project:upgrade1.2 task upgrades a symfony project based on the 1.1 release to the 1.2 symfony release.

./symfony project:upgrade1.2

Please read the UPGRADE_TO_1_2 file to have information on what does this task.

propel

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] [--skip-forms|-F] [--classes-only|-C] [--phing-arg="..."] 

Alias(es): propel-build-all

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] [--skip-forms|-F] [--classes-only|-C] [--phing-arg="..."] [--append] [--dir="..."] 

Alias(es): propel-build-all-load

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[="..."]] 

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[="..."]] 

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="..."] 

Alias(es): propel-build-model

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="..."] 

Alias(es): propel-build-schema

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="..."] 

Alias(es): propel-build-sql

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]

Alias(es): propel-dump-data

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 data from fixtures directory:

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

Alias(es): propel-load-data

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 other directories, you can use the --dir option:

./symfony propel:data-load --dir="data/fixtures" --dir="data/data"

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="..."] 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 wildcard 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="..."] application module model

Alias(es): propel-generate-crud, propel:generate-crud

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.

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="..."] 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::init-admin

The propel::init-admin task initializes a Propel admin module:

$ php symfony propel:init-admin [--theme="..."] application module model

Alias(es): propel-init-admin

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

./symfony propel:init-admin frontend article Article

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

The created module is an empty one that inherit its actions and templates from a runtime generated module in %sf_app_cache_dir%/modules/auto%module%.

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

./symfony propel:init-admin --theme="custom" frontend article Article

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="..."] 

Alias(es): propel-insert-sql

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  

Alias(es): propel-convert-yml-schema

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  

Alias(es): propel-convert-xml-schema

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

./symfony propel:schema-to-yml

test

test::all

The test::all task launches all tests:

$ php symfony test:all  

Alias(es): test-all

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

./symfony test:all

The task launches all tests found in test/.

If one or more test fail, you can try to fix the problem by launching them by hand or with the test:unit and test:functional task.

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  application [controller1] ... [controllerN]

Alias(es): test-functional

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

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

test::unit

The test::unit task launches unit tests:

$ php symfony test:unit  [name1] ... [nameN]

Alias(es): test-unit

The test:unit task launches unit tests:

./symfony test:unit

The task launches all tests found in test/unit.

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