Merge branch '2.2'

Conflicts:
	reference/forms/types/birthday.rst
	reference/forms/types/choice.rst
	reference/forms/types/date.rst
	reference/forms/types/datetime.rst
	reference/forms/types/file.rst
	reference/forms/types/time.rst

Author: weaverryan

book/security.rst

@@ -807,7 +807,7 @@ Take the following ``access_control`` entries as an example:
                 array('path' => '^/admin', 'role' => 'ROLE_USER'),
             ),
 
-For each incoming request, Symfony will decided which ``access_control``
+For each incoming request, Symfony will decide which ``access_control``
 to use based on the URI, the client's IP address, the incoming host name,
 and the request method. Remember, the first rule that matches is used, and
 if ``ip``, ``host`` or ``method`` are not specified for an entry, that ``access_control``

components/http_foundation/introduction.rst

@@ -499,10 +499,11 @@ to ``application/json``.
 
 .. caution::
 
-    To avoid `JSON Hijacking`_, you should pass an associative array as the
-    outer-most array to ``JsonResponse`` and not an indexed array so that
-    the final result is an object (e.g. ``{"object": "not inside an array"}``)
-    instead of an array (e.g. ``[{"object": "inside an array"}]``).
+    To avoid XSSI `JSON Hijacking`_, you should pass an associative array
+    as the outer-most array to ``JsonResponse`` and not an indexed array so
+    that the final result is an object (e.g. ``{"object": "not inside an array"}``)
+    instead of an array (e.g. ``[{"object": "inside an array"}]``). Read
+    the `OWASP guidelines`_ for more information.
 
 JSONP Callback
 ~~~~~~~~~~~~~~
@@ -528,3 +529,4 @@ The session information is in its own document: :doc:`/components/http_foundatio
 .. _Nginx: http://wiki.nginx.org/XSendfile
 .. _Apache: https://tn123.org/mod_xsendfile/
 .. _`JSON Hijacking`: http://haacked.com/archive/2009/06/25/json-hijacking.aspx
+.. _OWASP guidelines: https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines#Always_return_JSON_with_an_Object_on_the_outside

contributing/documentation/format.rst

@@ -52,6 +52,8 @@ the highlighted pseudo-language:
 
     A list of supported languages is available on the `Pygments website`_.
 
+.. _docs-configuration-blocks:
+
 Configuration Blocks
 ~~~~~~~~~~~~~~~~~~~~
 

contributing/documentation/index.rst

@@ -6,5 +6,6 @@ Contributing Documentation
 
     overview
     format
+    standards
     translations
     license

contributing/documentation/overview.rst

@@ -161,55 +161,8 @@ tags would be removed from the new 2.5 branch.
 Standards
 ---------
 
-In order to help the reader as much as possible and to create code examples that
-look and feel familiar, you should follow these rules:
-
-* The code follows the :doc:`Symfony Coding Standards</contributing/code/standards>`
-  as well as the `Twig Coding Standards`_;
-* Each line should break approximately after the first word that crosses the
-  72nd character (so most lines end up being 72-78 characters);
-* To avoid horizontal scrolling on code blocks, we prefer to break a line
-  correctly if it crosses the 85th character;
-* When you fold one or more lines of code, place ``...`` in a comment at the point
-  of the fold. These comments are: ``// ...`` (php), ``# ...`` (yaml/bash), ``{# ... #}``
-  (twig), ``<!-- ... -->`` (xml/html), ``; ...`` (ini), ``...`` (text);
-* When you fold a part of a line, e.g. a variable value, put ``...`` (without comment)
-  at the place of the fold;
-* Description of the folded code: (optional)
-  If you fold several lines: the description of the fold can be placed after the ``...``
-  If you fold only part of a line: the description can be placed before the line;
-* If useful, a ``codeblock`` should begin with a comment containing the filename
-  of the file in the code block. Don't place a blank line after this comment,
-  unless the next line is also a comment;
-* You should put a ``$`` in front of every bash line;
-* The ``::`` shorthand is preferred over ``.. code-block:: php`` to begin a PHP
-  code block;
-* You should use a form of *you* instead of *we*.
-
-An example::
-
-    // src/Foo/Bar.php
-
-    // ...
-    class Bar
-    {
-        // ...
-
-        public function foo($bar)
-        {
-            // set foo with a value of bar
-            $foo = ...;
-
-            // ... check if $bar has the correct value
-
-            return $foo->baz($bar, ...);
-        }
-    }
-
-.. caution::
-
-    In Yaml you should put a space after ``{`` and before ``}`` (e.g. ``{ _controller: ... }``),
-    but this should not be done in Twig (e.g.  ``{'hello' : 'value'}``).
+All documentation in the Symfony Documentation should follow
+:doc:`the documentation standards <standards>`.
 
 Reporting an Issue
 ------------------
@@ -231,4 +184,3 @@ Read the dedicated :doc:`document <translations>`.
 .. _`fork`: https://help.github.com/articles/fork-a-repo
 .. _`pull requests`: https://help.github.com/articles/using-pull-requests
 .. _`Documentation Build Errors`: http://symfony.com/doc/build_errors
-.. _`Twig Coding Standards`: http://twig.sensiolabs.org/doc/coding_standards.html

contributing/documentation/standards.rst

@@ -0,0 +1,108 @@
+Documentation Standards
+=======================
+
+In order to help the reader as much as possible and to create code examples that
+look and feel familiar, you should follow these standards.
+
+Sphinx
+------
+
+* The following characters are choosen for different heading levels: level 1
+  is ``=``, level 2 ``-``, level 3 ``~``, level 4 ``.`` and level 5 ``"``;
+* Each line should break approximately after the first word that crosses the
+  72nd character (so most lines end up being 72-78 characters);
+* The ``::`` shorthand is *preferred* over ``.. code-block:: php`` to begin a PHP
+  code block (read `the Sphinx documentation`_ to see when you should use the
+  shorthand);
+* Inline hyperlinks are **not** used. Seperate the link and their target
+  definition, which you add on the bottom of the page;
+* You should use a form of *you* instead of *we*.
+
+Example
+~~~~~~~
+
+.. code-block:: text
+
+    Example
+    =======
+
+    When you are working on the docs, you should follow the `Symfony Docs`_
+    standards.
+
+    Level 2
+    -------
+
+    A PHP example would be::
+
+        echo 'Hello World';
+
+    Level 3
+    ~~~~~~~
+
+    .. code-block:: php
+
+        echo 'You cannot use the :: shortcut here';
+
+    .. _`Symfony Docs`: http://symfony.com/doc/current/contributing/documentation/standards.html
+
+Code Examples
+-------------
+
+* The code follows the :doc:`Symfony Coding Standards</contributing/code/standards>`
+  as well as the `Twig Coding Standards`_;
+* To avoid horizontal scrolling on code blocks, we prefer to break a line
+  correctly if it crosses the 85th character;
+* When you fold one or more lines of code, place ``...`` in a comment at the point
+  of the fold. These comments are: ``// ...`` (php), ``# ...`` (yaml/bash), ``{# ... #}``
+  (twig), ``<!-- ... -->`` (xml/html), ``; ...`` (ini), ``...`` (text);
+* When you fold a part of a line, e.g. a variable value, put ``...`` (without comment)
+  at the place of the fold;
+* Description of the folded code: (optional)
+  If you fold several lines: the description of the fold can be placed after the ``...``
+  If you fold only part of a line: the description can be placed before the line;
+* If useful, a ``codeblock`` should begin with a comment containing the filename
+  of the file in the code block. Don't place a blank line after this comment,
+  unless the next line is also a comment;
+* You should put a ``$`` in front of every bash line.
+
+Formats
+~~~~~~~
+
+Configuration examples should show all supported formats using
+:ref:`configuration blocks <docs-configuration-blocks>`. The supported formats
+(and their orders) are:
+
+* **Configuration** (including services and routing): Yaml, Xml, Php
+* **Validation**: Yaml, Annotations, Xml, Php
+* **Doctrine Mapping**: Annotations, Yaml, Xml, Php
+
+Example
+~~~~~~~
+
+.. code-block:: php
+
+    // src/Foo/Bar.php
+
+    // ...
+    class Bar
+    {
+        // ...
+
+        public function foo($bar)
+        {
+            // set foo with a value of bar
+            $foo = ...;
+
+            // ... check if $bar has the correct value
+
+            return $foo->baz($bar, ...);
+        }
+    }
+
+.. caution::
+
+    In Yaml you should put a space after ``{`` and before ``}`` (e.g. ``{ _controller: ... }``),
+    but this should not be done in Twig (e.g.  ``{'hello' : 'value'}``).
+
+.. _`the Sphinx documentation`: http://sphinx-doc.org/rest.html#source-code
+.. _`Twig Coding Standards`: http://twig.sensiolabs.org/doc/coding_standards.html

contributing/map.rst.inc

@@ -13,6 +13,7 @@
 
   * :doc:`Overview </contributing/documentation/overview>`
   * :doc:`Format </contributing/documentation/format>`
+  * :doc:`Documentation Standards </contributing/documentation/standards>`
   * :doc:`Translations </contributing/documentation/translations>`
   * :doc:`License </contributing/documentation/license>`
 

cookbook/form/data_transformers.rst

@@ -152,7 +152,7 @@ when creating your form. Later, you'll learn how you could create a custom
 ``issue`` field type to avoid needing to do this in your controller::
 
     $taskForm = $this->createForm(new TaskType(), $task, array(
-        'em' => $this->getDoctrine()->getEntityManager(),
+        'em' => $this->getDoctrine()->getManager(),
     ));
 
 Cool, you're done! Your user will be able to enter an issue number into the