diff --git a/book/translation.rst b/book/translation.rst index 255cd45fd55..281fadd8bc5 100644 --- a/book/translation.rst +++ b/book/translation.rst @@ -394,13 +394,13 @@ Imagine that the user's locale is ``fr_FR`` and that you're translating the key ``Symfony is great``. To find the French translation, Symfony actually checks translation resources for several different locales: -1. First, Symfony looks for the translation in a ``fr_FR`` translation resource +#. First, Symfony looks for the translation in a ``fr_FR`` translation resource (e.g. ``messages.fr_FR.xliff``); -2. If it wasn't found, Symfony looks for the translation in a ``fr`` translation +#. If it wasn't found, Symfony looks for the translation in a ``fr`` translation resource (e.g. ``messages.fr.xliff``); -3. If the translation still isn't found, Symfony uses the ``fallback`` configuration +#. If the translation still isn't found, Symfony uses the ``fallback`` configuration parameter, which defaults to ``en`` (see `Configuration`_). .. _book-translation-user-locale: diff --git a/components/routing/introduction.rst b/components/routing/introduction.rst index e751b0a36d2..85bcd1065de 100644 --- a/components/routing/introduction.rst +++ b/components/routing/introduction.rst @@ -72,25 +72,25 @@ Defining Routes A full route definition can contain up to seven parts: -1. The URL path route. This is matched against the URL passed to the `RequestContext`, +#. The URL path route. This is matched against the URL passed to the `RequestContext`, and can contain named wildcard placeholders (e.g. ``{placeholders}``) to match dynamic parts in the URL. -2. An array of default values. This contains an array of arbitrary values +#. An array of default values. This contains an array of arbitrary values that will be returned when the request matches the route. -3. An array of requirements. These define constraints for the values of the +#. An array of requirements. These define constraints for the values of the placeholders as regular expressions. -4. An array of options. These contain internal settings for the route and +#. An array of options. These contain internal settings for the route and are the least commonly needed. -5. A host. This is matched against the host of the request. See +#. A host. This is matched against the host of the request. See :doc:`/components/routing/hostname_pattern` for more details. -6. An array of schemes. These enforce a certain HTTP scheme (``http``, ``https``). +#. An array of schemes. These enforce a certain HTTP scheme (``http``, ``https``). -7. An array of methods. These enforce a certain HTTP request method (``HEAD``, +#. An array of methods. These enforce a certain HTTP request method (``HEAD``, ``GET``, ``POST``, ...). .. versionadded:: 2.2 diff --git a/components/serializer.rst b/components/serializer.rst index aeaabeb6067..472de02aa02 100644 --- a/components/serializer.rst +++ b/components/serializer.rst @@ -144,9 +144,9 @@ of the ``Person`` class would be encoded in XML format:: In this case, :method:`Symfony\\Component\\Serializer\\Serializer::deserialize` needs three parameters: -1. The information to be decoded -2. The name of the class this information will be decoded to -3. The encoder used to convert that information into an array +#. The information to be decoded +#. The name of the class this information will be decoded to +#. The encoder used to convert that information into an array Using Camelized Method Names for Underscored Attributes ------------------------------------------------------- diff --git a/components/translation/introduction.rst b/components/translation/introduction.rst index 5810fe5e770..c637dce0b5a 100644 --- a/components/translation/introduction.rst +++ b/components/translation/introduction.rst @@ -159,12 +159,12 @@ If the message is not located in the catalog of the specific locale, the translator will look into the catalog of one or more fallback locales. For example, assume you're trying to translate into the ``fr_FR`` locale: -1. First, the translator looks for the translation in the ``fr_FR`` locale; +#. First, the translator looks for the translation in the ``fr_FR`` locale; -2. If it wasn't found, the translator looks for the translation in the ``fr`` +#. If it wasn't found, the translator looks for the translation in the ``fr`` locale; -3. If the translation still isn't found, the translator uses the one or more +#. If the translation still isn't found, the translator uses the one or more fallback locales set explicitly on the translator. For (3), the fallback locales can be set by calling diff --git a/contributing/code/security.rst b/contributing/code/security.rst index 49a6ff35e30..51acb3f1adf 100644 --- a/contributing/code/security.rst +++ b/contributing/code/security.rst @@ -19,10 +19,10 @@ Resolving Process For each report, we first try to confirm the vulnerability. When it is confirmed, the core-team works on a solution following these steps: -1. Send an acknowledgement to the reporter; -2. Work on a patch; -3. Get a CVE identifier from mitre.org; -4. Write a security announcement for the official Symfony `blog`_ about the +#. Send an acknowledgement to the reporter; +#. Work on a patch; +#. Get a CVE identifier from mitre.org; +#. Write a security announcement for the official Symfony `blog`_ about the vulnerability. This post should contain the following information: * a title that always include the "Security release" string; @@ -32,12 +32,12 @@ confirmed, the core-team works on a solution following these steps: * how to patch/upgrade/workaround affected applications; * the CVE identifier; * credits. -5. Send the patch and the announcement to the reporter for review; -6. Apply the patch to all maintained versions of Symfony; -7. Package new versions for all affected versions; -8. Publish the post on the official Symfony `blog`_ (it must also be added to +#. Send the patch and the announcement to the reporter for review; +#. Apply the patch to all maintained versions of Symfony; +#. Package new versions for all affected versions; +#. Publish the post on the official Symfony `blog`_ (it must also be added to the "`Security Advisories`_" category); -9. Update the security advisory list (see below). +#. Update the security advisory list (see below). .. note:: @@ -61,23 +61,23 @@ As Symfony is used by many large Open-Source projects, we standardized the way the Symfony security team collaborates on security issues with downstream projects. The process works as follows: -1. After the Symfony security team has acknowledged a security issue, it -immediately sends an email to the downstream project security teams to inform -them of the issue; +#. After the Symfony security team has acknowledged a security issue, it + immediately sends an email to the downstream project security teams to + inform them of the issue; -2. The Symfony security team creates a private Git repository to ease the -collaboration on the issue and access to this repository is given to the -Symfony security team, to the Symfony contributors that are impacted by the -issue, and to one representative of each downstream projects; +#. The Symfony security team creates a private Git repository to ease the + collaboration on the issue and access to this repository is given to the + Symfony security team, to the Symfony contributors that are impacted by + the issue, and to one representative of each downstream projects; -3. All people with access to the private repository work on a solution to -solve the issue via pull requests, code reviews, and comments; +#. All people with access to the private repository work on a solution to + solve the issue via pull requests, code reviews, and comments; -4. Once the fix is found, all involved projects collaborate to find the best -date for a joint release (there is no guarantee that all releases will be at -the same time but we will try hard to make them at about the same time). When -the issue is not known to be exploited in the wild, a period of two weeks -seems like a reasonable amount of time. +#. Once the fix is found, all involved projects collaborate to find the best + date for a joint release (there is no guarantee that all releases will + be at the same time but we will try hard to make them at about the same + time). When the issue is not known to be exploited in the wild, a period + of two weeks seems like a reasonable amount of time. The list of downstream projects participating in this process is kept as small as possible in order to better manage the flow of confidential information diff --git a/cookbook/deployment/heroku.rst b/cookbook/deployment/heroku.rst index 5525e7ffce5..44f33b46362 100644 --- a/cookbook/deployment/heroku.rst +++ b/cookbook/deployment/heroku.rst @@ -81,9 +81,9 @@ Creating a Procfile By default, Heroku will launch an Apache web server together with PHP to serve applications. However, two special circumstances apply to Symfony applications: -1. The document root is in the ``web/`` directory and not in the root directory +#. The document root is in the ``web/`` directory and not in the root directory of the application; -2. The Composer ``bin-dir``, where vendor binaries (and thus Heroku's own boot +#. The Composer ``bin-dir``, where vendor binaries (and thus Heroku's own boot scripts) are placed, is ``bin/`` , and not the default ``vendor/bin``. .. note:: diff --git a/cookbook/security/custom_authentication_provider.rst b/cookbook/security/custom_authentication_provider.rst index be18a236549..2a05498c913 100644 --- a/cookbook/security/custom_authentication_provider.rst +++ b/cookbook/security/custom_authentication_provider.rst @@ -20,9 +20,9 @@ The following chapter demonstrates how to create a custom authentication provider for WSSE authentication. The security protocol for WSSE provides several security benefits: -1. Username / Password encryption -2. Safe guarding against replay attacks -3. No web server configuration required +#. Username / Password encryption +#. Safe guarding against replay attacks +#. No web server configuration required WSSE is very useful for the securing of web services, may they be SOAP or REST. diff --git a/cookbook/workflow/new_project_svn.rst b/cookbook/workflow/new_project_svn.rst index c8140d1f09a..861c6871cec 100644 --- a/cookbook/workflow/new_project_svn.rst +++ b/cookbook/workflow/new_project_svn.rst @@ -48,26 +48,26 @@ Initial Project Setup To get started, you'll need to download Symfony and get the basic Subversion setup: -1. Download the `Symfony Standard Edition`_ with or without vendors. +#. Download the `Symfony Standard Edition`_ with or without vendors. -2. Unzip/untar the distribution. It will create a folder called Symfony with +#. Unzip/untar the distribution. It will create a folder called Symfony with your new project structure, config files, etc. Rename it to whatever you like. -3. Checkout the Subversion repository that will host this project. Suppose +#. Checkout the Subversion repository that will host this project. Suppose it is hosted on `Google code`_ and called ``myproject``: .. code-block:: bash $ svn checkout http://myproject.googlecode.com/svn/trunk myproject -4. Copy the Symfony project files in the Subversion folder: +#. Copy the Symfony project files in the Subversion folder: .. code-block:: bash $ mv Symfony/* myproject/ -5. Now, set the ignore rules. Not everything *should* be stored in your Subversion +#. Now, set the ignore rules. Not everything *should* be stored in your Subversion repository. Some files (like the cache) are generated and others (like the database configuration) are meant to be customized on each machine. This makes use of the ``svn:ignore`` property, so that specific files can @@ -88,21 +88,21 @@ To get started, you'll need to download Symfony and get the basic Subversion set $ svn ci -m "commit basic Symfony ignore list (vendor, app/bootstrap*, app/config/parameters.yml, app/cache/*, app/logs/*, web/bundles)" -6. The rest of the files can now be added and committed to the project: +#. The rest of the files can now be added and committed to the project: .. code-block:: bash $ svn add --force . $ svn ci -m "add basic Symfony Standard 2.X.Y" -7. Copy ``app/config/parameters.yml`` to ``app/config/parameters.yml.dist``. +#. Copy ``app/config/parameters.yml`` to ``app/config/parameters.yml.dist``. The ``parameters.yml`` file is ignored by svn (see above) so that machine-specific settings like database passwords aren't committed. By creating the ``parameters.yml.dist`` file, new developers can quickly clone the project, copy this file to ``parameters.yml``, customize it, and start developing. -8. Finally, download all of the third-party vendor libraries by +#. Finally, download all of the third-party vendor libraries by executing Composer. For details, see :ref:`installation-updating-vendors`. .. tip::