In symfony, applications sharing the same data model are regrouped into projects. For most projects, you will have two different applications: a frontend and a backend.
sfproject/ directory, run the symfony
generate:project task to
actually create the symfony project:
$ php lib/vendor/symfony/data/bin/symfony generate:project PROJECT_NAME
c:\> php lib\vendor\symfony\data\bin\symfony generate:project PROJECT_NAME
generate:project task generates the default structure of directories and
files needed for a symfony project:
||Hosts all project applications|
||The files cached by the framework|
||The project configuration files|
||Data files like initial fixtures|
||The project libraries and classes|
||The framework log files|
||The installed plugins|
||The unit and functional test files|
||The web root directory (see below)|
Why does symfony generate so many files? One of the main benefits of using a full-stack framework is to standardize your developments. Thanks to symfony's default structure of files and directories, any developer with some symfony knowledge can take over the maintenance of any symfony project. In a matter of minutes, he will be able to dive into the code, fix bugs, and add new features.
generate:project task has also created a
symfony shortcut in the
project root directory to shorten the number of characters you have to write
when running a task.
So, from now on, instead of using the fully qualified path to the symfony
program, you can use the
Now that symfony is installed, check that everything is working by using the
symfony command line to display the symfony version (note the capital
$ cd ../.. $ php lib/vendor/symfony/data/bin/symfony -V
c:\> cd ..\.. c:\> php lib\vendor\symfony\data\bin\symfony -V
-V option also displays the path to the symfony installation directory,
which is stored in
If the path to symfony is an absolute one (which should not be by default if you follow the above instructions), change it so it reads like follows for better portability:
// config/ProjectConfiguration.class.php require_once dirname(__FILE__).'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';
That way, you can move the project directory anywhere on your machine or another one, and it will just work.
If you are curious about what this command line tool can do for you, type
symfony to list the available options and tasks:
$ php lib/vendor/symfony/data/bin/symfony
c:\> php lib\vendor\symfony\data\bin\symfony
The symfony command line is the developer's best friend. It provides a lot of utilities that improve your productivity for day-to-day activities like cleaning the cache, generating code, and much more.
The symfony framework supports all PDO-supported databases (MySQL, PostgreSQL, SQLite, Oracle, MSSQL, ...) out of the box. On top of PDO, symfony comes bundled with two ORM tools: Propel and Doctrine.
When creating a new project, Doctrine is enabled by default. Configuring the
database used by Doctrine is as simple as using the
$ php symfony configure:database "mysql:host=localhost;dbname=dbname" root mYsEcret
configure:database task takes three arguments: the
PDO DSN, the username, and
the password to access the database. If you don't need a password to access
your database on the development server, just omit the third argument.
If you want to use Propel instead of Doctrine, add
--orm=Propel when creating
the project with the
generate:project task. And if you don't want to use an
ORM, just pass
Now, create the frontend application by running the
$ php symfony generate:app frontend
Because the symfony shortcut file is executable, Unix users can replace all
occurrences of '
php symfony' by '
./symfony' from now on.
On Windows you can copy the '
symfony.bat' file to your project and use
symfony' instead of '
c:\> copy lib\vendor\symfony\data\bin\symfony.bat .
Based on the application name given as an argument, the
creates the default directory structure needed for the application under the
||The application configuration files|
||The application libraries and classes|
||The application code (MVC)|
||The global template files|
By default, the
generate:app task has secured our application from the two
most widespread vulnerabilities found on the web. That's right, symfony
automatically takes security measures on our behalf.
To prevent XSS attacks, output escaping has been enabled; and to prevent CSRF attacks, a random CSRF secret has been generated.
Of course, you can tweak these settings thanks to the following options:
--escaping-strategy: Enables or disables output escaping
--csrf-secret: Enables session tokens in forms
Before trying to access your newly created project, you need to set the write
permissions on the
log/ directories to the appropriate levels,
so that your web server can write to them:
$ chmod 777 cache/ log/
Tips for People using a SCM Tool
symfony only ever writes in two directories of a symfony project,
log/. The content of these directories should be ignored
by your SCM (by editing the
svn:ignore property if you use Subversion
This work is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported License license.