diff --git a/components/security/authorization.rst b/components/security/authorization.rst index 3effc3d0794..5444b5254c2 100644 --- a/components/security/authorization.rst +++ b/components/security/authorization.rst @@ -67,15 +67,15 @@ Strategies The following strategies are bundled with the component: ``AffirmativeStrategy`` (default) - grant access as soon as there is one voter granting access; + grants access as soon as there is one voter granting access; ``ConsensusStrategy`` - grant access if there are more voters granting access than there are denying; + grants access if there are more voters granting access than there are denying; if there is a draw between votes, the decision is made based on the ``$allowIfEqualGrantedDeniedDecisions`` constructor parameter which defaults to ``true``. ``UnanimousStrategy`` - only grant access if none of the voters has denied access. + only grants access if none of the voters has denied access. ``PriorityStrategy`` grants or denies access by the first voter that does not abstain; @@ -85,10 +85,10 @@ The following strategies are bundled with the component: The "priority" version strategy was introduced in Symfony 5.1. If all voters abstained from voting, the decision is based on the ``$allowIfAllAbstainDecisions`` -constructor parameter which is supported by all of the built-in strategies and defaults to ``false``. +constructor parameter which is supported by all the built-in strategies and defaults to ``false``. If none of the built-in strategies seem to fit, a custom strategy may be provided. The strategy will -receive a stream of votes and may return as soon as it has seen enough votes to come to a conclusion. +receive a stream of votes and may return as soon as it has seen enough votes to reach a conclusion. :: diff --git a/console/style.rst b/console/style.rst index 33f1ff59cc5..4a10639aee6 100644 --- a/console/style.rst +++ b/console/style.rst @@ -168,7 +168,7 @@ Content Methods :method:`Symfony\\Component\\Console\\Style\\SymfonyStyle::createTable` Creates an instance of :class:`Symfony\\Component\\Console\\Helper\\Table` styled according to the Symfony Style Guide, which allows you to use - features such as appending rows dynamically. + features such as dynamically appending rows. .. versionadded:: 5.4 diff --git a/mailer.rst b/mailer.rst index 66a64159c22..dc7c3249669 100644 --- a/mailer.rst +++ b/mailer.rst @@ -189,7 +189,7 @@ OhMySMTP ohmysmtp+smtp://API_TOKEN@default n/a .. caution:: - If you want to use ``ses+smtp`` transport together with :doc:`Messenger ` + If you want to use the ``ses+smtp`` transport together with :doc:`Messenger ` to :ref:`send messages in background `, you need to add the ``ping_threshold`` parameter to your ``MAILER_DSN`` with a value lower than ``10``: ``ses+smtp://USERNAME:PASSWORD@default?ping_threshold=9`` diff --git a/messenger.rst b/messenger.rst index e2565fab518..5761deac446 100644 --- a/messenger.rst +++ b/messenger.rst @@ -706,9 +706,9 @@ PHP is designed to be stateless, there are no shared resources across different requests. In HTTP context PHP cleans everything after sending the response, so you can decide to not take care of services that may leak memory. -On the other hand, workers usually run in long-running CLI processes, which don't -finish after processing a message. That's why you need to be careful about services -state to not leak information and/or memory from one message to another message. +On the other hand, workers usually sequentially process messages in long-running CLI processes, which don't +finish after processing a single message. That's why you must be careful about service +states to prevent information and/or memory leakage. However, certain Symfony services, such as the Monolog :ref:`fingers crossed handler `, leak by design. diff --git a/serializer.rst b/serializer.rst index 92250d2f5a9..1d47e7a2de2 100644 --- a/serializer.rst +++ b/serializer.rst @@ -151,7 +151,7 @@ properties and setters (``setXxx()``) to change properties: Serializer Context ------------------ -The serializer can define a context to control how the (de)serialization of +The serializer can define a context to control the (de)serialization of resources. This context is passed to all normalizers. For example: * :class:`Symfony\\Component\\Serializer\\Normalizer\\DateTimeNormalizer` uses @@ -165,7 +165,7 @@ resources. This context is passed to all normalizers. For example: The usage of the ``empty_array_as_object`` option by default in the Serializer was introduced in Symfony 5.4. -You can pass the context like following:: +You can pass the context as follows:: $serializer->serialize($something, 'json', [ DateTimeNormalizer::FORMAT_KEY => 'Y-m-d H:i:s', diff --git a/testing.rst b/testing.rst index 5ff21c1fb95..91a8bd3fa25 100644 --- a/testing.rst +++ b/testing.rst @@ -929,8 +929,8 @@ Browser Assertions Asserts the given cookie in the test Client is set to the expected value. ``assertThatForClient(Constraint $constraint, string $message = '')`` - Asserts the given Constraint in the Client. Useful to use your custom asserts - in the same way of built-in asserts (i.e. without passing the Client as argument):: + Asserts the given Constraint in the Client. Useful for using your custom asserts + in the same way as built-in asserts (i.e. without passing the Client as argument):: // add this method in some custom class imported in your tests protected static function assertMyOwnCustomAssert(): void