Document Updated make:entity command

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,9 @@
+<!--
+
+If your pull request fixes a BUG, use the oldest maintained branch that contains
+the bug (see https://symfony.com/roadmap for the list of maintained branches).
+
+If your pull request documents a NEW FEATURE, use the same Symfony branch where
+the feature was introduced (and `master` for features of unreleased versions).
+
+-->

_build/_theme/_templates/layout.html

@@ -1,13 +1,15 @@
 {% extends '!layout.html' %}
 
-{% set css_files = ['https://symfony.com/css/compiled/v5/all.css?v=4'] %}
+{% set css_files = ['./assets/css/app.css', './assets/css/doc.css'] %}
 {# make sure the Sphinx stylesheet isn't loaded #}
 {% set style = '' %}
 {% set isIndex = pagename is index %}
 
 {% block extrahead %}
 {# add JS to support tabs #}
-<script src="https://symfony.com/js/v5/all.js?v=4"></script>
+<script src="./assets/js/manifest.js"></script>
+<script src="./assets/js/app.js"></script>
+<script src="./assets/js/doc.js"></script>
 
 {# pygment's styles are still loaded, undo some unwanted styles #}
 <style>

_includes/_annotation_loader_tip.rst.inc

@@ -0,0 +1,19 @@
+.. note::
+
+    In order to use the annotation loader, you should have installed the
+    ``doctrine/annotations`` and ``doctrine/cache`` packages with Composer.
+
+.. tip::
+
+    Annotation classes aren't loaded automatically, so you must load them
+    using a class loader like this::
+
+        use Composer\Autoload\ClassLoader;
+        use Doctrine\Common\Annotations\AnnotationRegistry;
+
+        /** @var ClassLoader $loader */
+        $loader = require __DIR__.'/../vendor/autoload.php';
+
+        AnnotationRegistry::registerLoader([$loader, 'loadClass']);
+
+        return $loader;

best_practices/business-logic.rst

@@ -38,14 +38,12 @@ Services: Naming and Configuration
 by Symfony's Service Container to manage services with minimal configuration. It
 reads the type-hints on your constructor (or other methods) and automatically
 passes the correct services to each method. It can also add
-:doc:`service tags </service_container/tags>` to the services needed them, such
+:doc:`service tags </service_container/tags>` to the services needing them, such
 as Twig extensions, event subscribers, etc.
 
 The blog application needs a utility that can transform a post title (e.g.
 "Hello World") into a slug (e.g. "hello-world") to include it as part of the
-post URL. Let's create a new ``Slugger`` class inside ``src/Utils/``:
-
-.. code-block:: php
+post URL. Let's create a new ``Slugger`` class inside ``src/Utils/``::
 
     // src/Utils/Slugger.php
     namespace App\Utils;
@@ -69,9 +67,7 @@ simply ``Slugger::class`` if the class is already imported in your code).
     case, use a snake case id).
 
 Now you can use the custom slugger in any other service or controller class,
-such as the ``AdminController``:
-
-.. code-block:: php
+such as the ``AdminController``::
 
     use App\Utils\Slugger;
 
@@ -152,9 +148,7 @@ PHP and annotations.
     Use annotations to define the mapping information of the Doctrine entities.
 
 Annotations are by far the most convenient and agile way of setting up and
-looking for mapping information:
-
-.. code-block:: php
+looking for mapping information::
 
     namespace App\Entity;
 
@@ -166,7 +160,7 @@ looking for mapping information:
      */
     class Post
     {
-        const NUM_ITEMS = 10;
+        const NUMBER_OF_ITEMS = 10;
 
         /**
          * @ORM\Id
@@ -233,9 +227,7 @@ the following command to install the Doctrine fixtures bundle:
     $ composer require "doctrine/doctrine-fixtures-bundle"
 
 Then, this bundle is enabled automatically, but only for the ``dev`` and
-``test`` environments:
-
-.. code-block:: php
+``test`` environments::
 
     // config/bundles.php
 
@@ -275,6 +267,6 @@ Next: :doc:`/best_practices/controllers`
 .. _`full definition`: https://en.wikipedia.org/wiki/Business_logic
 .. _`Doctrine project`: http://www.doctrine-project.org/
 .. _`fixture class`: https://symfony.com/doc/current/bundles/DoctrineFixturesBundle/index.html#writing-simple-fixtures
-.. _`PSR-1`: http://www.php-fig.org/psr/psr-1/
-.. _`PSR-2`: http://www.php-fig.org/psr/psr-2/
+.. _`PSR-1`: https://www.php-fig.org/psr/psr-1/
+.. _`PSR-2`: https://www.php-fig.org/psr/psr-2/
 .. _`PHP-CS-Fixer`: https://github.com/FriendsOfPHP/PHP-CS-Fixer

best_practices/configuration.rst

@@ -42,6 +42,13 @@ they have nothing to do with the application's behavior. In other words, your
 application doesn't care about the location of your database or the credentials
 to access to it, as long as the database is correctly configured.
 
+.. caution::
+
+    Beware that dumping the contents of the ``$_SERVER`` and ``$_ENV`` variables
+    or outputting the ``phpinfo()`` contents will display the values of the
+    environment variables, exposing sensitive information such as the database
+    credentials.
+
 .. _best-practices-canonical-parameters:
 
 Canonical Parameters
@@ -96,20 +103,20 @@ to control the number of posts to display on the blog homepage:
 
     # config/services.yaml
     parameters:
-        homepage.num_items: 10
+        homepage.number_of_items: 10
 
 If you've done something like this in the past, it's likely that you've in fact
 *never* actually needed to change that value. Creating a configuration
 option for a value that you are never going to configure just isn't necessary.
 Our recommendation is to define these values as constants in your application.
-You could, for example, define a ``NUM_ITEMS`` constant in the ``Post`` entity::
+You could, for example, define a ``NUMBER_OF_ITEMS`` constant in the ``Post`` entity::
 
     // src/Entity/Post.php
     namespace App\Entity;
 
     class Post
     {
-        const NUM_ITEMS = 10;
+        const NUMBER_OF_ITEMS = 10;
 
         // ...
     }
@@ -124,13 +131,11 @@ Constants can be used for example in your Twig templates thanks to the
 .. code-block:: html+twig
 
     <p>
-        Displaying the {{ constant('NUM_ITEMS', post) }} most recent results.
+        Displaying the {{ constant('NUMBER_OF_ITEMS', post) }} most recent results.
     </p>
 
 And Doctrine entities and repositories can now easily access these values,
-whereas they cannot access the container parameters:
-
-.. code-block:: php
+whereas they cannot access the container parameters::
 
     namespace App\Repository;
 
@@ -139,7 +144,7 @@ whereas they cannot access the container parameters:
 
     class PostRepository extends EntityRepository
     {
-        public function findLatest($limit = Post::NUM_ITEMS)
+        public function findLatest($limit = Post::NUMBER_OF_ITEMS)
         {
             // ...
         }

best_practices/controllers.rst

@@ -98,9 +98,7 @@ What does the Controller look like
 ----------------------------------
 
 Considering all this, here is an example of what the controller should look like
-for the homepage of our app:
-
-.. code-block:: php
+for the homepage of our app::
 
     namespace App\Controller;
 
@@ -154,9 +152,7 @@ to automatically query for an entity and pass it as an argument to your controll
     Use the ParamConverter trick to automatically query for Doctrine entities
     when it's simple and convenient.
 
-For example:
-
-.. code-block:: php
+For example::
 
     use App\Entity\Post;
     use Symfony\Component\Routing\Annotation\Route;
@@ -187,9 +183,7 @@ The above example works without any configuration because the wildcard name
 ``{id}`` matches the name of the property on the entity. If this isn't true, or
 if you have even more complex logic, the easiest thing to do is just query for
 the entity manually. In our application, we have this situation in
-``CommentController``:
-
-.. code-block:: php
+``CommentController``::
 
     /**
      * @Route("/comment/{postSlug}/new", name="comment_new")
@@ -208,9 +202,7 @@ the entity manually. In our application, we have this situation in
     }
 
 You can also use the ``@ParamConverter`` configuration, which is infinitely
-flexible:
-
-.. code-block:: php
+flexible::
 
     use App\Entity\Post;
     use Sensio\Bundle\FrameworkExtraBundle\Configuration\ParamConverter;

best_practices/forms.rst

@@ -80,9 +80,7 @@ makes them easier to re-use later.
 The Symfony Form component allows you to add buttons as fields on your form.
 This is a nice way to simplify the template that renders your form. But if you
 add the buttons directly in your form class, this would effectively limit the
-scope of that form:
-
-.. code-block:: php
+scope of that form::
 
     class PostType extends AbstractType
     {
@@ -164,9 +162,7 @@ can control *how* the form renders at a global level using form theming.
 Handling Form Submits
 ---------------------
 
-Handling a form submit usually follows a similar template:
-
-.. code-block:: php
+Handling a form submit usually follows a similar template::
 
     public function new(Request $request)
     {
@@ -175,9 +171,9 @@ Handling a form submit usually follows a similar template:
         $form->handleRequest($request);
 
         if ($form->isSubmitted() && $form->isValid()) {
-            $em = $this->getDoctrine()->getManager();
-            $em->persist($post);
-            $em->flush();
+            $entityManager = $this->getDoctrine()->getManager();
+            $entityManager->persist($post);
+            $entityManager->flush();
 
             return $this->redirectToRoute('admin_post_show', [
                 'id' => $post->getId()