diff --git a/book/http_fundamentals.rst b/book/http_fundamentals.rst index b3d13904f16..3213ebf2a29 100644 --- a/book/http_fundamentals.rst +++ b/book/http_fundamentals.rst @@ -551,7 +551,7 @@ So then, what *is* the Symfony2 *Framework*? The *Symfony2 Framework* is a PHP library that accomplishes two distinct tasks: #. Provides a selection of components (i.e. the Symfony2 Components) and - third-party libraries (e.g. `Swiftmailer`_ for sending emails); + third-party libraries (e.g. `Swift Mailer`_ for sending emails); #. Provides sensible configuration and a "glue" library that ties all of these pieces together. @@ -577,4 +577,4 @@ sensible defaults. For more advanced users, the sky is the limit. .. _`Validator`: https://github.com/symfony/Validator .. _`Security`: https://github.com/symfony/Security .. _`Translation`: https://github.com/symfony/Translation -.. _`Swiftmailer`: http://swiftmailer.org/ +.. _`Swift Mailer`: http://swiftmailer.org/ diff --git a/book/testing.rst b/book/testing.rst index 7a53cbbeac0..8b3319f488e 100644 --- a/book/testing.rst +++ b/book/testing.rst @@ -677,7 +677,7 @@ The Client used by functional tests creates a Kernel that runs in a special in the ``test`` environment, you can tweak any of your application's settings specifically for testing. -For example, by default, the swiftmailer is configured to *not* actually +For example, by default, the Swift Mailer is configured to *not* actually deliver emails in the ``test`` environment. You can see this under the ``swiftmailer`` configuration option: diff --git a/components/dependency_injection/compilation.rst b/components/dependency_injection/compilation.rst index af1fd1444f5..902336eafdb 100644 --- a/components/dependency_injection/compilation.rst +++ b/components/dependency_injection/compilation.rst @@ -13,7 +13,7 @@ It is compiled by running:: $container->compile(); -The compile method uses *Compiler Passes* for the compilation. The *Dependency Injection* +The compile method uses *Compiler Passes* for the compilation. The Dependency Injection component comes with several passes which are automatically registered for compilation. For example the :class:`Symfony\\Component\\DependencyInjection\\Compiler\\CheckDefinitionValidityPass` checks for various potential issues with the definitions that have been set @@ -40,7 +40,7 @@ and can be registered with the container with:: $container->registerExtension($extension); -The main work of the extension is done in the ``load`` method. In the load method +The main work of the extension is done in the ``load`` method. In the ``load`` method you can load configuration from one or more configuration files as well as manipulate the container definitions using the methods shown in :doc:`/components/dependency_injection/definitions`. diff --git a/components/dependency_injection/definitions.rst b/components/dependency_injection/definitions.rst index 6c930edf95c..2f452cfd0d1 100644 --- a/components/dependency_injection/definitions.rst +++ b/components/dependency_injection/definitions.rst @@ -73,7 +73,7 @@ You can add a new argument to the end of the arguments array using:: $definition->addArgument($argument); The argument can be a string, an array, a service parameter by using ``%parameter_name%`` -or a service id by using :: +or a service id by using:: use Symfony\Component\DependencyInjection\Reference; @@ -122,6 +122,6 @@ You can also replace any existing method calls with an array of new ones with:: .. note:: The methods here that change service definitions can only be used before - the container is compiled, once the container is compiled you cannot + the container is compiled. Once the container is compiled you cannot manipulate service definitions further. To learn more about compiling the container see :doc:`/components/dependency_injection/compilation`. diff --git a/components/dependency_injection/factories.rst b/components/dependency_injection/factories.rst index 70fcbd0142f..5fa7113ec23 100644 --- a/components/dependency_injection/factories.rst +++ b/components/dependency_injection/factories.rst @@ -12,7 +12,7 @@ For this situation, you can use a factory to create the object and tell the service container to call a method on the factory rather than directly instantiating the class. -Suppose you have a factory that configures and returns a new NewsletterManager +Suppose you have a factory that configures and returns a new ``NewsletterManager`` object:: class NewsletterFactory diff --git a/components/dependency_injection/parameters.rst b/components/dependency_injection/parameters.rst index 7f2259beb4d..1eb3716c897 100644 --- a/components/dependency_injection/parameters.rst +++ b/components/dependency_injection/parameters.rst @@ -60,7 +60,7 @@ One use for this is to inject the values into your services. This allows you to configure different versions of services between applications or multiple services based on the same class but configured differently within a single application. You could inject the choice of mail transport into the ``Mailer`` -class directly but by making it a parameter. This makes it easier to change +class directly. But declaring it as a parameter makes it easier to change rather than being tied up and hidden with the service definition: .. configuration-block:: @@ -343,7 +343,7 @@ Start the string with ``@`` or ``@?`` to reference a service in Yaml. converted into the string ``"@mailer"`` instead of referencing the ``mailer`` service. -Xml +XML ~~~ In XML, use the ``service`` type. The behavior if the service does not exist @@ -352,7 +352,7 @@ is thrown. Valid values for ``on-invalid`` are ``null`` (uses ``null`` in place of the missing service) or ``ignored`` (very similar, except if used on a method call, the method call is removed). -Php +PHP ~~~ In PHP, you can use the diff --git a/components/dependency_injection/tags.rst b/components/dependency_injection/tags.rst index 14c58b8fae9..7d354e27dbd 100644 --- a/components/dependency_injection/tags.rst +++ b/components/dependency_injection/tags.rst @@ -27,7 +27,7 @@ To begin with, define the ``TransportChain`` class:: $this->transports = array(); } - public function addTransport(\Swift_Transport $transport) + public function addTransport(\Swift_Transport $transport) { $this->transports[] = $transport; } @@ -176,7 +176,7 @@ Adding additional attributes on Tags ------------------------------------ Sometimes you need additional information about each service that's tagged with your tag. -For example, you might want to add an alias to each TransportChain. +For example, you might want to add an alias to each member of the transport chain. To begin with, change the ``TransportChain`` class:: diff --git a/components/event_dispatcher/introduction.rst b/components/event_dispatcher/introduction.rst index 238474e608c..4da9386aedf 100644 --- a/components/event_dispatcher/introduction.rst +++ b/components/event_dispatcher/introduction.rst @@ -564,7 +564,7 @@ Or:: Or:: - $response = $dispatcher->dispatch('bar.event', new BarEvent())->getBar(); + $bar = $dispatcher->dispatch('bar.event', new BarEvent())->getBar(); and so on... diff --git a/components/form/introduction.rst b/components/form/introduction.rst index e57faeb83e1..266719dcc5c 100644 --- a/components/form/introduction.rst +++ b/components/form/introduction.rst @@ -334,12 +334,12 @@ and then access it whenever you need to build a form. .. note:: - In this document, the form factory is always a locally variable called + In this document, the form factory is always a local variable called ``$formFactory``. The point here is that you will probably need to create this object in some more "global" way so you can access it from anywhere. Exactly how you gain access to your one form factory is up to you. If you're -using a :term`Service Container`, then you should add the form factory to +using a :term:`Service Container`, then you should add the form factory to your container and grab it out whenever you need to. If your application uses global or static variables (not usually a good idea), then you can store the object on some static class or do something similar. @@ -414,7 +414,7 @@ it and :ref:`process the form submission `) +* ``attributes``: no equivalent - used by your app to store other data (see :ref:`below `); * ``files``: equivalent of ``$_FILES``; @@ -109,7 +109,7 @@ methods to retrieve and update its data: parameter by name; * :method:`Symfony\\Component\\HttpFoundation\\ParameterBag::has`: Returns - true if the parameter is defined; + ``true`` if the parameter is defined; * :method:`Symfony\\Component\\HttpFoundation\\ParameterBag::remove`: Removes a parameter. @@ -461,7 +461,7 @@ whether or not the ``X-Sendfile-Type`` header should be trusted and call :method:`Symfony\\Component\\HttpFoundation\\BinaryFileResponse::trustXSendfileTypeHeader` if it should:: - $response::trustXSendfileTypeHeader(); + BinaryFileResponse::trustXSendfileTypeHeader(); You can still set the ``Content-Type`` of the sent file, or change its ``Content-Disposition``:: diff --git a/components/http_foundation/session_configuration.rst b/components/http_foundation/session_configuration.rst index a55957b0986..a4e327c47a8 100644 --- a/components/http_foundation/session_configuration.rst +++ b/components/http_foundation/session_configuration.rst @@ -119,7 +119,7 @@ be securely controlled from the server side. The ``cookie_lifetime`` setting is the number of seconds the cookie should live for, it is not a Unix timestamp. The resulting session cookie will be stamped - with an expiry time of ``time()``+``cookie_lifetime`` where the time is taken + with an expiry time of ``time()`` + ``cookie_lifetime`` where the time is taken from the server. Configuring Garbage Collection @@ -132,7 +132,7 @@ of 5%. Similarly, ``3/4`` would mean a 3 in 4 chance of being called, i.e. 75%. If the garbage collection handler is invoked, PHP will pass the value stored in the ``php.ini`` directive ``session.gc_maxlifetime``. The meaning in this context is -that any stored session that was saved more than ``maxlifetime`` ago should be +that any stored session that was saved more than ``gc_maxlifetime`` ago should be deleted. This allows one to expire records based on idle time. You can configure these settings by passing ``gc_probability``, ``gc_divisor`` @@ -173,8 +173,8 @@ example, it is common for banking applications to log the user out after just 5 to 10 minutes of inactivity. Setting the cookie lifetime here is not appropriate because that can be manipulated by the client, so we must do the expiry on the server side. The easiest way is to implement this via garbage collection -which runs reasonably frequently. The cookie ``lifetime`` would be set to a -relatively high value, and the garbage collection ``maxlifetime`` would be set +which runs reasonably frequently. The ``cookie_lifetime`` would be set to a +relatively high value, and the garbage collection ``gc_maxlifetime`` would be set to destroy sessions at whatever the desired idle period is. The other option is to specifically checking if a session has expired after the @@ -258,7 +258,7 @@ without knowledge of the specific save handler. .. note:: - Before PHP 5.4, you can only proxy user-land save handlers but not + Before PHP 5.4, you can only proxy user-land save handlers but not native PHP save handlers. .. _`php.net/session.customhandler`: http://php.net/session.customhandler diff --git a/components/http_foundation/session_testing.rst b/components/http_foundation/session_testing.rst index e9331eb71a3..a35b23caebe 100644 --- a/components/http_foundation/session_testing.rst +++ b/components/http_foundation/session_testing.rst @@ -18,7 +18,7 @@ starting one allowing you to test your code without complications. You may also run multiple instances in the same PHP process. The mock storage drivers do not read or write the system globals -`session_id()` or `session_name()`. Methods are provided to simulate this if +``session_id()`` or ``session_name()``. Methods are provided to simulate this if required: * :method:`Symfony\\Component\\HttpFoundation\\Session\\SessionStorageInterface::getId`: Gets the diff --git a/components/http_foundation/sessions.rst b/components/http_foundation/sessions.rst index 6e1ae379916..a292f8959e9 100644 --- a/components/http_foundation/sessions.rst +++ b/components/http_foundation/sessions.rst @@ -66,24 +66,24 @@ as follows divided into a couple of groups. Session workflow * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::start`: - Starts the session - do not use ``session_start()``. + Starts the session - do not use ``session_start()``; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::migrate`: Regenerates the session ID - do not use ``session_regenerate_id()``. This method can optionally change the lifetime of the new cookie that will - be emitted by calling this method. + be emitted by calling this method; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::invalidate`: - Clears all session data and regenerates session ID. Do not use ``session_destroy()``. + Clears all session data and regenerates session ID. Do not use ``session_destroy()``; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getId`: Gets the - session ID. Do not use ``session_id()``. + session ID. Do not use ``session_id()``; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::setId`: Sets the - session ID. Do not use ``session_id()``. + session ID. Do not use ``session_id()``; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getName`: Gets the - session name. Do not use ``session_name()``. + session name. Do not use ``session_name()``; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::setName`: Sets the session name. Do not use ``session_name()``. @@ -103,23 +103,23 @@ Session attributes Returns true if the attribute exists; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::replace`: - Sets multiple attributes at once: takes a keyed array and sets each key => value pair. + Sets multiple attributes at once: takes a keyed array and sets each key => value pair; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::remove`: Deletes an attribute by key; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::clear`: - Clear all attributes; + Clear all attributes. The attributes are stored internally in an "Bag", a PHP object that acts like an array. A few methods exist for "Bag" management: * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::registerBag`: - Registers a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface` + Registers a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface`; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getBag`: Gets a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface` by - bag name. + bag name; * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getFlashBag`: Gets the :class:`Symfony\\Component\\HttpFoundation\\Session\\Flash\\FlashBagInterface`. @@ -242,7 +242,7 @@ would be displayed immediately on the subsequent page load for that session. This is however just one application for flash messages. * :class:`Symfony\\Component\\HttpFoundation\\Session\\Flash\\AutoExpireFlashBag` - This implementation messages set in one page-load will + In this implementation, messages set in one page-load will be available for display only on the next page load. These messages will auto expire regardless of if they are retrieved or not. @@ -306,7 +306,7 @@ Examples of setting multiple flashes:: $session->getFlashBag()->add('error', 'Failed to update name'); $session->getFlashBag()->add('error', 'Another error'); -Displaying the flash messages might look like this: +Displaying the flash messages might look as follows. Simple, display one type of message:: diff --git a/components/http_kernel/introduction.rst b/components/http_kernel/introduction.rst index cc862141da7..edc43156fc4 100644 --- a/components/http_kernel/introduction.rst +++ b/components/http_kernel/introduction.rst @@ -104,7 +104,7 @@ listeners to the events discussed below:: // by dispatching events, calling a controller, and returning the response $response = $kernel->handle($request); - // echo the content and send the headers + // send the headers and echo the content $response->send(); // triggers the kernel.terminate event @@ -464,7 +464,7 @@ because it occurs *after* the ``HttpKernel::handle`` method, and after the response is sent to the user. Recall from above, then the code that uses the kernel, ends like this:: - // echo the content and send the headers + // send the headers and echo the content $response->send(); // triggers the kernel.terminate event diff --git a/contributing/code/tests.rst b/contributing/code/tests.rst index 873f3c382eb..f392485cfe0 100644 --- a/contributing/code/tests.rst +++ b/contributing/code/tests.rst @@ -25,7 +25,7 @@ autoloaded from `vendor/` under the main root directory (see The test suite needs the following third-party libraries: * Doctrine -* Swiftmailer +* Swift Mailer * Twig * Monolog diff --git a/cookbook/controller/error_pages.rst b/cookbook/controller/error_pages.rst index 6168fe7a9f3..7398fb59adf 100644 --- a/cookbook/controller/error_pages.rst +++ b/cookbook/controller/error_pages.rst @@ -63,7 +63,7 @@ end-user, create a new template located at .. tip:: If you're not familiar with Twig, don't worry. Twig is a simple, powerful - and optional templating engine that integrates with ``Symfony2``. For more + and optional templating engine that integrates with Symfony2. For more information about Twig see :doc:`/book/templating`. In addition to the standard HTML error page, Symfony provides a default error diff --git a/cookbook/deployment-tools.rst b/cookbook/deployment-tools.rst index 3d271159678..2c2733148e0 100644 --- a/cookbook/deployment-tools.rst +++ b/cookbook/deployment-tools.rst @@ -84,7 +84,7 @@ B) Update your vendors Your vendors can be updated before transferring your source code (i.e. update the ``vendor/`` directory, then transfer that with your source code) or afterwards on the server. Either way, just update your vendors -as your normally do: +as you normally do: .. code-block:: bash diff --git a/cookbook/email/dev_environment.rst b/cookbook/email/dev_environment.rst index ec798aefa21..4ea08bd6e6e 100644 --- a/cookbook/email/dev_environment.rst +++ b/cookbook/email/dev_environment.rst @@ -109,13 +109,13 @@ Now, suppose you're sending an email to ``recipient@example.com``. } In the ``dev`` environment, the email will instead be sent to ``dev@example.com``. -Swiftmailer will add an extra header to the email, ``X-Swift-To``, containing +Swift Mailer will add an extra header to the email, ``X-Swift-To``, containing the replaced address, so you can still see who it would have been sent to. .. note:: In addition to the ``to`` addresses, this will also stop the email being - sent to any ``CC`` and ``BCC`` addresses set for it. Swiftmailer will add + sent to any ``CC`` and ``BCC`` addresses set for it. Swift Mailer will add additional headers to the email with the overridden addresses in them. These are ``X-Swift-Cc`` and ``X-Swift-Bcc`` for the ``CC`` and ``BCC`` addresses respectively. diff --git a/cookbook/email/email.rst b/cookbook/email/email.rst index 9718aa67f14..c8109e307ba 100644 --- a/cookbook/email/email.rst +++ b/cookbook/email/email.rst @@ -7,7 +7,7 @@ How to send an Email Sending emails is a classic task for any web application and one that has special complications and potential pitfalls. Instead of recreating the wheel, one solution to send emails is to use the ``SwiftmailerBundle``, which leverages -the power of the `Swiftmailer`_ library. +the power of the `Swift Mailer`_ library. .. note:: @@ -29,7 +29,7 @@ the power of the `Swiftmailer`_ library. Configuration ------------- -Before using Swiftmailer, be sure to include its configuration. The only +Before using Swift Mailer, be sure to include its configuration. The only mandatory configuration parameter is ``transport``: .. configuration-block:: @@ -74,7 +74,7 @@ mandatory configuration parameter is ``transport``: 'password' => "your_password", )); -The majority of the Swiftmailer configuration deals with how the messages +The majority of the Swift Mailer configuration deals with how the messages themselves should be delivered. The following configuration attributes are available: @@ -96,7 +96,7 @@ The following configuration attributes are available: Sending Emails -------------- -The Swiftmailer library works by creating, configuring and then sending +The Swift Mailer library works by creating, configuring and then sending ``Swift_Message`` objects. The "mailer" is responsible for the actual delivery of the message and is accessible via the ``mailer`` service. Overall, sending an email is pretty straightforward:: @@ -123,7 +123,7 @@ To keep things decoupled, the email body has been stored in a template and rendered with the ``renderView()`` method. The ``$message`` object supports many more options, such as including attachments, -adding HTML content, and much more. Fortunately, Swiftmailer covers the topic +adding HTML content, and much more. Fortunately, Swift Mailer covers the topic of `Creating Messages`_ in great detail in its documentation. .. tip:: @@ -135,5 +135,5 @@ of `Creating Messages`_ in great detail in its documentation. * :doc:`dev_environment` * :doc:`spool` -.. _`Swiftmailer`: http://swiftmailer.org/ +.. _`Swift Mailer`: http://swiftmailer.org/ .. _`Creating Messages`: http://swiftmailer.org/docs/messages.html diff --git a/cookbook/email/gmail.rst b/cookbook/email/gmail.rst index 63ff6a12eba..0be1bbfad1a 100644 --- a/cookbook/email/gmail.rst +++ b/cookbook/email/gmail.rst @@ -5,7 +5,7 @@ How to use Gmail to send Emails =============================== During development, instead of using a regular SMTP server to send emails, you -might find using Gmail easier and more practical. The Swiftmailer bundle makes +might find using Gmail easier and more practical. The ``SwiftmailerBundle`` makes it really easy. .. tip:: diff --git a/cookbook/email/spool.rst b/cookbook/email/spool.rst index e44cdfe7a23..f3cb9de74db 100644 --- a/cookbook/email/spool.rst +++ b/cookbook/email/spool.rst @@ -6,14 +6,14 @@ How to Spool Emails When you are using the ``SwiftmailerBundle`` to send an email from a Symfony2 application, it will default to sending the email immediately. You may, however, -want to avoid the performance hit of the communication between ``Swiftmailer`` +want to avoid the performance hit of the communication between Swift Mailer and the email transport, which could cause the user to wait for the next page to load while the email is sending. This can be avoided by choosing -to "spool" the emails instead of sending them directly. This means that ``Swiftmailer`` +to "spool" the emails instead of sending them directly. This means that Swift Mailer does not attempt to send the email but instead saves the message to somewhere such as a file. Another process can then read from the spool and take care of sending the emails in the spool. Currently only spooling to file or memory is supported -by ``Swiftmailer``. +by Swift Mailer. Spool using memory ------------------ diff --git a/cookbook/email/testing.rst b/cookbook/email/testing.rst index 7386618303d..d44def3f5da 100644 --- a/cookbook/email/testing.rst +++ b/cookbook/email/testing.rst @@ -5,7 +5,7 @@ How to test that an Email is sent in a functional Test ====================================================== Sending e-mails with Symfony2 is pretty straightforward thanks to the -``SwiftmailerBundle``, which leverages the power of the `Swiftmailer`_ library. +``SwiftmailerBundle``, which leverages the power of the `Swift Mailer`_ library. To functionally test that an email was sent, and even assert the email subject, content or any other headers, you can use :ref:`the Symfony2 Profiler `. @@ -67,4 +67,4 @@ to get information about the messages send on the previous request:: } } -.. _Swiftmailer: http://swiftmailer.org/ +.. _`Swift Mailer`: http://swiftmailer.org/ diff --git a/cookbook/symfony1.rst b/cookbook/symfony1.rst index f79361bf318..dca1e22ae32 100644 --- a/cookbook/symfony1.rst +++ b/cookbook/symfony1.rst @@ -77,7 +77,7 @@ The ``vendor/`` directory is basically equivalent to the ``lib/vendor/`` directory in symfony1, which was the conventional directory for all vendor libraries and bundles. By default, you'll find the Symfony2 library files in this directory, along with several other dependent libraries such as Doctrine2, -Twig and Swiftmailer. 3rd party Symfony2 bundles live somewhere in the +Twig and Swift Mailer. 3rd party Symfony2 bundles live somewhere in the ``vendor/``. The ``web/`` Directory diff --git a/cookbook/templating/PHP.rst b/cookbook/templating/PHP.rst index a3454abbb29..bd3dba7ff26 100644 --- a/cookbook/templating/PHP.rst +++ b/cookbook/templating/PHP.rst @@ -114,7 +114,7 @@ Now, let's have a look at the ``layout.html.php`` file: The layout is itself decorated by another one (``::base.html.php``). Symfony2 supports multiple decoration levels: a layout can itself be decorated by another one. When the bundle part of the template name is empty, views are -looked for in the ``app/Resources/views/`` directory. This directory store +looked for in the ``app/Resources/views/`` directory. This directory stores global views for your entire project: .. code-block:: html+php diff --git a/quick_tour/the_architecture.rst b/quick_tour/the_architecture.rst index bce41d873a8..a3cb96cac7c 100644 --- a/quick_tour/the_architecture.rst +++ b/quick_tour/the_architecture.rst @@ -184,7 +184,7 @@ PHP. Have a look at the default configuration: auto_generate_proxy_classes: "%kernel.debug%" auto_mapping: true - # Swiftmailer Configuration + # Swift Mailer Configuration swiftmailer: transport: "%mailer_transport%" host: "%mailer_host%" diff --git a/reference/configuration/swiftmailer.rst b/reference/configuration/swiftmailer.rst index a051f8b7233..b948cf6e6e7 100644 --- a/reference/configuration/swiftmailer.rst +++ b/reference/configuration/swiftmailer.rst @@ -1,5 +1,5 @@ .. index:: - single: Configuration reference; Swiftmailer + single: Configuration reference; Swift Mailer SwiftmailerBundle Configuration ("swiftmailer") =============================================== @@ -8,7 +8,7 @@ This reference document is a work in progress. It should be accurate, but all options are not yet fully covered. For a full list of the default configuration options, see `Full Default Configuration`_ -The ``swiftmailer`` key configures Symfony's integration with Swiftmailer, +The ``swiftmailer`` key configures Symfony's integration with Swift Mailer, which is responsible for creating and delivering email messages. Configuration @@ -119,7 +119,7 @@ sender_address If set, all messages will be delivered with this address as the "return path" address, which is where bounced messages should go. This is handled internally -by Swiftmailer's ``Swift_Plugins_ImpersonatePlugin`` class. +by Swift Mailer's ``Swift_Plugins_ImpersonatePlugin`` class. antiflood ~~~~~~~~~ @@ -166,7 +166,7 @@ logging **type**: ``Boolean`` **default**: ``%kernel.debug%`` -If true, Symfony's data collector will be activated for Swiftmailer and the +If true, Symfony's data collector will be activated for Swift Mailer and the information will be available in the profiler. Full Default Configuration