- How Symfony2 differs from symfony1
- How Symfony2 differs from symfony1
- Directory Structure
- The app/ Directory
- The src/ Directory
- The vendor/ Directory
- The web/ Directory
- How to Override Symfony’s default Directory Structure
- How to Override Symfony’s default Directory Structure
- Override the cache Directory
- Override the logs Directory
- Override the Templates Directory
- Override the web Directory
- Override the vendor Directory
How Symfony2 differs from symfony1
Warning: You are browsing the documentation for Symfony 2.0, which is no longer maintained.
Read the updated version of this page for Symfony 6.3 (the current stable version).
How Symfony2 differs from symfony1
The Symfony2 framework embodies a significant evolution when compared with the first version of the framework. Fortunately, with the MVC architecture at its core, the skills used to master a symfony1 project continue to be very relevant when developing in Symfony2. Sure, app.yml is gone, but routing, controllers and templates all remain.
This chapter walks through the differences between symfony1 and Symfony2. As you’ll see, many tasks are tackled in a slightly different way. You’ll come to appreciate these minor differences as they promote stable, predictable, testable and decoupled code in your Symfony2 applications.
So, sit back and relax as you travel from «then» to «now».
Directory Structure
When looking at a Symfony2 project — for example, the Symfony2 Standard Edition — you’ll notice a very different directory structure than in symfony1. The differences, however, are somewhat superficial.
The app/ Directory
In symfony1, your project has one or more applications, and each lives inside the apps/ directory (e.g. apps/frontend ). By default in Symfony2, you have just one application represented by the app/ directory. Like in symfony1, the app/ directory contains configuration specific to that application. It also contains application-specific cache, log and template directories as well as a Kernel class ( AppKernel ), which is the base object that represents the application.
Unlike symfony1, almost no PHP code lives in the app/ directory. This directory is not meant to house modules or library files as it did in symfony1. Instead, it’s simply the home of configuration and other resources (templates, translation files).
The src/ Directory
Put simply, your actual code goes here. In Symfony2, all actual application-code lives inside a bundle (roughly equivalent to a symfony1 plugin) and, by default, each bundle lives inside the src directory. In that way, the src directory is a bit like the plugins directory in symfony1, but much more flexible. Additionally, while your bundles will live in the src/ directory, third-party bundles may live in the vendor/bundles/ directory.
To get a better picture of the src/ directory, let’s first think of a symfony1 application. First, part of your code likely lives inside one or more applications. Most commonly these include modules, but could also include any other PHP classes you put in your application. You may have also created a schema.yml file in the config directory of your project and built several model files. Finally, to help with some common functionality, you’re using several third-party plugins that live in the plugins/ directory. In other words, the code that drives your application lives in many different places.
In Symfony2, life is much simpler because all Symfony2 code must live in a bundle. In the pretend symfony1 project, all the code could be moved into one or more plugins (which is a very good practice, in fact). Assuming that all modules, PHP classes, schema, routing configuration, etc were moved into a plugin, the symfony1 plugins/ directory would be very similar to the Symfony2 src/ directory.
Put simply again, the src/ directory is where your code, assets, templates and most anything else specific to your project will live.
The vendor/ Directory
The vendor/ directory is basically equivalent to the lib/vendor/ directory in symfony1, which was the conventional directory for all vendor libraries and bundles. By default, you’ll find the Symfony2 library files in this directory, along with several other dependent libraries such as Doctrine2, Twig and Swiftmailer. 3rd party Symfony2 bundles usually live in the vendor/bundles/ .
The web/ Directory
Not much has changed in the web/ directory. The most noticeable difference is the absence of the css/ , js/ and images/ directories. This is intentional. Like with your PHP code, all assets should also live inside a bundle. With the help of a console command, the Resources/public/ directory of each bundle is copied or symbolically-linked to the web/bundles/ directory. This allows you to keep assets organized inside your bundle, but still make them available to the public. To make sure that all bundles are available, run the following command:
$ php app/console assets:install web
How to Override Symfony’s default Directory Structure
Warning: You are browsing the documentation for Symfony 3.4, which is no longer maintained.
Read the updated version of this page for Symfony 6.3 (the current stable version).
How to Override Symfony’s default Directory Structure
Symfony automatically ships with a default directory structure. You can override this directory structure to create your own. The default directory structure is:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
your-project/ ├─ app/ │ ├─ config/ │ ├─ Resources/ │ │ └─ views/ │ └─ . ├─ bin/ │ └─ . ├─ src/ │ └─ . ├─ tests/ │ └─ . ├─ var/ │ ├─ cache/ │ ├─ logs/ │ └─ . ├─ vendor/ │ └─ . └─ web/ ├─ app.php └─ .
Override the cache Directory
You can change the default cache directory by overriding the getCacheDir() method in the AppKernel class of your application:
1 2 3 4 5 6 7 8 9 10 11 12
// app/AppKernel.php // . class AppKernel extends Kernel < // . public function getCacheDir() < return dirname(__DIR__).'/var/'.$this->environment.'/cache'; > >
In this code, $this->environment is the current environment (i.e. dev ). In this case you have changed the location of the cache directory to var//cache .
You should keep the cache directory different for each environment, otherwise some unexpected behavior may happen. Each environment generates its own cached configuration files, and so each needs its own directory to store those cache files.
Override the logs Directory
Overriding the logs directory is the same as overriding the cache directory. The only difference is that you need to override the getLogDir() method:
1 2 3 4 5 6 7 8 9 10 11 12
// app/AppKernel.php // . class AppKernel extends Kernel < // . public function getLogDir() < return dirname(__DIR__).'/var/'.$this->environment.'/logs'; > >
Here you have changed the location of the directory to var//logs .
Override the Templates Directory
If your templates are not stored in the default app/Resources/views/ directory, use the twig.default_path configuration option to define your own templates directory (use twig.paths for multiple directories):
# app/config/config.yml twig: # . default_path: "%kernel.project_dir%/templates"
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
container xmlns="http://symfony.com/schema/dic/services" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:twig="http://symfony.com/schema/dic/twig" xsi:schemaLocation="http://symfony.com/schema/dic/services https://symfony.com/schema/dic/services/services-1.0.xsd http://symfony.com/schema/dic/twig https://symfony.com/schema/dic/twig/twig-1.0.xsd"> twig:config> twig:default-path>%kernel.project_dir%/templates twig:default-path> twig:config> container>
// app/config/config.php $container->loadFromExtension('twig', [ 'default_path' => '%kernel.project_dir%/templates', ]);
Override the web Directory
If you need to rename or move your web directory, the only thing you need to guarantee is that the path to the var directory is still correct in your app.php and app_dev.php front controllers. If you renamed the directory, you’re fine. But if you moved it in some way, you may need to modify these paths inside those files:
require_once __DIR__.'/../path/to/app/autoload.php';
You also need to change the extra.symfony-web-dir option in the composer.json file:
< ". ": ". ", "extra": < ". ": ". ", "symfony-web-dir": "my_new_web_dir" > >
Some shared hosts have a public_html web directory root. Renaming your web directory from web to public_html is one way to make your Symfony project work on your shared host. Another way is to deploy your application to a directory outside of your web root, delete your public_html directory, and then replace it with a symbolic link to the web in your project.
If you use the AsseticBundle, you need to configure the read_from option to point to the correct web directory:
# app/config/config.yml # . assetic: # . read_from: '%kernel.project_dir%/../public_html'
1 2 3 4 5 6 7 8 9 10 11 12 13 14
container xmlns="http://symfony.com/schema/dic/services" xmlns:assetic="http://symfony.com/schema/dic/assetic" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://symfony.com/schema/dic/services https://symfony.com/schema/dic/services/services-1.0.xsd http://symfony.com/schema/dic/assetic https://symfony.com/schema/dic/assetic/assetic-1.0.xsd"> assetic:config read-from="%kernel.project_dir%/../public_html"/> container>
// app/config/config.php // . $container->loadFromExtension('assetic', [ // . 'read_from' => '%kernel.project_dir%/../public_html', ]);
Now you just need to clear the cache and dump the assets again and your application should work:
$ php bin/console cache:clear --env=prod $ php bin/console assetic:dump --env=prod --no-debug
Override the vendor Directory
To override the vendor directory, you need to introduce changes in the app/autoload.php and composer.json files.
The change in the composer.json will look like this:
< "config": < "bin-dir": "bin", "vendor-dir": "/some/dir/vendor" >, >
Then, update the path to the autoload.php file in app/autoload.php :
// app/autoload.php // . $loader = require '/some/dir/vendor/autoload.php';
This modification can be of interest if you are working in a virtual environment and cannot use NFS — for example, if you’re running a Symfony application using Vagrant/VirtualBox in a guest operating system.