shopware · Isengo1989 · Dec 3, 2024 · Dec 2, 2024 · Dec 2, 2024 · Dec 2, 2024
diff --git a/.github/workflows/markdown-style-check.yml b/.github/workflows/markdown-style-check.yml
@@ -13,9 +13,10 @@ jobs:
     - name: Check out code
       uses: actions/checkout@v4
 
-    - name: Lint changelog file
+    - name: Lint all files
       uses: docker://avtodev/markdown-lint:v1.5
       with:
         config: 'markdown-style-config.yml'
         args: './'
-        ignore: './resources/guidelines/code/core/* ./resources/references/* ./adr/* ./'
+        ignore: './resources/references/adr/* ./assets/adr/* ./resources/guidelines/code/core/* ./snippets/guide/*'
+      continue-on-error: false
diff --git a/Makefile b/Makefile
@@ -1,7 +1,7 @@
 #! /usr/bin/env make
 
 user := "$(shell id -u):$(shell id -g)"
-ignored = '/docs/resources/references/* /docs/adr/*'
+ignored = '/docs/resources/references/adr/* /docs/assets/adr/* /docs/resources/guidelines/code/core/* /docs/snippets/guide/*'
 image = jonasbn/github-action-spellcheck:0.43.0
 
 .PHONY : help lint fix

diff --git a/README.md b/README.md
@@ -18,12 +18,10 @@ The developer documentation is organized into sections covering :
 - [Products](./products/)
 - [Resources](./resources/)
 
-Refer to its [structure](./index.md) to understand better. Contributions to improve the content are welcome, following the outlined [contribution guidelines](./resources/guidelines/documentation-guidelines/06-doc-process.md). The markdown content undergoes workflow checks for easier maintenance. Further details are outlined below. 
-
+Refer to its [structure](./index.md) to understand better. Contributions to improve the content are welcome, following the outlined [contribution guidelines](./resources/guidelines/documentation-guidelines/06-doc-process.md). The markdown content undergoes workflow checks for easier maintenance. Further details are outlined below.
 
 ![Developer docs](./assets/developer-docs.png)
 
-
 ## Workflows
 
 They are defined in the [`.github/workflows`](./.github/workflows/) folder and help the DX team to maintain the documentation. The workflows are triggered by events like `push`, `pull_request`, `schedule` and `workflow_dispatch`. The workflows are used to build, test, and deploy the documentation. If a PR pipeline fails, the PR will be marked as failed, and it won't be possible to merge it. In this case, check the below-mentioned workflows to see what went wrong and where to fix it.
@@ -52,7 +50,6 @@ The `/docs/assets` folder stores images, videos, and other files linked in markd
 
 [Lychee](https://github.com/lycheeverse/lychee) is used to check if external links are working properly or broken. The configuration for lychee can be found in [`validate-external-links.yml`](./.github/workflows/validate-external-links.yml).
 
-
 ### Synced files
 
 Certain files within the `shopware/shopware` repository are duplicated in the `shopware/docs` repository for reference purposes. Any modifications made to the former files will automatically synchronize with the corresponding files in the latter repository by the [`update-adrs`](./.github/workflows/update-adrs.yml) workflow.

diff --git a/concepts/commerce/content/shopping-experiences-cms.md b/concepts/commerce/content/shopping-experiences-cms.md
@@ -148,11 +148,11 @@
 Let's go through the steps one by one.
 
 1. **Load category**: This can be initiated through an API call or a page request \(e.g., through the Storefront\).
-1. **Load CMS layout**: Shopware will load the CMS layout associated with the category.
-1. **Build resolver context**: This object will be passed on and contains information about the request and the sales channel context.
-1. **Assemble criteria for every element**: Every CMS element within the layout has a `type` configuration which determines the correct page resolver to resolve its content. Together with the **resolver context**, the resolver is able to resolve the correct criteria for the element. All criteria are collected in a criteria collection. Shopware will optimize those criteria \(e.g. by splitting searches from direct lookups or merging duplicate requests\) and execute the resulting queries.
-1. **Override slot configuration**: The resulting configuration determine the ultimate configuration of the slots that will be displayed, so Shopware will use it to override the existing configuration.
-1. **Respond with CMS page**: Since the page data is finally assembled, it can be passed on to the view layer where it will be interpreted and displayed.
+2. **Load CMS layout**: Shopware will load the CMS layout associated with the category.
+3. **Build resolver context**: This object will be passed on and contains information about the request and the sales channel context.
+4. **Assemble criteria for every element**: Every CMS element within the layout has a `type` configuration which determines the correct page resolver to resolve its content. Together with the **resolver context**, the resolver is able to resolve the correct criteria for the element. All criteria are collected in a criteria collection. Shopware will optimize those criteria \(e.g. by splitting searches from direct lookups or merging duplicate requests\) and execute the resulting queries.
+5. **Override slot configuration**: The resulting configuration determine the ultimate configuration of the slots that will be displayed, so Shopware will use it to override the existing configuration.
+6. **Respond with CMS page**: Since the page data is finally assembled, it can be passed on to the view layer where it will be interpreted and displayed.
 
 ### Extensibility
 

diff --git a/concepts/extensions/apps-concept.md b/concepts/extensions/apps-concept.md
@@ -12,7 +12,7 @@
 The app system is designed to be decoupled from Shopware itself. This has two great advantages:
 
 1. **Freedom of choice:** You need to understand only the interface between Shopware and your app to get started with developing your own app. You don't need special knowledge of the inner workings and internal structure of Shopware itself. Additionally, you have the freedom to choose a programming language or framework of your choice to implement your app. This is achieved by decoupling the deployment of Shopware itself and your app and by using the Admin API and webhooks to communicate between Shopware and your app instead of using programming language constructs directly.
-1. **Fully cloud compatible:** By decoupling Shopware and your app, your app is automatically compatible for use in a multi-tenant cloud system. Therefore your app can be used within self-hosted shops and shops on [Shopware SaaS](../../products/saas).
+2. **Fully cloud compatible:** By decoupling Shopware and your app, your app is automatically compatible for use in a multi-tenant cloud system. Therefore your app can be used within self-hosted shops and shops on [Shopware SaaS](../../products/saas).
 
 The central interface between your app and Shopware is defined by a dedicated manifest file. The manifest is what glues Shopware and your app together. It defines your app's features and how Shopware can connect to it. You can find more information about how to use the manifest file in the [App base Guide](../../guides/plugins/apps/app-base-guide).
 

diff --git a/concepts/extensions/index.md b/concepts/extensions/index.md
@@ -11,13 +11,13 @@ In order to provide users \(i.e., developers\) with a clear abstraction, Shopwar
 
 ## Apps
 
-![](../../assets/concepts-extensions-apps.svg)
+![App concept](../../assets/concepts-extensions-apps.svg)
 
 Starting with Shopware 6.4.0.0, we introduced a new way to extend Shopware using the newly created app system. Apps are not executed within the process of the Shopware Core but are notified about events via webhooks, which they can register. They can modify and interact with Shopware resources through the [Admin REST API](https://shopware.stoplight.io/docs/admin-api/twpxvnspkg3yu-quick-start-guide).
 
 ## Plugins
 
-![](../../assets/concepts-extensions-plugins.svg)
+![Plugin concept](../../assets/concepts-extensions-plugins.svg)
 
 Plugins are executed within the Shopware Core process and can react to events, execute custom code or extend services. They have direct access to the database and guidelines are in place to ensure update-compatibility, such as a service facade or database migrations.
 

diff --git a/concepts/framework/data-abstraction-layer.md b/concepts/framework/data-abstraction-layer.md
@@ -16,7 +16,7 @@ The DAL is implemented with the specific needs of Shopware in mind and lets deve
 Some concepts used by the DAL, like Criteria, may sound familiar to you if you know [Doctrine](https://symfony.com/doc/current/doctrine.html) or other ORMs.
 A reference to more in-depth documentation about the DAL can be found below.
 
-Refer to [Shopware 6.6.5.0 entity relationship model](../../../assets/shopware6-erd.pdf) that depicts different tables and their relationships. 
+Refer to [Shopware 6.6.5.0 entity relationship model](../../../assets/shopware6-erd.pdf) that depicts different tables and their relationships.
 
 Alternatively, you can export a fresh ER model, using [MySQL Workbench](https://dev.mysql.com/doc/workbench/en/wb-reverse-engineering.html), [PHPStorm Database Tools](https://www.jetbrains.com/help/phpstorm/creating-diagrams.html), or similar tool.
 
@@ -64,9 +64,9 @@ The DAL was designed, among other things, to enable the special requirements of
 When a record is read or searched, three language levels are searched.
 
 1. **Current language**: The first level is the current language that is set and displayed to the user.
-1. **Parent language**: the second level is an optional parent language that can be configured. 
+2. **Parent language**: the second level is an optional parent language that can be configured.
 So it is possible to translate certain dialects faster.
-1. **System language**: The third and last level is the system language that is selected during the installation.
+3. **System language**: The third and last level is the system language that is selected during the installation.
 Each entity in the system has a translation in this language.
 This serves as a final fallback to ensure only one label for the entity in the end.
 

diff --git a/concepts/framework/http_cache.md b/concepts/framework/http_cache.md
@@ -22,7 +22,7 @@ So whenever a user requests a page, Shopware will create a result page individua
 * A reverse proxy cache
 * The web application generates a result
 
-![](../../assets/concepts-framework-httpCache.svg)
+![Http cache concept](../../assets/concepts-framework-httpCache.svg)
 
 The reverse proxy is located between the user and the web application and takes care of any requests to the web application. If a user requests a page that has been requested before, chances are that the reverse proxy can just hand out the same result as before, so the web application will not even be asked.
 

diff --git a/concepts/framework/rules.md b/concepts/framework/rules.md
@@ -70,7 +70,7 @@ As you can see, a single rule can either contain user defined values or other us
 
 The last building block is the **Rule Scope**. The Scope contains the current runtime state of the application and is necessary to match the data. The whole picture is visualized in the next diagram:
 
-![](../../assets/framework-rules-rulesScope.svg)
+![Rule scope](../../assets/framework-rules-rulesScope.svg)
 
 ## Connection to the System
 

diff --git a/concepts/framework/system-check.md b/concepts/framework/system-check.md
@@ -29,7 +29,7 @@ And to ensure clear terminology, we have defined the following logical concepts
 
 ### Category
 
-The category aims to cluster what the check is verifying rather than to categorize the type of check itself. 
+The category aims to cluster what the check is verifying rather than to categorize the type of check itself.
 Each component logically falls into a certain category. Functional categories are used to group checks together. The following categories are available:
 
 - `SYSTEM`: System checks make sure that the backbone of the software is functioning correctly. For example, a database connection.

diff --git a/guides/hosting/configurations/index.md b/guides/hosting/configurations/index.md
@@ -40,4 +40,4 @@ If you want to aim at a specific environment, you can create a configuration fil
          └── mailer.yaml
 ```
 
-For more information on environment-specific configurations, check out the [Symfony Configuration Environments](https://symfony.com/doc/current/configuration.html#configuration-environments) section.
+For more information on environment-specific configurations, check out the [Symfony Configuration Environments](https://symfony.com/doc/current/configuration.html#configuration-environments) section.
diff --git a/guides/hosting/configurations/observability/logging.md b/guides/hosting/configurations/observability/logging.md
@@ -17,7 +17,6 @@ Configuration of Monolog is done in the `config/packages/prod/monolog.yaml` file
 
 <<< @/docs/snippets/config/monolog.yaml
 
-
 ## Log levels
 
 Monolog supports the following log levels:
@@ -31,7 +30,6 @@ Monolog supports the following log levels:
 - `ALERT`: Action must be taken immediately. Example: Entire website down, database unavailable, etc. This should trigger the SMS alerts and wake you up.
 - `EMERGENCY`: Emergency: system is unusable.
 
-
 ## Log sent e-mails and other flow events
 
 To monitor all sent e-mails and other flow events set the `business_event_handler_buffer` to `info` level:

diff --git a/guides/hosting/configurations/observability/profiling.md b/guides/hosting/configurations/observability/profiling.md
@@ -27,7 +27,7 @@ shopware:
 ```
 
 ::: info
-The OpenTelemetry profiler is not installed by default. Checkout the [OpenTelemetry Integration](./opentelemetry.md) to learn how to install it. 
+The OpenTelemetry profiler is not installed by default. Checkout the [OpenTelemetry Integration](./opentelemetry.md) to learn how to install it.
 :::
 
 ## Adding custom spans
@@ -76,4 +76,4 @@ class ConsoleProfiler implements ProfilerInterface
 </service>
 ```
 
-The attribute `integration` is used to identify the profiler backend in the configuration.
+The attribute `integration` is used to identify the profiler backend in the configuration.
diff --git a/guides/hosting/configurations/shopware/html-sanitizer.md b/guides/hosting/configurations/shopware/html-sanitizer.md
@@ -35,5 +35,4 @@ If you want to deactivate the sanitizer despite security risks, you can also do
 Disabling the HTML sanitizer will allow potentially unsafe or malicious HTML code to be inserted.
 :::
 
-
 <!-- {"WATCHER_URL":"https://raw.githubusercontent.com/shopware/shopware/trunk/src/Core/Framework/Resources/config/packages/shopware.yaml","WATCHER_HASH":"183f85ba8f15e8e7d0006b70be20940f","WATCHER_CONTAINS":"html_sanitizer"} -->
diff --git a/guides/hosting/configurations/shopware/staging.md b/guides/hosting/configurations/shopware/staging.md
@@ -22,11 +22,12 @@ The recommended way to create a second Shopware instance would be to deploy from
 An alternative way would be to copy the files from the live environment to the staging environment.
 
 ### Copying the database
+
 ::: info
 Ensure that the `mysqldump` and `mysql` binary are from the same major version and vendor. If you use `mysqldump` from MariaDB, you should also use `mysql` from MariaDB. The same applies to MySQL.
 :::
 
-To have the staging environment similar to the live environment, it's recommended that the database be duplicated. You can use the `mysqldump` command to export the database and import it into the staging environment. 
+To have the staging environment similar to the live environment, it's recommended that the database be duplicated. You can use the `mysqldump` command to export the database and import it into the staging environment.
 
 ::: info
 `shopware-cli` is a separate Go command line application that contains a lot of useful commands for Shopware. [Checkout the docs](https://sw-cli.fos.gg/install/) to learn how to install it.
@@ -45,6 +46,7 @@ shopware-cli project dump --clean --anonymize --host localhost --username db_use
 You can configure the dump command with a `.shopware-project.yml`. This file allows you to specify tables that should be skipped, define additional fields for anonymization, and more. Check out the [CLI](https://sw-cli.fos.gg/commands/project/#shopware-cli-project-dump-database) for more information.
 
 ### Configuration
+
 ::: info
 It is not recommended to share resources like MySQL, Redis, ElasticSearch/OpenSearch between the live and staging environments. This could lead to data corruption when the configuration is not done correctly. Also, the performance of the live environment could be affected by the staging environment.
 :::
@@ -58,7 +60,7 @@ After the database is imported and the configuration is done, you can activate t
 ```bash
 ./bin/console system:setup:staging
 ```
- 
+
 This command will modify the database to be used in a staging environment. You can pass `--no-interaction` to the command to avoid the interactive questions.
 
 ### Protecting the staging environment
@@ -85,7 +87,6 @@ An alternative way could be to use an Application Proxy before the staging envir
 - [Azure Application Gateway](https://azure.microsoft.com/en-us/services/application-gateway/)
 - [Generic oauth2 proxy](https://oauth2-proxy.github.io/oauth2-proxy/)
 
-
 ## Staging mode
 
 The staging mode is designed to be used in a test environment. This means the shop is prepared to be used in a test environment, where changes can be made without affecting the live shop.
@@ -134,7 +135,6 @@ One of the most important options is the `domain_rewrite`. This option allows yo
 
 - Using direct match (`equal`)
 
-
 ```yaml
 # <shopware-root>/config/packages/staging.yaml
 shopware:
@@ -213,4 +213,3 @@ class StagingSubscriber implements EventSubscriberInterface
     }
 }
 ```
-
diff --git a/guides/hosting/configurations/shopware/static-system-config.md b/guides/hosting/configurations/shopware/static-system-config.md
@@ -55,4 +55,4 @@ and then set the environment variable in your `.env` file:
 ```dotenv
 # .env.local
 ALLOW_BUY_IN_LISTING=true
-```
+```
diff --git a/guides/hosting/infrastructure/filesystem.md b/guides/hosting/infrastructure/filesystem.md
@@ -68,6 +68,7 @@ By default, the configuration for the theme, asset and sitemap filesystem will u
 This means when you want to change the configuration used for the public filesystem, but the others should use the old configuration you have to set them explicitly.
 
 E.g. before you had the following configuration:
+
 ```yaml
 shopware:
   filesystem:
@@ -78,7 +79,9 @@ shopware:
         root: "%kernel.project_dir%/public"
 
 ```
+
 Now you want to change the public filesystem to use an S3 adapter, but the theme, asset and sitemap filesystem should still use the local adapter. You have to set them explicitly:
+
 ```yaml
 shopware:
   filesystem:
@@ -113,9 +116,6 @@ shopware:
 
 ### Additional configuration
 
-If you want to regulate the uploaded file types, then you could add the keys `allowed_extensions` for the public filesystem or `private_local_download_strategy` for the private filesystem.
-With the `private_local_download_strategy` key you could choose the download strategy for private files (e.g. the downloadable products):
-=======
 If you want to regulate the uploaded file types, then you could add the keys `allowed_extensions`for the public filesystem or `private_local_download_strategy` for the private filesystem.
 With the `private_local_download_strategy` key you could choose the download strategy for private files (e.g., the downloadable products):
 
@@ -224,7 +224,6 @@ shopware:
 
 The bucket needs to use the "Fine-grained" [ACL mode](https://cloud.google.com/storage/docs/access-control#choose_between_uniform_and_fine-grained_access). This is required so that Shopware can manage the ACL of the objects.
 
-
 ## Add your own adapter
 
 To create your own adapter, check out the [official Flysystem guide](https://flysystem.thephpleague.com/v1/docs/advanced/creating-an-adapter/).

diff --git a/guides/hosting/infrastructure/message-queue.md b/guides/hosting/infrastructure/message-queue.md
@@ -225,7 +225,7 @@ shopware:
   messenger:
     routing_overwrite:
       'Shopware\Core\Framework\DataAbstractionLayer\Indexing\EntityIndexingMessage': entity_indexing
-```      
+```
 
 The `shopware.messenger.routing_overwrite` config option accepts the same format as the `framework.messenger.routing` option, but it will overwrite the routing for the given message class instead of adding to it.
 This is especially useful if there is a default routing already configured based on a message interface, but you need to change the routing for a specific message.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -35,5 +35,4 @@ If you want to deactivate the sanitizer despite security risks, you can also do
		Disabling the HTML sanitizer will allow potentially unsafe or malicious HTML code to be inserted.
		:::


		<!-- {"WATCHER_URL":"https://raw.githubusercontent.com/shopware/shopware/trunk/src/Core/Framework/Resources/config/packages/shopware.yaml","WATCHER_HASH":"183f85ba8f15e8e7d0006b70be20940f","WATCHER_CONTAINS":"html_sanitizer"} -->