More Vale fixes 😅

docs/components/integrations_authentication.rst

@@ -2,9 +2,13 @@
 
 :orphan:
 
+.. vale off
+
 Authentication integration
 ##########################
 
+.. vale on
+
 The IntegrationsBundle provides factories and helpers to create Guzzle Client classes for common authentication protocols.
 
 ----------
@@ -152,7 +156,7 @@ The best way to get configuration values such as username, password, consumer ke
 API key
 =======
 
-Use the ``mautic.integrations.auth_provider.api_key`` service (``\Mautic\IntegrationsBundle\Auth\Provider\ApiKey\HttpFactory``) to obtain a ``GuzzleHttp\ClientInterface`` that uses an API key for all requests. Out of the box, the factory supports a parameter API key or a header API key.
+Use the ``mautic.integrations.auth_provider.api_key`` service - ``\Mautic\IntegrationsBundle\Auth\Provider\ApiKey\HttpFactory`` - to obtain a ``GuzzleHttp\ClientInterface`` that uses an API key for all requests. Out of the box, the factory supports a parameter API key or a header API key.
 
 Parameter based API key
 -----------------------
@@ -269,7 +273,7 @@ Find the code snippet as follows,
 Basic auth
 ==========
 
-Use the ``mautic.integrations.auth_provider.basic_auth`` service (``\Mautic\IntegrationsBundle\Auth\Provider\BasicAuth\HttpFactory``) to obtain a ``GuzzleHttp\ClientInterface`` that uses basic auth for all requests.
+Use the ``mautic.integrations.auth_provider.basic_auth`` service - ``\Mautic\IntegrationsBundle\Auth\Provider\BasicAuth\HttpFactory`` - to obtain a ``GuzzleHttp\ClientInterface`` that uses basic auth for all requests.
 
 To use the basic auth, create a credentials class that implements ``\Mautic\IntegrationsBundle\Auth\Provider\BasicAuth\CredentialsInterface``.
 
@@ -338,7 +342,7 @@ Yet to implement in the core.
 OAuth1a two legged
 ------------------
 
-OAuth1a two legged does not require a User to login as would three legged.
+OAuth1a two legged doesn't require a User to login as would three legged.
 
 .. code-block:: php
 
@@ -420,7 +424,7 @@ The OAuth2 factories leverages :xref:`Guzzle Oauth2 Subscriber` as a middleware.
 Client configuration
 --------------------
 
-Both OAuth2 factories leverage the ``\Mautic\IntegrationsBundle\Auth\Provider\AuthConfigInterface`` object to manage things such as configuring the signer (basic auth, post form data, custom), token factory, token persistence, and token signer (bearer auth, basic auth, query string, custom). Use the appropriate interfaces as required for the use case (see the interfaces in ``app/bundles/IntegrationsBundle/Auth/Support/Oauth2/ConfigAccess``).
+Both OAuth2 factories leverage the ``\Mautic\IntegrationsBundle\Auth\Provider\AuthConfigInterface`` object to manage things such as configuring the signer (basic auth, ``post form data``, custom), token factory, token persistence, and token signer (bearer auth, basic auth, query string, custom). Use the appropriate interfaces as required for the use case (see the interfaces in ``app/bundles/IntegrationsBundle/Auth/Support/Oauth2/ConfigAccess``).
 
 See :xref:`Guzzle Oauth2 Subscriber` for additional details on configuring the credentials and token signers or creating custom token persistence and factories.
 
@@ -429,7 +433,7 @@ Token persistence
 
 For most use cases, a token persistence service requires fetching and storing the access tokens generated by using refresh tokens, etc. The IntegrationBundle provides one that natively uses the ``\Mautic\PluginBundle\Entity\Integration`` entity's API keys. Anything stored through the service is automatically encrypted.
 
-Use the ``mautic.integrations.auth_provider.token_persistence_factory`` service (``\Mautic\IntegrationsBundle\Auth\Support\Oauth2\Token\TokenPersistenceFactory``) to generate a ``TokenFactoryInterface``. The``\Mautic\IntegrationsBundle\Auth\Support\Oauth2\ConfigAccess\ConfigTokenFactoryInterface`` interface returns it.
+Use the ``mautic.integrations.auth_provider.token_persistence_factory`` service - ``\Mautic\IntegrationsBundle\Auth\Support\Oauth2\Token\TokenPersistenceFactory`` - to generate a ``TokenFactoryInterface``. The``\Mautic\IntegrationsBundle\Auth\Support\Oauth2\ConfigAccess\ConfigTokenFactoryInterface`` interface returns it.
 
 .. code-block:: php
 
@@ -465,9 +469,9 @@ The token persistence service automatically manages ``access_token``, ``refresh_
 Token factory
 -------------
 
-In some cases, the third-party service may return additional values that are not traditionally part of the OAuth2 spec, and these values are required for further communication with the API service. In this case, the integration bundle's ``\Mautic\IntegrationsBundle\Auth\Support\Oauth2\Token\IntegrationTokenFactory`` can use to capture those extra values and store them in the ``Integration`` entity's API keys array.
+In some cases, the third-party service may return additional values that aren't traditionally part of the OAuth2 spec. Sometimes, the API service requires these values for further communication. In this case, the Integration bundle's ``\Mautic\IntegrationsBundle\Auth\Support\Oauth2\Token\IntegrationTokenFactory`` can use to capture those extra values and store them in the ``Integration`` entity's API keys array.
 
-The ``IntegrationTokenFactory`` can then be returned in a ``\Mautic\IntegrationsBundle\Auth\Support\Oauth2\ConfigAccess\ConfigTokenFactoryInterface`` when configuring the ``Client``.
+You can then return the ``IntegrationTokenFactory`` in a ``\Mautic\IntegrationsBundle\Auth\Support\Oauth2\ConfigAccess\ConfigTokenFactoryInterface`` when configuring the ``Client``.
 
 .. code-block:: php
 
@@ -498,7 +502,7 @@ OAuth2 two legged
 Password grant
 --------------
 
-Below is an example of the password grant for a service that uses a scope (optional interface). The use of the token persistence is assuming the access token is valid for a period of time (that is an hour).
+Below is an example of the password grant for a service that uses a scope. The interfaces used are optional. The use of the token persistence is assuming the access token is valid for an hour.
 
 .. code-block:: php
 
@@ -586,7 +590,7 @@ Below is an example of the password grant for a service that uses a scope (optio
 Client credentials grant
 ------------------------
 
-Below is an example of the client credentials grant for a service that uses a scope (optional interface). The use of the token persistence is assuming the access token is valid for a period of time (that is an hour).
+Below is an example of the client credentials grant for a service that uses a scope. The interfaces used are optional. The use of the token persistence is assuming the access token is valid for an hour.
 
 .. code-block:: php
 
@@ -660,9 +664,18 @@ Below is an example of the client credentials grant for a service that uses a sc
 OAuth2 three legged
 ===================
 
-Three legged OAuth2 with the code grant is the most complex to implement because it involves redirecting the user to the third party service to authenticate then sent back to Mautic to initiate the access token process using a code returned in the request.
+Three legged OAuth2 with the code grant is the most complex to implement because it involves redirecting the User to the third party service to authenticate then sent back to Mautic to initiate the access token process using a code returned in the request.
+
+The first step is to register the Integration as a :ref:`\\Mautic\\IntegrationsBundle\\Integration\\Interfaces\\AuthenticationInterface<Register the Integration for Authentication>`.
+The ``authenticateIntegration()`` method initiates the access token process using the ``code`` returned in the request after the User logs into the third-party service.
+
+.. vale off
+
+The Integration bundle provides a route that can use as the redirect or callback URIs through the named route ``mautic_integration_public_callback`` that requires a ``integration`` parameter.
+
+.. vale on
 
-The first step is to register the integration as a :ref:`\\Mautic\\IntegrationsBundle\\Integration\\Interfaces\\AuthenticationInterface<Register the Integration for Authentication>`. The ``authenticateIntegration()`` method initiates the access token process using the ``code`` returned in the request after the user logs into the third-party service. The Integration bundle provides a route that can use as the redirect or callback URIs through the named route ``mautic_integration_public_callback`` that requires a ``integration`` parameter. This redirect URI can display in the UI by using :xref:`ConfigFormCallbackInterface`. This route is to find the integration by name from the ``AuthIntegrationsHelper`` and then execute its ``authenticateIntegration()``.
+This redirect URI can display in the UI by using :xref:`ConfigFormCallbackInterface`. This route is to find the Integration by name from the ``AuthIntegrationsHelper`` and then execute its ``authenticateIntegration()``.
 
 .. code-block:: php
 
@@ -689,7 +702,9 @@ The first step is to register the integration as a :ref:`\\Mautic\\IntegrationsB
         }
     }
 
-The trick here is that the ``Client``'s ``authenticate`` method configures a ``ClientInterface`` and then calls to any valid API URL (*this is required*). The middleware initiates the access token process by making a call and storing it in the ``Integration`` entity's API keys through :ref:`TokenPersistenceFactory<Token Persistence>`. The URL is recommended to be something simple, like a checking version or fetching info for the authenticated User.
+The trick here is that the ``Client``'s ``authenticate`` method configures a ``ClientInterface`` and then calls any valid API URL.
+The middleware initiates the access token process by making a call and storing it in the ``Integration`` entity's API keys through :ref:`TokenPersistenceFactory<Token Persistence>`.
+Mautic recommends keeping the URL simple, like a checking version or fetching info for the authenticated User.
 
 Here is an example of a client, assuming that the User has already logged in and the code is in the request.
 

docs/components/integrations_builder.rst

@@ -2,9 +2,13 @@
 
 :orphan:
 
+.. vale off
+
 Builder integrations
 #####################
 
+.. vale on
+
 Builders can register itself as a "builder" for Email and/or Landing Pages.
 
 ----

docs/components/integrations_sync.rst

@@ -2,14 +2,18 @@
 
 :orphan:
 
+.. vale off
+
 Sync engine
 ###########
 
+.. vale on
+
 The Sync Engine supports bidirectional syncing between Mautic's Contact and Companies with third party objects. The engine generates a "``sync report``" from Mautic that it converts to a "``sync order``" for the Integration to process. It then asks for a "``sync report``" from the Integration which it converts to a "``sync order``" for Mautic to process.
 
 When building the Report, Mautic or the Integration fetches the objects those either modified or created within the specified timeframe. If the Integration supports changes at the field level, it should tell the Report on a per-field basis when the field was last updated. Otherwise, it should tell the Report when the object itself was last modified. The "``sync judge``" uses these dates to determine which value to use in bi-directional sync.
 
-The sync is initiated using the ``mautic:integrations:sync`` command. For example::
+The ``mautic:integrations:sync`` command initiates the sync. For example::
 
     php bin/console mautic:integrations:sync HelloWorld --start-datetime="2020-01-01 00:00:00" --end-datetime="2020-01-02 00:00:00".
 
@@ -74,7 +78,7 @@ ____________________
 
 .. vale on
 
-The Sync Report tells the Sync Engine what objects are new and/or modified between the two timestamps given by the engine (or up to the Integration's discretion if it is a first-time sync). Objects should process in batches and ``RequestDAO::getSyncIteration()`` takes care of this batching. The Sync Engine executes ``SyncDataExchangeInterface::getSyncReport()`` until a Report comes back with no objects.
+The Sync Report tells the Sync Engine what objects are new and/or modified between the two timestamps given by the engine. It's up to the Integration's discretion if it's a first-time sync. Objects should process in batches and ``RequestDAO::getSyncIteration()`` takes care of this batching. The Sync Engine executes ``SyncDataExchangeInterface::getSyncReport()`` until a Report comes back with no objects.
 
 If the Integration supports field level change tracking, it should tell the Report so that the Sync Engine can merge the two data sets more accurately.
 
@@ -87,6 +91,6 @@ ________________________
 
 .. vale on
 
-The Sync Order contains all the changes the Sync Engine has determined, and these should report to the Integration. The Integration should communicate back the ID of any objects created or adjust objects as needed, such as if they get converted from one to another or deleted.
+The Sync Order contains all the changes the Sync Engine has determined, and these should inform the Integration. The Integration should communicate back the ID of any objects created or adjust objects as needed, such as if they get converted from one to another or deleted.
 
 See :xref:`OrderExecutioner`.