Command Line Interface
Overview
Many of the tasks that a developer executes during the building and maintenance of a web application can be handled by symfony's Command Line Interface (CLI).
Pake
Symfony uses a dedicated tool called Pake to manage common tasks. Pake is a php tool similar to the Rake command, a Ruby translation of the make command. It automates some administration tasks according to a specific configuration file called pakefile.php. But since you use the pake tool just by typing symfony in a command line, everything becomes much simpler than it sounds.
Note: The symfony CLI works only from the root of a symfony project
CLI core
$ symfony -V
Returns the installed version of the symfony package.
$ symfony
Returns the full list of the available administration operations.
The symfony command expects tasks, and some tasks require additional parameters. The general syntax is:
$ symfony <TASK> [parameters]
A few tasks have a shortcut, faster to write, that has the same effect.
$ symfony cc
// does the same thing as
$ symfony clear-cache
When an exception occurs, you might want to get the stack trace and detailed explanation. Add the -t option before the task name to get the trace.
CLI tasks
Structure generation
$ symfony init-project <PROJECT_NAME>
Initializes a new symfony project (shortcut: new).
$ symfony init-app <APPLICATION_NAME>
Initializes a new symfony application (shortcut: app).
$ symfony init-module <APPLICATION_NAME> <MODULE_NAME>
Initializes a new symfony module (shortcut: module).
$ symfony init-batch <SKELETON_NAME> [...]
Initializes a new batch file (shortcut: batch). You must select a batch skeleton to init, and then follow the prompts.
$ symfony init-controller <APPLICATION_NAME> <ENVIRONMENT_NAME> [<SCRIPT_NAME>] [true|false]
Initializes a new controller (shortcut: controller). The default script name follows the symfony convention.
Find more about these commands in the project creation chapter.
Model generation
$ symfony propel-build-model
Generates the Propel classes for the current model, based on the schema files (YAML or XML) of your config/ directory.
The connection settings used by the following commands are taken from the config/propel.ini configuration.
$ symfony propel-build-sql
Generates the SQL code to create the tables described in the schema.yml, in a data/schema.sql file.
$ symfony propel-build-db
Creates an empty database based on the connection settings.
$ symfony propel-insert-sql
Inserts the SQL code from data/schema.sql into the database.
$ symfony propel-build-all
Executes propel-build-model, propel-build-sql and then propel-insert-sql all in one command.
$ symfony propel-load-data <APPLICATION_NAME> [<ENVIRONMENT_NAME>] [<FIXTURES_DIR_OR_FILE>]
Loads all data from default data/fixtures/ directory unless otherwise specified. Environment is default to dev. The fixtures directory must be specified relative to the project's data dir, for example fixtures (default) or testdata or specify a single file fixtures/file.yml.
$ symfony propel-build-all-load <APPLICATION_NAME> [<ENVIRONMENT_NAME>] [<FIXTURES_DIR_OR_FILE>]
Executes propel-build-all then propel-load-data. Accepts same arguments as propel-load-data.
$ symfony propel-build-schema
Creates a schema.yml from an existing database.
$ symfony propel-build-schema xml
Creates a schema.xml from an existing database.
Find more about these commands in the model chapter.
Development tools
$ symfony clear-cache [<APPLICATION_NAME>] [template|config]
Clears the cached information (shortcut: cc) (find more in the cache chapter).
$ symfony clear-controllers
Clears the web directory of all controllers other than ones running in a production environment. Very useful before deployment to the production server.
$ symfony fix-perms
Fixes directories permissions, to change to 777 the directories that need to be writable. The permission can be broken if you use a checkout from a SVN repository.
$ symfony test <APPLICATION_NAME>
Launches the test suite for an application (find more in the unit test chapter).
$ symfony freeze
$ symfony unfreeze
Copies all the necessary symfony libraries into the data/, lib/ and web/sf/ directories of your project. Your project then becomes a kind of sandbox, i.e. a standalone application with no dependence and ready to be transferred to production via FTP. Works fine with PEAR installations as well as symbolic links. Unfreeze your project with the unfreeze task.
$ symfony sync <ENVIRONMENT_NAME> [go]
Synchronises the current project with another machine (find more in the deployment chapter).
Project administration
$ symfony disable <APPLICATION_NAME> <ENVIRONMENT_NAME>
Forwards the user to the unavailable module and action in your settings.yml file and acts in the same way as if you had set the unavaiable setting in your settings.yml file. The advantage over the setting is that you can disable a single application for a single environment, and not only the whole project.
$ symfony enable <APPLICATION_NAME> <ENVIRONMENT_NAME>
Enables the application and clears the cache.
$ symfony purge-logs
Clears the logs files in the log directory in applications and environments where the logging.yml specifies purge: on (which is the default value).
$ symfony rotate-log <APPLICATION_NAME> <ENVIRONMENT_NAME>
Forces a rotation of a log file if rotate is enabled for the log file in logging.yml. The rotation parameters are the period (the number of days a single log file lasts) and the history (the number of backup log files kept). Here is an example of logging.yml withrotation configutation:
prod:
rotate: on
period: 7 ## Log files are rotated every 7 days by default
history: 10 ## A maximum history of 10 log files is kepts
Scaffolding and admin generation
$ symfony propel-generate-crud <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME>
$ symfony propel-init-crud <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME>
Generates a new Propel CRUD module based on a class from the model. The generate version copies the code from the framework to a new module, the init verson creates an empty module that inherits from the one in the framework. In this case, the generated code is visible only in the cache/ folder (the generated actions and templates inherit from the framework).
$ symfony propel-init-admin <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME>
Initializes a new Propel admin module based on a class from the model
Find more about these commands in the scaffolding and generator chapter.
Plugin management
$ symfony plugin-install [local|global] <CHANNEL_NAME>/<PLUGIN_NAME>
Installs a new plugin.
$ symfony plugin-upgrade [local|global] <CHANNEL_NAME>/<PLUGIN_NAME>
Upgrades a plugin.
$ symfony plugin-upgrade-all
Upgrades all the plugins previously installed in local
$ symfony plugin-uninstall [local|global] <CHANNEL_NAME>/<PLUGIN_NAME>
Uninstalls a plugin.
The way to build, install and manage plugins is described in the plugin chapter.
Automatic completion
The symfony wiki contains user-contributed configuration files to allow automatic completion of symfony commands. Check out the one that fits your CLI:
|