Symfony best practices

A couple months ago the Symfony creator Fabien Potencier, alongside Ryan Weaver and Javier Eguiluz have created a handbook called “Symfony Best Practices“.

The reason of this handbook was due to the community has created an unofficial set of recommendations for developing Symfony applications. Unfortunately, a lot of these recommendations are unneeded for web applications.

Here, a summary of these best practices:

Projects creation

Use the Symfony installer.

You can read about it in an earlier post.

About bundles:

Create only one bundle called AppBundle for your application logic


Define the infrastructure-related configuration options in the app/config/parameters.yml file.

Define all your application’s parameters in the app/config/parameters.yml.dist file.

Define the application behavior related configuration options in the app/config/config.yml file.

Organizing our Business Logic

Services: Name and Format

The name of your application’s services should be as short as possible, but unique enough that you can search your project for the service if you ever need to.

Use the YAML format to define your own services.

Don’t define parameters for the classes of your services.

Using a Persistence Layer:

Use annotations to define the mapping information of the Doctrine entities.


Make your controller extend the FrameworkBundle base Controller and use annotations to configure routing, caching and security whenever possible.

Routing configuration:

Don’t use the @Template() annotation to configure the template used by the controller.

Use the ParamConverter trick to automatically query for Doctrine entities when it’s simple and convenient.


Use Twig templating format for your templates.

Store all your application’s templates in app/Resources/views/ directory.

Twig extensions:

Define your Twig extensions in the AppBundle/Twig/ directory and configure them using the app/config/services.yml file.


Define your forms as PHP classes.

Add buttons in the templates, not in the form classes or the controllers.


Use the XLIFF format for your translation files.

Store the translation files in the app/Resources/translations/ directory.

Always use keys for translations instead of content strings.


Unless you have two legitimately different authentication systems and users (e.g. form login for the main site and a token system for your API only), we recommend having only one firewall entry with the anonymous key enabled.

Use the bcrypt encoder for encoding your users’ passwords.

Web Assets

Store your assets in the web/ directory.

Use Assetic to compile, combine and minimize web assets, unless you’re comfortable with frontend tools like GruntJS.


Define a functional test that at least checks if your application pages are successfully loading.

Hardcode the URLs used in the functional tests instead of using the URL generator.

Well, a great handbook to follow up, but of course, this are “best practices” and they are not a must.