Mastering Symfony: Orchestrate the designing, development, testing, and deployment of web applications with Symfony

I don't like to talk about features, numbers, and statistics. I don't do detailed comparisons between frameworks as well. Instead, I'd like to share an experience with you. As a PHP developer, I worked for the New Zealand Herald newspaper for a while. Sure, they are not the oldest newspaper in the world, but in 2013, they celebrated their 150th anniversary, which makes it very clear that over the years, they have created layers and layers of code on top of each other and used or tried almost every framework and technology in their website and internal newspaper systems. Their repositories contain tons of legacy codes written in different languages. You won't believe it if I say different parts of their system were implemented in Perl, Java, C#, ColdFusion, and PHP, and there was (perhaps, still is?) an API layer that acts as a communicating bridge between all of them.

Due to many factors such as maintenance costs, in the past few years, people at the NZ Herald decided to migrate their entire applications and services into one integrated system; something that is reliable, efficient, and easy to expand and maintain. Having experienced many frameworks already, the solution architects at NZ Herald chose Symfony as their framework.

They realized that those colorful graphs and pretty pictures that compare benchmarking results for various frameworks are worth nothing when it comes to real-life problems. They experienced the efficiency of various frameworks in the day-to-day challenges and understood that no matter how fast the development speed might look at the beginning, the most important thing is how reliable it actually is and how much it costs when it comes to maintaining the project. They simply put a price tag on many factors including performance, abstraction, decouplement, portability, integration, and above all, how well organized the code base will be after spending several years and using several men for the development. Guess what? Symfony beat every PHP framework out there.

What I'm trying to say is that Symfony is not just another tool for web app or website development. It is a new culture for web development, a solid reliable foundation that you can build your project on top of with peace of mind. I call it a new culture because for the first time, I see that it has made various PHP communities talk to each other and work together. I believe this is the most important PHP achievement ever. In the years to come, we will see more about this movement.

There are four ways to install the Symfony framework:

The easiest way is to download the Symfony installer and make it publicly accessible via the following commands:

$ sudo curl -LsS https://symfony.com/installer -o /usr/local/bin/symfony
$ sudo chmod a+x /usr/local/bin/symfony

Now create a new project simply by running the following command:

$ symfony new mava

As this command shows, it will ask the Symfony installer to create a new folder in the current path called mava, and when you hit enter, you will see that the Symfony source code will be downloaded to that folder:

In the list of things that we can do after installation is running the application immediately, without installing a virtual host. Thanks to the PHP built-in web server, we can run it via Symfony's console and browse the mava app at port 8000 on localhost:

$ bin/console server:run

The following screenshot shows how http://localhost:8000 looks like in your favourite browser:

Composer is a dependency manager application that can be used to install PHP packages.

Some developers prefers Composer, not just because it is easy to use, but it is far more efficient when it comes to keeping track of the project dependencies. In fact, the main reason for creating Composer was to provide a reliable and consistent environment to develop PHP projects.

Imagine a team of PHP developers who work on the same project using various libraries and resources. Sometimes, it can be a nightmare if updating an existing library or installing a new one crashes the code of another developer in the team. Someone should be in charge of tracking all dependencies and controlling the updates and installs to make sure that the project development runs smoothly. In the past, that person used to be the lead developer, but thanks to Composer, the dependency management during development, staging, and production phases is handled automatically by Composer.

Let's get started by downloading Composer if you don't have it already:

$ curl -sS https://getcomposer.org/installer | php

$ php -r "readfile('https://getcomposer.org/installer');" | php

Move it to your /usr/local/bin folder so that it is accessible from everywhere in your machine:

$ sudo mv composer.phar /usr/local/bin/composer

Composer is just a manager. It does not store any libraries or packages in itself. However, it works very closely with a package repository called Packagist to make sure that it gets the right packages with the correct dependencies. To do so, Packagist talks to Composer via a configuration file called composer.json, which contains many settings including dependency information.

Symfony Standard Edition is a package saved in https://packagist.org/. Go to the website and search symfony and you will see the Symfony framework along with a list of Symfony components as the search result:

In this book, we will deal mainly with three Composer commands:

Let's see how to install the Symfony Standard Edition package via Composer.

$ composer self-update

Installing Symfony via Composer

Fire a terminal and go to /var/www. I chose to install Symfony there to keep it simple and avoid different usernames and folders. Create a new folder called mava and set the ownership to yourself:

$ cd /var/www
$ sudo mkdir mava
$ sudo chown -hR <YourUserName>:<YourUserName> mava

Now type the following command:

$ composer create-project symfony/symfony mava/

As you can see in the following image, version 3.0.1 is the latest stable version. We can always choose a long-term support version if we want to take a conservative approach toward a project or we can choose the development version if we are crazy enough to ask for everything cutting-edge. Normal people like me always choose the latest stable version. In other words, it is a trade-off between the latest features and longest support:

If the installation process runs smoothly, you will see a bunch of packages being downloaded and installed to the /mava directory:

Using version ^3.0 for symfony/symfony
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing psr/log (1.0.0)
    Loading from cache

  - Installing doctrine/lexer (v1.0.1)
    Loading from cache

  - Installing doctrine/annotations (v1.2.7)
    Loading from cache

  - Installing doctrine/collections (v1.3.0)
    Loading from cache

  - Installing doctrine/cache (v1.6.0)
    Loading from cache

  - Installing doctrine/inflector (v1.1.0)
    Loading from cache

  - Installing doctrine/common (v2.6.1)
    Loading from cache
etc...

After Composer has finished downloading and unpacking all the dependencies, it will ask a couple of questions including sample demo, database settings, and mailer settings. Just accept the default answer by pushing Enter:

Creating the "app/config/parameters.yml" file
Some parameters are missing. Please provide them.
database_driver (pdo_mysql):
database_host (127.0.0.1):
database_port (null):
database_name (symfony):
database_user (root):
database_password (null):
mailer_transport (smtp):
mailer_host (127.0.0.1):
mailer_user (null):
mailer_password (null):
locale (en):
secret (ThisTokenIsNotSoSecretChangeIt):
debug_toolbar (true):
debug_redirects (false):
use_assetic_controller (true):

These settings will be saved in the app/config/parameters.yml file, and we always have a chance to change them later. If everything was okay, at the end, the cache will be cleared and the default assets will be installed as follows:

The road map

If you are concerned about how long your choice of the Symfony version is going to be supported, visit the http://symfony.com/roadmap page, scroll down, enter the version number, and push the Check button. You will see a detailed description about the support duration:

Checking the installation

To make sure that Symfony installed properly, first run the PHP built-in server:

$ bin/console server:run

Then, visit the following link in your browser:

http://localhost:8000/config.php

If you see the following image, then you are good to go. You can ignore the suggested recommendations for now:

In this chapter, we read about the practicality of Symfony and the basic reasons why big companies are using it. We read about the Symfony road map and its potential. We ran the built-in web server to be able to see our Symfony instance. We saw how to use Composer to install Symfony and how to check the installation afterward.

In the next chapter, I will walk you through the request/response life cycle and show you how to use Symfony to generate code and shape it based on your needs.