Since its release date, Symfony 2.0 installation process and tools required for it have been changed and updated for several times. In this article we tell you how to install and set up a Symfony2 application.
The default tool for creating a new Symfony 2 application at this moment is a command line tool of the same name. On Linux or Mac OX it can be installed from console:
$ sudo curl -LsS http://symfony.com/installer -o/usr/local/bin/symfony $ sudochmod a+x /usr/local/bin/symfony
The only required condition for this utility is PHP version 5.4 and higher. If you are still using PHP 5.3, in the article you will find the second variant of how to install and configure Symfony2.
Symfony command-line tool has several available execution commands. To see the list of available commands, write the following:
$ symfony listHere’s a list of available commands:
aboutdemohelplistnewself-updateselfupdate
symfony about command shows the information about the current installer version, and by the way, the same information can be found by launching symfony utility parameters. Symfony installer is updated regularly and new versions are frequently released. Once you have installed Symfony2 globally, you can update it with the help of self-update or selfupdate command (based on Composer).
$ symfony self-update $ symfony selfupdate
It is recommended to update it from time to time or to make an update right before using the console command. If you need more information concerning to the use of any console command you should use help command or --help option.
$ symfony help demo $ symfony demo --help
Symfony makes it easy to optimize and run demo-application (the PHP version greater 5.4 is required). To do so, run the following commands:
$ symfony demo new_directory_name $ cd new_directory_name/ $ app/console server:run
Next, open a web page http://localhost:8000 in your browser. A simple blog with front- and backend parts is available for you. And of course there is a working code sample you can examine, study and use.
Installing Symfony With The Help Of Basic Installer
To create new application, use command new. The command syntax is:
$ symfony new directory_name [version]
Directory name is necessary, version is optional. Here is an example of possible ways to run a command:
# To create project based on the most recent stable Symfony version available. $ symfony new my_project_name # If you point out the version, the recent stable release of this version will appear. $ symfony new my_project_name 2.3 $ symfony new my_project_name 2.5 $ symfony new my_project_name 2.6# It is possible to use a specific Symfony version. $ symfony new my_project_name 2.3.26 $ symfony new my_project_name 2.6.5 # Also, it is possible to use the recent LTS version, now it is 2.7 $ symfony new my_project_name lts
Now you should open file with Symfony2 configuration parameters my_project_name/app/config/parameters.yml and make the necessary changes to app settings.
Creating Applications Without Symfony Installer
Before the Symfony Installer was invented, projects were created with the help of the alternative installation method based on Composer. You can use this method if you like, but if you got PHP 5.3, this is unfortunately the one and only method you can use. First, install Composer globally. Creation of the Symfony applications based on the latest stable version is performed as follows:
$ composer create-project symfony/framework-standard-edition my_project_name
Or, if you need to create an application based on a specific version of Symfony:
$ composer create-project symfony/framework-standard-edition my_project_name "2.7.*"
The disadvantage of this method is that it doesn’t define “Its” as a version and you should use numbers to specify it.
After this command is executed, new project template and all necessary dependencies are downloaded. Now you need to enter parameters of the variables for file parameters.yml from console in interactive mode.
Built-in Web Server
Starting from PHP 5.4 the built-in web server appeared. It can be used to run Symfony application out-of-the-box. It is done using Symfony console which provides 4 commands for working with web server:
$ php app/console server:run $ php app/console server:start $ php app/console server:stop $ php app/console server:status
The difference between server:run and server:start is that the first command will remain in console after execution and you can stop server only by using Ctrl+C. The second runs web-server in the background and to stop it you need to execute server:stop.
By default web server runs the selected application at http://127.0.0.1:8000/
If you have several local Symfony projects, you can run them using different ports.
$ app/console server:run 127.0.0.1:8000 $ app/console server:run 127.0.0.1:8001 $ app/console server:run 127.0.0.1:8002
Read more about built-in web server on PHP website. If you use Apache or nginx for development, you have to set up virtual hosts for local development. You should take into account that built-in web server is used only for development and is not designed to be used in production mode.
Configuring Symfony
The framework is provided with visual configuration tester, which is available at http://localhost:8000/config.php. It checks the availability of all the necessary options for running the application and allows you to fill in or to change value of Symfony2 configuration through web-interface. Frankly speaking, I never fill in configuration through web-interface, I prefer to edit the file itself.
You can also check system configuration for Symfony with the help of a console script:
$ php app/check.php
This script checks the availability of all system requirements for Symfony and if something is missing, warns you and tells what to do. For example, some PHP extension Symfony needs may be missing, or necessary option may be absent. The console PHP version can have different configuration from the web-version. There is also a Symfony command for checking the security of your application:
$ app/console security:check
This command checks dependencies in composer.lock file. If you are using the vulnerable version of vendor, the script will tell you about it. Insecure vendors database is maintained by SensioLabs and is available at https://security.sensiolabs.org/database.
Permissions On Directories
Symfony folders app/cache and app/logs must have access permission for web-server and for the command line user. There are several ways to do it.
Using the same user for web-server and console
To do so, you should edit web server configuration and set its user to be the same as your console user. For example for Apache you use file httpd.conf (or apache2.conf).
Using ACL on a system that supports chmod +a
$ rm-rf app/cache/* $ rm-rf app/logs/* $ HTTPDUSER=`ps aux |grep-E'[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx'|grep-v root |head-1|cut -d\ -f1` $ sudochmod +a "$HTTPDUSER allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs $ sudochmod +a "`whoami` allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
If you get an error — try the next solution.
Using ACL on system that does not support chmod+a
$ HTTPDUSER=`ps aux |grep-E'[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx'|grep-v root |head-1|cut -d\ -f1` $ sudo setfacl -R-m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs $ sudo setfacl -dR-m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs
If it does not work, try to add -n option.
Without using ACL
If none of the previous solutions work for you, change the umask so that the cache and log directories will be group-writable or writable for all (it depends on whether web-service and command line users are in the same group or not). To achieve it put the following line in the beginning of the app/console, web/app.php and web/app_dev.php:
umask(0002); // This will let the access permission be 0775 // or umask(0000); // This will let the access permission be 0777
Symfony Distribution
Examples described above use a distribution called Symfony Standard Edition. It includes a full-functional Symfony-application skeleton and composer.json with all necessary default configurations. This distribution is the most popular one and is the best choice for creation of a new application. There are also other distributions:
- Symfony CMF Standard Edition is a custom distribution based on Symfony CMF, makes it easier to add CMS functionality to your project.
- Symfony REST Edition is a distribution which helps you to organize RESTful API server based on Symfony and FOSRestBundle.
Symfony and its components are updated all the time. You can use this command to update your project:
$ composer updateYou shouldn’t encounter any problems with code unless you’re using the latest version. To run the latest version (e.g. from 2.* to 3.0) you should read all the necessary specifications. If any bundle will depend on specific Symfony version, Composer will warn you and won’t work until the problem is solved
To keep up with all updates and changes, follow the official Symfony blog .
You can check out all version update specifications from a Git repository, UPDATE folder..
Other tips for working on a new Symfony-application
If you finished with all Symfony installation requirements and already have the core of your application, you can only fill it with business logic and expand it using different bundles. If you are a beginner than certainly you should use Symfony2 documentation from the official web site. Check the CookBook too.
After creating a new project I make some additional adjustments. I correct file PHPUnit config, take off some directories and files which won’t be testable, e.g. fixture classes (if you don’t do it, they will impact the test coverage). If a project is available on GitHub as an open-source one, I connect it to code quality control services. There is also Insight service by SensioLabs, I wrote about in that article. As an experiment I decided to check out a clean Symfony Standard Edition, to know what it discovers in the out-of-the-box Symfony code. I created a clean new Symfony project using a command:
$ symfony new test
The current version was 2.7.1. After that, without making any change, I sent my project to Git repository and made a check using SensioLabs Insight. And here’s the result.
Errors were found, let’s analyze them.
For sure, you need to register your passphrase. But here, in this case, it’s useless. You can just change the default value, which will be used when someone open your application out-of-the-box. It doesn’t mean that the same value will be used on a production server. However, to take away this warning you should replace the standard passphrase ThisTokenIsNotSoSecretChangeIt with your own passphrase.
Symfony got invalid composer.json because there is no description field which is required.
Also config.php is not deleted, it is used to check Symfony web environment configurations parameters. Insight tells you to delete the commented and unused code. One more advice is to change the name of the cookie for PHP session, it can be specified in the file config.yml in the framework.session.name field.
Informative messages are the next ones. Insight advices you to delete all htaccess files, to set all the necessary parameters in global web server configurations. Also to customize error pages 404 and 500. It is recommended to specify supported methods for each action (route) in controller using annotations. And don’t forget to change the default favicon.
These are advices given us by robot. Some of them are controversial but if they exist, it means that somebody spent some time to add them to the base. In any case, they won’t hurt.
