[create-pull-request] automated change (#2241)

Co-authored-by: shopwareBot <example@example.com>

Author: github-actions[bot]

…delines/code/core/database-migrations.md …idelines/code/core/database-migations.mdresources/guidelines/code/core/database-migrations.md renamed to resources/guidelines/code/core/database-migations.md resources/guidelines/code/core/database-migrations.md renamed to resources/guidelines/code/core/database-migations.md

@@ -1,5 +1,4 @@
 ## Introduction
-
 Changing the database structure of Shopware is an important and sensitive topic, because it can effect the installation of customers and their data in many ways.
 Therefore, it is important for every developer to understand the core principles of database migrations, also in the case of backward compatibility.
 
@@ -34,7 +33,7 @@ The migration consists of two separated steps: `update` and `updateDestructive`.
 
 ## Backward compatibility
 
-As every other change, also your database changes should always be [backward compatible](../backward-compatibility.md) for minor and patch releases and support blue-green deployment.
+As every other change, also your database changes should always be [backward compatible](/docs/resources/guidelines/code/backward-compatibility.html) for minor and patch releases and support blue-green deployment.
 A common technique is the [expand and contract](https://www.tim-wellhausen.de/papers/ExpandAndContract/ExpandAndContract.html) pattern, which will help you to implement your changes in a backward compatible way.
 
 * **Expand**: Instead of renaming an existing column, create a new column with the updated name. (non-destructive)
@@ -85,7 +84,7 @@ Migrations are executed in following order.
 
 ::: info
 This document represents core guidelines and has been mirrored from the core in our Shopware 6 repository.
-You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/coding-guidelines/core/database-migrations.md)
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/coding-guidelines/core/database-migations.md)
 :::
 
 ### 1. NEVER change an executed migration

resources/guidelines/code/core/extendability.md

@@ -14,7 +14,6 @@ Regarding software extendability, different business cases and requirements must
 The requirements are divided into technical requirements and business requirements.
 
 ## Technical requirements
-
 When talking about technical requirements, we talk about how we have to design our software for different extension use cases. These use cases include:
 
 * Functional extensibility
@@ -31,7 +30,6 @@ When talking about technical requirements, we talk about how we have to design o
   * Ex: An external newsletter system should be connected
 
 ## Business requirements
-
 When talking about business requirements, we talk about how the above technical requirements are used in different business cases. These business cases include:
 * Marketplace extensions
   * We should build the software so everyone can easily provide new features in certain areas.
@@ -44,7 +42,6 @@ When talking about business requirements, we talk about how the above technical
   * Ex: Assets should be able to be loaded via CDN as there are several App Servers.
 
 ## Approaches
-
 These business cases are realized with the following three conceptual approaches:
 - Project templates
   - Large customers have their deployments in which they deploy a fork of our production template.
@@ -58,7 +55,6 @@ These business cases are realized with the following three conceptual approaches
   - Plugin technology is designed to replace all areas in Shopware
 
 ## Patterns
-
 All the above requirements and approaches are based on different design patterns within our architecture. To realize the extensibility, we use the following patterns, which allow the third-party developer to extend our software:
 
 * Decoration
@@ -68,38 +64,32 @@ All the above requirements and approaches are based on different design patterns
 * Adapter
 
 ### Decoration
-
 With the Decoration pattern, we make it possible to replace or extend certain areas in Shopware completely. We often use this pattern for our Store API routes to provide more functionality in the Store API. Another use case is the **functional replacement market** case, where we can completely replace features with other technologies or external libraries.
 
 An example Store API route is the CategoryRoute. For this route, there is an [Abstract class](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Content/Category/SalesChannel/AbstractCategoryRoute.php) to which we type behind a [Concrete implementation](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Content/Category/SalesChannel/CategoryRoute.php) and a [Cache decorator](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Content/Category/SalesChannel/CachedCategoryRoute.php)
 
 ### Factory
-
 The factory pattern is often used when we have to interpret user input and validate or enrich this input before it is passed to the application.
 One use case for the factory pattern is the **Functional extensibility**, to allow third-party developers to add new factories, which allow other user input.
 
 A good example is the [line item factory registry](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Checkout/Cart/LineItemFactoryRegistry.php). This registry is used when an item is to be added to the shopping cart via store-API. [The corresponding handler](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Checkout/Cart/LineItemFactoryHandler/ProductLineItemFactory.php) is responsible for the instantiation of the line item and enriches it with necessary data.
 
 ### Visitor
-
 The visitor pattern is often used when we process some objects within our application. This pattern is often used to fit the **Functional extensibility** and **Functional modifiability** requirements. In theory, after or before the core visitors are executed, the third party visitors are executed, and they can visit the objects and manipulate or extend the processed data beforehand or afterward to manipulate the result.
 
 A good example of the visitor pattern is the [cart processor](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Checkout/Cart/Processor.php). The processor calls all line item processors, like the [product cart process](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Content/Product/Cart/ProductCartProcessor.php), to modify the provided cart object and transport the line items from the previous cart to the calculated.
 
 ### Mediator
-
 We often use this pattern to realize **functional extensibility** and **functional modifiability** to manipulate data or extend it with additional data sources. The best-known example of this pattern in our application is Events. We use events to create different entry points for developers to trigger specific processes.
 
 The best-known example is the [`checkout.order.placed`](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Checkout/Cart/Event/CheckoutOrderPlacedEvent.php) event. This event is [dispatched](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Core/Checkout/Cart/SalesChannel/CartOrderRoute.php#L151) as soon as an order is created in the system. However, over time, it has been shown that it is best practice not to pass objects or entities around in events, but only a corresponding primary key so that the connected listeners can determine the data for themselves. Furthermore, possible asynchronous processing of the underlying processes is easier to realize this way. An optimized variant of this event would not contain the `private OrderEntity $order;` but only the primary key for the order `private string $orderId;`.
 
 #### Hooks
-
-Hooks are another good example of the observer pattern. Hooks are entry points for apps in which the so-called [**App scripts**](../../../../guides/plugins/apps/app-scripts/index.md) is enabled. Since apps do not have the permission to execute code on the server directly, hooks are a way to execute more complex business logic within the request without having to address the own app server via HTTP. Hooks are the equivalent of **events**.
+Hooks are another good example of the observer pattern. Hooks are entry points for apps in which the so-called [**App scripts**](/docs/guides/plugins/apps/app-scripts/) is enabled. Since apps do not have the permission to execute code on the server directly, hooks are a way to execute more complex business logic within the request without having to address the own app server via HTTP. Hooks are the equivalent of **events**.
 
 One of the best-known hooks is the [`product page loaded hook`](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Storefront/Page/Product/ProductPageLoadedHook.php). This hook allows apps to load additional data on the product detail page. The hook is instantiated and dispatched [at controller level](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Storefront/Controller/ProductController.php#L100). Each app script, which is registered to the hook, is executed.
 
 ### Adapter
-
 The adapter pattern is perfectly designed for **Functional exchange market**. We often realize this by allowing the user to do some configuration and select a corresponding adapter. These adapters are usually registered inside a registry, and third-party developers can easily add new adapters via events or via tagged services.
 
 A good example is the captcha implementation. The store owner can configure a [captcha type](https://docs.shopware.com/en/shopware-en/settings/basic-information#captcha), and we then use the [corresponding adapter](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Storefront/Framework/Captcha/HoneypotCaptcha.php#L11) in the code for the configured captcha.

resources/guidelines/code/core/feature-flags.md

@@ -6,23 +6,19 @@ You can find the original version [here](https://github.com/shopware/shopware/bl
 :::
 
 ## Introduction
-
 Feature flags enable the developer to create new code which is hidden behind the flag and merge it into the trunk branch, even when the code is not finalized.
-We use this functionality to merge breaks into the trunk early, without them already being switched active. To learn more about breaking changes and backward compatibility take a look to our [Backward Compatibility Guide](../backward-compatibility.md).
+We use this functionality to merge breaks into the trunk early, without them already being switched active. To learn more about breaking changes and backward compability take a look to our [Backward Compatibility Guide](/docs/resources/guidelines/code/backward-compatibility.html)
 
 ### Activating the flag
-
 To switch flags on and off you can use the ***.env*** to configure each feature flag. Using dots inside an env variable are not allowed, so we use underscore instead:
 ```
 V6_5_0_0=1
 ```
 
 ## Using flags in PHP
-
 The feature flag can be used in PHP to make specific code parts only executable when the flag is active.
 
 ### Using flags in methods
-
 When there is no option via the container you can use additional helper functions:
 
 ```php
@@ -101,15 +97,14 @@ class ApiController
 ```
 
 ### Using flags in tests
-
 You can flag a test by using the corresponding helper function. This can also be used in the `setUp()` method.
 
 ```php
 use Shopware\Core\Framework\Feature;
 
 class ProductTest
 {
-  public function testNewFeature()
+  public function testNewFeature() 
   {
      Feature::skipTestIfActive('v6.5.0.0', $this);
 
@@ -118,12 +113,10 @@ class ProductTest
 }
 ```
 
-## Using flags in the Administration
-
+## Using flags in the administration
 Also in the JavaScript code of the administration the flags can be used in various ways.
 
 ### Using flags for modules
-
 You can also hide complete admin modules behind a flag:
 
 ```javascript
@@ -135,7 +128,6 @@ Module.register('sw-awesome', {
 ```
 
 ### Using flags in JavaScript
-
 To use a flag in a VueJS component you can inject the feature service and use it.
 ```
 inject: ['feature'],
@@ -146,7 +138,6 @@ featureIsActive(flag) {
 ```
 
 ### Using flags in templates
-
 When you want to toggle different parts of the template you can use the flag in a VueJs condition if you injected the service in the module:
 
 ```html
@@ -167,11 +158,9 @@ When you want to toggle config input fields in config.xml like [basicInformatati
 ```
 
 ## Using flags in the storefront
-
 In the Storefront it works nearly similar to the admin.
 
 ### Using flags in storefront JavaScript
-
 ```
 import Feature from 'src/helper/feature.helper';
 ...
@@ -183,25 +172,21 @@ data() {
 ```
 
 ### Using flags in storefront templates
-
 ```
 {% if feature('v6.5.0.0') %}
     <span>Feature is active</span>
 {% endif %}
 ```
 
 ## Using flags in plugins
-
 Feature flags can also be used in plugins. Among other things, by adding your own flags, but also the use of the major feature flag is an intended use case.
 
 ### Major feature flag
-
 As mentioned before, we use the major feature flags (`v6.5.0.0`, `v6.6.0.0`) to signal breaks within the code ahead of time. This is an incredible help in the preparation of the next major release, as otherwise all breaks would have to be made within a short period of time.
 
 This procedure can also be applied to plugins, which also use this flag and internally query it to either prepare the plugin for the next major or to support multiple Shopware major versions with one plugin version. Since each major feature flag remains after the corresponding release, they can be used as an alternative version switch to the php equivalent `version_compare`.
 
 ### Own plugin flags
-
 <alert-box type="warning">This is internal only and we may break this behaviour at any time!</alert-box>
 
 When you need to implement a feature flag for a plugin you can't edit the feature.yaml or provide an override for it,