Quelle symfony-commands.xml Sprache: XML

<?xml version="1.0" encoding="UTF-8"?>
<symfony>
 <tasks>
 <task id="help" namespace="_global" name="help">
 <usage> help [--xml] [task_name]</usage>
 <description>Displays help for a task</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="task_name" is_required="0" is_array="0">
 <description>The task name</description>
 <defaults>
 <default>help</default>
 </defaults>
 </argument>
 </arguments>
 <options>
 <option name="--xml" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>To output help as XML</description>
 </option>
 </options>
</task>
 <task id="list" namespace="_global" name="list">
 <usage> list [--xml] [namespace]</usage>
 <description>Lists tasks</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="namespace" is_required="0" is_array="0">
 <description>The namespace name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--xml" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>To output help as XML</description>
 </option>
 </options>
</task>
 <task id="app:routes" namespace="app" name="routes">
 <usage> app:routes application [name]</usage>
 <description>Displays current routes for an application</description>
 <help>The app:routes displays the current routes for a given application:

 ./symfony app:routes frontend</help>
 <aliases/>
 <arguments>
 <argument name="application" is_required="1" is_array="0">
 <description>The application name</description>
 <defaults/>
 </argument>
 <argument name="name" is_required="0" is_array="0">
 <description>A route name</description>
 <defaults/>
 </argument>
 </arguments>
 <options/>
</task>
 <task id="cache:clear" namespace="cache" name="clear">
 <usage> cache:clear [--app[="..."]] [--env[="..."]] [--type[="..."]] </usage>
 <description>Clears the cache</description>
 <help>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.
</help>
 <aliases>
 <alias>cc</alias>
 </aliases>
 <arguments/>
 <options>
 <option name="--app" shortcut="" accept_parameter="1" is_parameter_required="0" is_multiple="0">
 <description>The application name</description>
 <defaults/>
 </option>
 <option name="--env" shortcut="" accept_parameter="1" is_parameter_required="0" is_multiple="0">
 <description>The environment</description>
 <defaults/>
 </option>
 <option name="--type" shortcut="" accept_parameter="1" is_parameter_required="0" is_multiple="0">
 <description>The type</description>
 <defaults>
 <default>all</default>
 </defaults>
 </option>
 </options>
</task>
 <task id="configure:author" namespace="configure" name="author">
 <usage> configure:author author</usage>
 <description>Configure project author</description>
 <help>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].</help>
 <aliases/>
 <arguments>
 <argument name="author" is_required="1" is_array="0">
 <description>The project author</description>
 <defaults/>
 </argument>
 </arguments>
 <options/>
</task>
 <task id="generate:app" namespace="generate" name="app">
 <usage> generate:app [--escaping-strategy="..."] [--csrf-secret="..."] app</usage>
 <description>Generates a new application</description>
 <help>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.</help>
 <aliases/>
 <arguments>
 <argument name="app" is_required="1" is_array="0">
 <description>The application name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--escaping-strategy" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>Output escaping strategy</description>
 <defaults>
 <default>1</default>
 </defaults>
 </option>
 <option name="--csrf-secret" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>Secret to use for CSRF protection</description>
 <defaults>
 <default>1</default>
 </defaults>
 </option>
 </options>
</task>
 <task id="generate:module" namespace="generate" name="module">
 <usage> generate:module application module</usage>
 <description>Generates a new module</description>
 <help>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:

 [symfony]
 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.</help>
 <aliases/>
 <arguments>
 <argument name="application" is_required="1" is_array="0">
 <description>The application name</description>
 <defaults/>
 </argument>
 <argument name="module" is_required="1" is_array="0">
 <description>The module name</description>
 <defaults/>
 </argument>
 </arguments>
 <options/>
</task>
 <task id="generate:project" namespace="generate" name="project">
 <usage> generate:project [--orm="..."] [--installer="..."] name [author]</usage>
 <description>Generates a new project</description>
 <help>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"</help>
 <aliases/>
 <arguments>
 <argument name="name" is_required="1" is_array="0">
 <description>The project name</description>
 <defaults/>
 </argument>
 <argument name="author" is_required="0" is_array="0">
 <description>The project author</description>
 <defaults>
 <default>Your name here</default>
 </defaults>
 </argument>
 </arguments>
 <options>
 <option name="--orm" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The ORM to use by default</description>
 <defaults>
 <default>Doctrine</default>
 </defaults>
 </option>
 <option name="--installer" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>An installer script to execute</description>
 <defaults/>
 </option>
 </options>
</task>
 <task id="generate:task" namespace="generate" name="task">
 <usage> generate:task [--dir="..."] [--use-database="..."] [--brief-description="..."] task_name</usage>
 <description>Creates a skeleton class for a new task</description>
 <help>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"</help>
 <aliases/>
 <arguments>
 <argument name="task_name" is_required="1" is_array="0">
 <description>The task name (can contain namespace)</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--dir" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The directory to create the task in</description>
 <defaults>
 <default>lib/task</default>
 </defaults>
 </option>
 <option name="--use-database" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>Whether the task needs model initialization to access database</description>
 <defaults/>
 </option>
 <option name="--brief-description" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>A brief task description (appears in task list)</description>
 <defaults/>
 </option>
 </options>
</task>
 <task id="i18n:extract" namespace="i18n" name="extract">
 <usage> i18n:extract [--display-new] [--display-old] [--auto-save] [--auto-delete] application culture</usage>
 <description>Extracts i18n strings from php files</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="application" is_required="1" is_array="0">
 <description>The application name</description>
 <defaults/>
 </argument>
 <argument name="culture" is_required="1" is_array="0">
 <description>The target culture</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--display-new" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Output all new found strings</description>
 </option>
 <option name="--display-old" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Output all old strings</description>
 </option>
 <option name="--auto-save" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Save the new strings</description>
 </option>
 <option name="--auto-delete" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Delete old strings</description>
 </option>
 </options>
</task>
 <task id="i18n:find" namespace="i18n" name="find">
 <usage> i18n:find [--env="..."] application</usage>
 <description>Finds non "i18n ready" strings in an application</description>
 <help>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:

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

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).</help>
 <aliases/>
 <arguments>
 <argument name="application" is_required="1" is_array="0">
 <description>The application name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--env" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The environment</description>
 <defaults>
 <default>dev</default>
 </defaults>
 </option>
 </options>
</task>
 <task id="log:clear" namespace="log" name="clear">
 <usage> log:clear </usage>
 <description>Clears log files</description>
 <help>The log:clear task clears all symfony log files:

 ./symfony log:clear</help>
 <aliases/>
 <arguments/>
 <options/>
</task>
 <task id="log:rotate" namespace="log" name="rotate">
 <usage> log:rotate [--history="..."] [--period="..."] application env</usage>
 <description>Rotates an application's log files
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="application" is_required="1" is_array="0">
 <description>The application name</description>
 <defaults/>
 </argument>
 <argument name="env" is_required="1" is_array="0">
 <description>The environment name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--history" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The maximum number of old log files to keep</description>
 <defaults>
 <default>10</default>
 </defaults>
 </option>
 <option name="--period" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The period in days</description>
 <defaults>
 <default>7</default>
 </defaults>
 </option>
 </options>
</task>
 <task id="plugin:add-channel" namespace="plugin" name="add-channel">
 <usage> plugin:add-channel name</usage>
 <description>Add a new PEAR channel</description>
 <help>The plugin:add-channel task adds a new PEAR channel:

 ./symfony plugin:add-channel symfony.plugins.pear.example.com</help>
 <aliases/>
 <arguments>
 <argument name="name" is_required="1" is_array="0">
 <description>The channel name</description>
 <defaults/>
 </argument>
 </arguments>
 <options/>
</task>
 <task id="plugin:install" namespace="plugin" name="install">
 <usage> plugin:install [-s|--stability="..."] [-r|--release="..."] [-c|--channel="..."] [-d|--install_deps] [--force-license] name</usage>
 <description>Installs a plugin</description>
 <help>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.</help>
 <aliases/>
 <arguments>
 <argument name="name" is_required="1" is_array="0">
 <description>The plugin name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--stability" shortcut="-s" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The preferred stability (stable, beta, alpha)</description>
 <defaults/>
 </option>
 <option name="--release" shortcut="-r" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The preferred version</description>
 <defaults/>
 </option>
 <option name="--channel" shortcut="-c" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The PEAR channel name</description>
 <defaults/>
 </option>
 <option name="--install_deps" shortcut="-d" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Whether to force installation of required dependencies</description>
 </option>
 <option name="--force-license" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Whether to force installation even if the license is not MIT like</description>
 </option>
 </options>
</task>
 <task id="plugin:list" namespace="plugin" name="list">
 <usage> plugin:list </usage>
 <description>Lists installed plugins</description>
 <help>The plugin:list task lists all installed plugins:

 ./symfony plugin:list

It also gives the channel and version for each plugin.</help>
 <aliases/>
 <arguments/>
 <options/>
</task>
 <task id="plugin:publish-assets" namespace="plugin" name="publish-assets">
 <usage> plugin:publish-assets [--core-only] [plugins1] ... [pluginsN]</usage>
 <description>Publishes web assets for all plugins</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="plugins" is_required="0" is_array="1">
 <description>Publish this plugin's assets
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--core-only" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>If set only core plugins will publish their assets</description>
 </option>
 </options>
</task>
 <task id="plugin:uninstall" namespace="plugin" name="uninstall">
 <usage> plugin:uninstall [-c|--channel="..."] [-d|--install_deps] name</usage>
 <description>Uninstalls a plugin</description>
 <help>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).</help>
 <aliases/>
 <arguments>
 <argument name="name" is_required="1" is_array="0">
 <description>The plugin name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--channel" shortcut="-c" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The PEAR channel name</description>
 <defaults/>
 </option>
 <option name="--install_deps" shortcut="-d" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Whether to force installation of dependencies</description>
 </option>
 </options>
</task>
 <task id="plugin:upgrade" namespace="plugin" name="upgrade">
 <usage> plugin:upgrade [-s|--stability="..."] [-r|--release="..."] [-c|--channel="..."] name</usage>
 <description>Upgrades a plugin</description>
 <help>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.</help>
 <aliases/>
 <arguments>
 <argument name="name" is_required="1" is_array="0">
 <description>The plugin name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--stability" shortcut="-s" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The preferred stability (stable, beta, alpha)</description>
 <defaults/>
 </option>
 <option name="--release" shortcut="-r" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The preferred version</description>
 <defaults/>
 </option>
 <option name="--channel" shortcut="-c" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The PEAR channel name</description>
 <defaults/>
 </option>
 </options>
</task>
 <task id="project:clear-controllers" namespace="project" name="clear-controllers">
 <usage> project:clear-controllers </usage>
 <description>Clears all non production environment controllers</description>
 <help>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.</help>
 <aliases/>
 <arguments/>
 <options/>
</task>
 <task id="project:deploy" namespace="project" name="deploy">
 <usage> project:deploy [--go] [--rsync-dir="..."] [--rsync-options[="..."]] server</usage>
 <description>Deploys a project to another server</description>
 <help>The project:deploy task deploys a project on a server:

 ./symfony project:deploy production

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

 [production]
 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</help>
 <aliases/>
 <arguments>
 <argument name="server" is_required="1" is_array="0">
 <description>The server name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--go" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Do the deployment</description>
 </option>
 <option name="--rsync-dir" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The directory where to look for rsync*.txt files</description>
 <defaults>
 <default>config</default>
 </defaults>
 </option>
 <option name="--rsync-options" shortcut="" accept_parameter="1" is_parameter_required="0" is_multiple="0">
 <description>To options to pass to the rsync executable</description>
 <defaults>
 <default>-azC --force --delete --progress</default>
 </defaults>
 </option>
 </options>
</task>
 <task id="project:disable" namespace="project" name="disable">
 <usage> project:disable env [app1] ... [appN]</usage>
 <description>Disables an application in a given environment</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="env" is_required="1" is_array="0">
 <description>The environment name</description>
 <defaults/>
 </argument>
 <argument name="app" is_required="0" is_array="1">
 <description>The application name</description>
 <defaults/>
 </argument>
 </arguments>
 <options/>
</task>
 <task id="project:enable" namespace="project" name="enable">
 <usage> project:enable env [app1] ... [appN]</usage>
 <description>Enables an application in a given environment</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="env" is_required="1" is_array="0">
 <description>The environment name</description>
 <defaults/>
 </argument>
 <argument name="app" is_required="0" is_array="1">
 <description>The application name</description>
 <defaults/>
 </argument>
 </arguments>
 <options/>
</task>
 <task id="project:optimize" namespace="project" name="optimize">
 <usage> project:optimize application [env]</usage>
 <description>Optimizes a project for better performance</description>
 <help>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.</help>
 <aliases/>
 <arguments>
 <argument name="application" is_required="1" is_array="0">
 <description>The application name</description>
 <defaults/>
 </argument>
 <argument name="env" is_required="0" is_array="0">
 <description>The environment name</description>
 <defaults>
 <default>prod</default>
 </defaults>
 </argument>
 </arguments>
 <options/>
</task>
 <task id="project:permissions" namespace="project" name="permissions">
 <usage> project:permissions </usage>
 <description>Fixes symfony directory permissions</description>
 <help>The project:permissions task fixes directory permissions:

 ./symfony project:permissions</help>
 <aliases/>
 <arguments/>
 <options/>
</task>
 <task id="project:send-emails" namespace="project" name="send-emails">
 <usage> project:send-emails [--application[="..."]] [--env="..."] [--message-limit[="..."]] [--time-limit[="..."]] </usage>
 <description>Sends emails stored in a queue</description>
 <help>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</help>
 <aliases/>
 <arguments/>
 <options>
 <option name="--application" shortcut="" accept_parameter="1" is_parameter_required="0" is_multiple="0">
 <description>The application name</description>
 <defaults>
 <default>1</default>
 </defaults>
 </option>
 <option name="--env" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The environment</description>
 <defaults>
 <default>dev</default>
 </defaults>
 </option>
 <option name="--message-limit" shortcut="" accept_parameter="1" is_parameter_required="0" is_multiple="0">
 <description>The maximum number of messages to send</description>
 <defaults/>
 </option>
 <option name="--time-limit" shortcut="" accept_parameter="1" is_parameter_required="0" is_multiple="0">
 <description>The time limit for sending messages (in seconds)</description>
 <defaults/>
 </option>
 </options>
</task>
 <task id="project:validate" namespace="project" name="validate">
 <usage> project:validate </usage>
 <description>Finds deprecated usage in a project</description>
 <help>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.</help>
 <aliases/>
 <arguments/>
 <options/>
</task>
 <task id="symfony:test" namespace="symfony" name="test">
 <usage> symfony:test [-u|--update-autoloader] [-f|--only-failed] [--xml="..."] [--rebuild-all] </usage>
 <description>Launches the symfony test suite</description>
 <help>The test:all task launches the symfony test suite:

 ./symfony symfony:test</help>
 <aliases/>
 <arguments/>
 <options>
 <option name="--update-autoloader" shortcut="-u" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Update the sfCoreAutoload class</description>
 </option>
 <option name="--only-failed" shortcut="-f" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Only run tests that failed last time</description>
 </option>
 <option name="--xml" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The file name for the JUnit compatible XML log file</description>
 <defaults/>
 </option>
 <option name="--rebuild-all" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Rebuild all generated fixture files</description>
 </option>
 </options>
</task>
 <task id="test:all" namespace="test" name="all">
 <usage> test:all [-f|--only-failed] [--xml="..."] </usage>
 <description>Launches all tests</description>
 <help>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</help>
 <aliases/>
 <arguments/>
 <options>
 <option name="--only-failed" shortcut="-f" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Only run tests that failed last time</description>
 </option>
 <option name="--xml" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The file name for the JUnit compatible XML log file</description>
 <defaults/>
 </option>
 </options>
</task>
 <task id="test:coverage" namespace="test" name="coverage">
 <usage> test:coverage [--detailed] test_name lib_name</usage>
 <description>Outputs test code coverage</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="test_name" is_required="1" is_array="0">
 <description>A test file name or a test directory</description>
 <defaults/>
 </argument>
 <argument name="lib_name" is_required="1" is_array="0">
 <description>A lib file name or a lib directory for wich you want to know the coverage</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--detailed" shortcut="" accept_parameter="0" is_parameter_required="0" is_multiple="0">
 <description>Output detailed information</description>
 </option>
 </options>
</task>
 <task id="test:functional" namespace="test" name="functional">
 <usage> test:functional [--xml="..."] application [controller1] ... [controllerN]</usage>
 <description>Launches functional tests</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="application" is_required="1" is_array="0">
 <description>The application name</description>
 <defaults/>
 </argument>
 <argument name="controller" is_required="0" is_array="1">
 <description>The controller name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--xml" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The file name for the JUnit compatible XML log file</description>
 <defaults/>
 </option>
 </options>
</task>
 <task id="test:unit" namespace="test" name="unit">
 <usage> test:unit [--xml="..."] [name1] ... [nameN]</usage>
 <description>Launches unit tests</description>
 <help>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</help>
 <aliases/>
 <arguments>
 <argument name="name" is_required="0" is_array="1">
 <description>The test name</description>
 <defaults/>
 </argument>
 </arguments>
 <options>
 <option name="--xml" shortcut="" accept_parameter="1" is_parameter_required="1" is_multiple="0">
 <description>The file name for the JUnit compatible XML log file</description>
 <defaults/>
 </option>
 </options>
</task>
 </tasks>
 <namespaces>
 <namespace id="_global">
 <task>help</task>
 <task>list</task>
 </namespace>
 <namespace id="app">
 <task>routes</task>
 </namespace>
 <namespace id="cache">
 <task>clear</task>
 </namespace>
 <namespace id="configure">
 <task>author</task>
 </namespace>
 <namespace id="generate">
 <task>app</task>
 <task>module</task>
 <task>project</task>
 <task>task</task>
 </namespace>
 <namespace id="i18n">
 <task>extract</task>
 <task>find</task>
 </namespace>
 <namespace id="log">
 <task>clear</task>
 <task>rotate</task>
 </namespace>
 <namespace id="plugin">
 <task>add-channel</task>
 <task>install</task>
 <task>list</task>
 <task>publish-assets</task>
 <task>uninstall</task>
 <task>upgrade</task>
 </namespace>
 <namespace id="project">
 <task>clear-controllers</task>
 <task>deploy</task>
 <task>disable</task>
 <task>enable</task>
 <task>optimize</task>
 <task>permissions</task>
 <task>send-emails</task>
 <task>validate</task>
 </namespace>
 <namespace id="symfony">
 <task>test</task>
 </namespace>
 <namespace id="test">
 <task>all</task>
 <task>coverage</task>
 <task>functional</task>
 <task>unit</task>
 </namespace>
 </namespaces>
</symfony>

quality100%

¤ Dauer der Verarbeitung: 0.22 Sekunden (vorverarbeitet) ¤

Wurzel

Suchen

Beweissystem der NASA

Beweissystem Isabelle

NIST Cobol Testsuite

Cephes Mathematical Library

Wiener Entwicklungsmethode

Haftungshinweis

Die Informationen auf dieser Webseite wurden nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit, noch Qualität der bereit gestellten Informationen zugesichert.

Bemerkung:

Die farbliche Syntaxdarstellung ist noch experimentell.