Official Symfony Best Practices Guide

Fabien Potencier, Symfony manager, a few days ago introduced a draft version of the best practices guide for developing applications using Symfony as a framework (remember, this is also a set of independent components).

We know how difficult it is to unlearn old habits and some tips shock you, but by following them you will be able to develop applications faster, make them less complex and at the same time more qualitative.
In any case, it is worth remembering that these are just recommendations and your team is not obliged to follow them. You can continue to use your approaches, symfony is flexible enough for any need and this will never change.

Under the cut, I wrote out the main theses, most of them are explained in detail inside the book, in some “shocking” places there is a small explanation besides the thesis.

• Always use Composer to install symfony.
• Create only one bundle for application logic. Bundle is an independent component that can be reused later. For example, your application has a UserBundle and a ProductBundle. Most likely the ProductBundle will not work correctly without the UserBundle, and this is not correct.
• The environment parameters (database, logs) and applications are described in the file app/config/parameters.yml .
• The default environment and application parameters are described in app/config/parameters.yml.dist .
• Parameters that do not change are described in constants (directly in app/config/parameters.yml ).
• The names of your services should be as short and simple as possible, ideally it should be one word (for example, slugger, geocoder).
• To define application services, use YAML.
• Using Doctrine ORM, define the schema using annotations. All configuration formats have the same performance.
• Application controllers should inherit Symfony\Bundle\FrameworkBundle\Controller\Controller , use annotations for routing and caching when possible.
• Do not use the @Template() annotation to customize the template used by the controller. The abstract is useful, but it works "magically", so it is recommended not to use it. Also the use of this annotation slows down your application by 21ms.
• Use automatic parameter conversion when it’s useful and convenient.
  

   /** * @Route("/{id}", name="admin_post_show") */ public function showAction(Post $post) 

  
  
• For templating, use Twig .
• Store your templates in the app/Resources/views/ directory.
• For each form, create a class.
• Add buttons in the template, not in the PHP code.
• For translations use the XLIFF format.
• Store translation files in app/Resources/translations/ .
• Always use keywords to translate instead of text. For example, not Username , but label.username .
• If your application has two authorization options, it is recommended to use one firewall, with the anonymous parameter enabled.
• Use bcrypt algorithm to hash user passwords.
• To automatically check access permissions on a URL, use access_control . When possible, use the @Security annotation. In more complex situations, use the security.context service.
• Store statics (assets) in the web/ directory.
• Use Assetic to handle statics, or other similar tools, such as GruntJS .
• When using frontend frameworks such as AngularJS , you must separate the frontend and backend into two projects.
• Write at least functional tests to verify that the pages of the application load successfully. Hardcode the URL of the page instead of using the UrlGenerator .