Markdownlint: blanks-around-lists

Author: mnocon

.markdownlint-cli2.yaml

@@ -15,6 +15,7 @@ config:
     style: leading_and_trailing
 
   no-trailing-spaces: true
+  blanks-around-lists: true
   no-trailing-punctuation:
     punctuation: [".", ":", ";",]
 

docs/cdp/cdp_activation/cdp_data_export.md

@@ -107,6 +107,7 @@ Go to the **Audience Builder** and select **Build new audience**.
 When naming the audience remember, you need to find it in a drop-down list during activation.
 There, you can choose conditions from `did`, `did not` or `have`.
 The conditions `did` and `did not` allow you to use events like buy, visit or add to a cart from online tracking.
+
 - `have` conditions are tied to personal characteristics and can be used to track the sum of all buys or top-visited categories.
 
 In the Audience Builder, you can also connect created audiences to the activations.

docs/cdp/cdp_data_customization.md

@@ -64,7 +64,7 @@ The interface is plain and has two methods that you need to provide:
 - **process** - takes `Field` instance and then returns a flat array of scalar values that are combined with the payload data.
 ​
 A common field type is serialized to:
-​
+
 ```json
 {
     "field_measurement_simple_id": 1792,
@@ -109,13 +109,13 @@ To customize export of field type values, provide your own [`\Ibexa\Contracts\Cd
 New implementation has to be registered as a service manually or by using autoconfiguration.
 The service has to use the tag `ibexa.cdp.export.content.field_value_processor`.
 You can also provide `priority` property to override other Field Value Processors.
-​
+
 * `FieldValueProcessorInterface::process` - takes `Field` instance and returns an `array` with scalar values that are applied to export data payload.
 If the field type returns a single value, provides a `value` key in the array.
 You can return multiple values.
 
 * `FieldValueProcessorInterface::supports` - decides whether `FieldValueProcessor` can work with the `Field`.
-​
+
 ### Built in Field Value Processors for custom field types
 ​
 Several system Field Value Processors either work by default or can be registered for custom field types:

docs/release_notes/ez_platform_v2.3.md

@@ -96,6 +96,7 @@ Improvements to the API cover:
 #### Back office translations
 
 There are three new ways you can now contribute to back office translations:
+
 - translate in-context with bookmarks
 - translate in-context with console
 - translate directly on the Crowdin website

docs/release_notes/ez_platform_v3.0_deprecations.md

@@ -420,10 +420,10 @@ This change is introduced without BC breaks.
 
 Following API methods have been removed:
 
-* `\eZ\Publish\API\Repository\ContentService::removeTranslation`
-* `\eZ\Publish\API\Repository\UserService::loadAnonymousUser`
-* `\eZ\Publish\API\Repository\Repository::getCurrentUser`
-* `\eZ\Publish\API\Repository\Repository::getCurrentUserReference`
+- `\eZ\Publish\API\Repository\ContentService::removeTranslation`
+- `\eZ\Publish\API\Repository\UserService::loadAnonymousUser`
+- `\eZ\Publish\API\Repository\Repository::getCurrentUser`
+- `\eZ\Publish\API\Repository\Repository::getCurrentUserReference`
 - `\eZ\Publish\API\Repository\Repository::setCurrentUser`
 - `\eZ\Publish\API\Repository\Repository::hasAccess`
 - `\eZ\Publish\API\Repository\Repository::canUser`

docs/resources/new_in_doc.md

@@ -766,6 +766,7 @@ Enhanced the PHP API with the following new classes and interfaces:
 - Added edition information to [PHP API reference](https://doc.ibexa.co/en/4.6/api/php_api/php_api_reference/) to aid navigation
 
 ### REST API
+
 - Removed multiple obsolete RAML types from the [REST API reference](https://doc.ibexa.co/en/4.6/api/rest_api/rest_api_reference/rest_api_reference.html)
 
 ### User management
@@ -1173,6 +1174,7 @@ Enhanced the PHP API with the following new classes and interfaces:
 - [Work with product attributes](https://doc.ibexa.co/projects/userguide/en/latest/pim/work_with_product_attributes/) in User Documentation
 
 ### REST API
+
 - Added example of input payload in JSON format for [ContentTypeCreate in REST API reference](https://doc.ibexa.co/en/4.6/api/rest_api/rest_api_reference/rest_api_reference.html#managing-content-create-content-type)
 - [Expected user](https://doc.ibexa.co/en/4.6/api/rest_api/rest_api_usage/rest_requests/#expected-user) header support
 

docs/search/aggregation_reference/daterange_aggregation.md

@@ -9,6 +9,7 @@ The field-based [DateRangeAggregation](/api/php_api/php_api_reference/classes/Ib
 ## Arguments
 
 [[= include_file('docs/snippets/aggregation_arguments.md') =]]
+
 - `ranges` - array of Range objects that define the borders of the specific range sets
 
 ## Example

docs/search/aggregation_reference/datetimerange_aggregation.md

@@ -9,6 +9,7 @@ The field-based [DateTimeRangeAggregation](/api/php_api/php_api_reference/classe
 ## Arguments
 
 [[= include_file('docs/snippets/aggregation_arguments.md') =]]
+
 - `ranges` - array of Range objects that define the borders of the specific range sets
 
 ## Example

docs/search/aggregation_reference/floatrange_aggregation.md

@@ -9,6 +9,7 @@ The field-based [FloatRangeAggregation](/api/php_api/php_api_reference/classes/I
 ## Arguments
 
 [[= include_file('docs/snippets/aggregation_arguments.md') =]]
+
 - `ranges` - array of Range objects that define the borders of the specific range sets
 
 ## Example

docs/search/aggregation_reference/integerrange_aggregation.md

@@ -9,6 +9,7 @@ The field-based [IntegerRangeAggregation](/api/php_api/php_api_reference/classes
 ## Arguments
 
 [[= include_file('docs/snippets/aggregation_arguments.md') =]]
+
 - `ranges` - array of Range objects that define the borders of the specific range sets
 
 ## Example