The Symfony documentation

The documentation strategy (instead of a large book, the Symfony2 documentation is split into small chapters about specific topics); Fabien Potencier http://symfony.com/blog/symfony2-documentation

i think, it would be very important to also create and provide the symfony2 docs in "book" form -> pdf / epub.

why?

• no, we don't have a internet connection everywhere
• ebook reader doesn't handle rst
• for people who want to print it out
• ...

of course the format of the symfony docs opens all doors to do it myself (http://symfony.com/doc/2.0/contributing/documentation/format.html), i only need Sphinx and then i can create pdfs. wait, i have to install rst2pdf. easy

ImportError: No module named setuptools
http://www.happylife.sg/index.php/2010/04/25/importerror-no-module-named-setuptools/

and so on...

what i want to say is, that its not a 5 minute act to create a pdf and if i just want to learn a framework it doesn't mean i want to learn how to convert rst in pdf (or have the time to).

it would be a great thing, to add the conversion to pdf/epub to the docment website build/deploy process, so the problem is solved one time and the users of symfony can focus on symfony instead of building pdf files.

before anyone answer with "we don't need that", "it is ok how it is",... don't forget we are talking about digital/virtual stuff, so if i would ask to print a book in paperback insted of hardcover this would be a decision where only one way would be possible course you can if you look at the costs but in the virtual world we just can deploy both with nearly no overhead. we don't need to choose between this or that way, we can take both ways at the same time.

to provide a one (all the docs) or three (book, cookbook, components) file(s) doc would really help to use it mobile.

please help the developers to keep focus on developing with php and symfony not sphinx and other stuff.

Hello,

there are lots of users using doctrine:generate:entities nowadays. This must stop.

Symfony should provide its large user base decent article on designing/modelling entities in a proper way, with business methods and as few setters as possible, not by generating them from database. Such generated entities lead to a tediously known anemic domain model, something that does more harm than good: breaks encapsulation and completely undermines the purpose of ORM. It'd probably be even better to not use ORM at all and use DBAL directly, the result would be very similar without runtime overhead.

Note that Doctrine 3.0 will remove support for code generation entirely, so the better we educate the users, the better.

This issue is a direct response to discussion in doctrine/DoctrineBundle#729.

Thanks.

This is the proposal for the new Symfony Console Style Guide. Please review it as soon as you can, because the schedule is pretty tight. We'd like to update most of the commands for Symfony 2.6 version.

Download Symfony Console Style Guide (PDF, 89 KB)

| Q | A | | --- | --- | | Doc fix? | [yes] | | New docs? | [no] | | Applies to | [all] | | Fixed tickets | [] |

After upgrading to Varnish 4.0, I've noticed the documentation was not really up-to-date anymore:

• according to https://www.varnish-cache.org/docs/4.0/whats-new/upgrading.html#req-not-available-in-vcl-backend-response,

  beresp is available in vcl_backend_response

• according to https://www.varnish-cache.org/docs/4.0/whats-new/upgrading.html#hit-for-pass-objects-are-created-using-beresp-uncacheable,

  hit_for_pass objects are created via beresp.uncacheable

Would this addition be enough in order to consider the documentation up-to-date in accordance with Varnish 4.0 upgrading guidelines?

The other day, @lyrixx and I were talking about Twig template naming and locations and he asked if we could update the official Symfony documentation to use the new template syntax.

Imagine that your project has the following four templates:

your-project/
 ├─ app/
 │  └─ Resources
 │     └─ views/
 │        └─ template1.twig
 ├─ src/
 │  └─ Acme/
 │     └─ Bundle/
 │        └─ DemoBundle/
 │           └─ Resources
 │              └─ views/
 │                 ├─ template2.twig
 │                 └─ Default/
 │                    ├─ template3.twig
 │                    └─ common/
 │                       └─ template4.twig
 ├─ vendor/
 └─ web/

Using the traditional syntax, you have four different formats to explain:

::template1.twig
AcmeDemoBundle::template2.twig
AcmeDemoBundle:Default:template3.twig
AcmeDemoBundle:Default:common/template4.twig

Using the new namespaced syntax everything is straightforward:

template1.twig
@AcmeDemoBundle/template2.twig
@AcmeDemoBundle/Default/template3.twig
@AcmeDemoBundle/Default/common/template4.twig

With the new syntax you only have to write the path from Resources/views/, without thinking if the template is associated with a controller or if it's stored in a subdirectory. Everything is much easier to explain, specially for Symfony newcomers.

Forgetting for a moment about the colossal effort that would be needed to update all the documentation, what do you think about this proposal?

In the manual page How to Work with multiple Entity Managers and Connections for Symfony 4, we can see in the end the following code snippet:

        // Retrieves a repository managed by the "customer" em
        $customers = $this->getDoctrine()
            ->getRepository(Customer::class, 'customer')
            ->findAll()
        ;

Using the ORM configuration code indicated in the beginning of that document, where the Customer entity is mapped to the 'customer' entity manager, the 'customer' parameter for the getRepository() method is ignored. As so, this last code about repository calls should be updated.

Also, I suggest to add the code on how to use multiple entity managers for a single Entity, or to add a note that it's not possible if that's the case.

• Updated service_container.rst to include php-fluent-di
• Updated _build/conf.py to include codeblock for php-fluent-di
• Updated existing di resource loading to refer to latest sf 4.2 excludes

Remaining: need to update the rest of the service_container files

Signed-off-by: RJ Garcia [email protected]

Correct me if I am wrong, but Symfony2 documentation does not specify if filename of Twig template should be written in camelCase (articleDetails.html.twig) or with underscores (article_details.html.twig).

In Symfony naming conventions is note:

Use alphanumeric characters and underscores for file names;

But in Including other templates doc section is mentioned template filename in camel case: articleDetails.html.twig

In the majority of open source bundles there are underscores used in template filenames (for example Sonata, KnpPaginatorBundle,MopaBootstrapBundle, GenemuFormBundle, AdmingeneratorGeneratorBundle), but some use camelCase filenames (FOSFacebookBundle) or they mix it together (for example FOSUserBundle, FOSMessageBundle).

So what`s the recommended way? This should be clearly explained in documentation.

Also Twig coding standars should be linked somewhere in documentation: http://twig.sensiolabs.org/doc/coding_standards.html

Question:

What if you do container->get() some services in tests.

Answer:

The proper solution would be to create a public alias for the service you want to test in the test environment only:

# app/config/config_test.yml
services:
    test_alias.AppBundle\Service\MyService:
        alias: 'AppBundle\Service\MyService'
        public: true # require on SF4, where everything is private by default

Then, you would actually fetch test_alias.AppBundle\Service\MyService out of the container in your unit test. It's a nice idea too: you only need to expose your service as public in the test environment.

| Q | A | | --- | --- | | Doc fix? | no | | New docs? | yes | | Applies to | 2.1 | | Fixed tickets | #881 |

I added a quick reference to https://github.com/symfony/symfony/blob/2.1/src/Symfony/Bridge/Doctrine/HttpFoundation/DbalSessionHandler.php basing it almost completely on the PDO Session handler

I'm merging it into this branch, even though it's not mantained anymore, because this is where this option became available to use for session storage

Documentation for symfony/symfony#20863 and symfony/symfony#20858. PR symfony/symfony#20863 is still being written/finalized, so this is a WIP following that PR at this time. Resolves #7256.

Related to https://github.com/symfony/symfony/pull/48669.

:information_source: I added a namespace to the enum in the example to kind of remind that quadruple backslashes must be used in the expression to use the namespaced enum.

When creating a form to edit an already persisted item, the file form type still expects a :class:Symfony\\Component\\HttpFoundation\\File\\File instance.

The file form type is not mapped so it doesn't matter.

$product->setBrochureFilename() this expects a string, not a File instance.

Actually when you edit already persisted item you don't need to pass anything to $product->setBrochureFilename() since this field is not actually in the form type and it won't get handled (which is fine). The suggested tip is not needed.

Hello,

It would be interesting to have the best practice for the suffix of form class names. For example, would it be /src/Form/TaskType.php or /src/Form/TaskFormType.php? I find the 2 suffixes on the internet:

• https://github.com/the-fast-track/book-6.2-1/blob/main/src/Form/CommentFormType.php
• https://github.com/symfony/demo/blob/main/src/Form/CommentType.php

Then we may be able to modify the Forms section of the Best Practices page.

| Q | A | ------------ | --- | Feature PR | symfony/symfony#48671 | PR author(s) | @syl20b | Merged in | 6.3

We created this issue to not forget to document this new feature. We would really appreciate if you can help us with this task. If you are not sure how to do it, please ask us and we will help you.

To fix this issue, please create a PR against the 6.3 branch in the symfony-docs repository.

Thank you! :smile: