shopware · Copilot · Apr 7, 2026 · Apr 7, 2026 · Apr 9, 2026 · Apr 9, 2026
diff --git a/.github/workflows/validate-external-links.yml b/.github/workflows/validate-external-links.yml
@@ -18,7 +18,16 @@ jobs:
         uses: lycheeverse/lychee-action@v2
         with:
           fail: false
-          args: --retry-wait-time 10 --max-retries 3 --timeout 30 --accept=200,403,429,408 -s "https"  "**/*.html" "**/*.md" "**/*.txt" "**/*.json" --exclude "https://github.com/\[your*" --exclude "https://localhost:9200"
+          args: >-
+            --retry-wait-time 10
+            --max-retries 3
+            --timeout 30
+            --accept=200,403,429,408
+            -s "https"
+            "**/*.html" "**/*.md" "**/*.txt" "**/*.json"
+            --exclude "https://github.com/\[your*"
+            --exclude "https://localhost:9200"
+            --exclude "/resources/admin-extension-sdk"
 
       - name: Find Link Checker Issue
         uses: micalevisk/last-issue-action@v2

diff --git a/guides/development/extensions/architecture/extendability.md b/guides/development/extensions/architecture/extendability.md
@@ -90,7 +90,7 @@ The best-known example is the [`checkout.order.placed`](https://github.com/shopw
 
 #### Hooks
 
-Hooks are another good example of the observer pattern. Hooks are entry points for apps where the so-called [**App scripts**](/docs/guides/plugins/apps/app-scripts/) are 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 where the so-called [**App scripts**](/guides/plugins/apps/app-scripts/) are 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 the controller level](https://github.com/shopware/shopware/blob/v6.4.12.0/src/Storefront/Controller/ProductController.php#L100). Each app script registered to the hook is executed.
 

diff --git a/guides/development/monetization/quality-guidelines.md b/guides/development/monetization/quality-guidelines.md
@@ -312,7 +312,7 @@ Use Scheme.org's [Schema Markup Validator](https://validator.schema.org/) and Go
 
 ## Tools
 
-Use the [Shopware CLI](/development/tooling/cli) to build, validate, and upload Shopware 6 plugin releases to the Community Store. It also supports efficiently managing store descriptions and plugin images.
+Use the [Shopware CLI](/products/cli/) to build, validate, and upload Shopware 6 plugin releases to the Community Store. It also supports efficiently managing store descriptions and plugin images.
 
 ## Final notes
 

diff --git a/...xtensions/advanced-search/How-to-define-your-custom-Elasticsearch-definition.md b/...xtensions/advanced-search/How-to-define-your-custom-Elasticsearch-definition.md
@@ -9,7 +9,7 @@ nav:
 
 In the previous implementation, the Elasticsearch index was language-based, meaning each system's language would be indexed in a separate index. With the introduction of the multilingual index:
 
-Each index will contain multiple language-based fields; refer to the [ADR](/docs/resources/references/adr/2023-04-11-new-language-inheritance-mechanism-for-opensearch) and adjust your custom Elasticsearch definition's configuration mapping to adapt to the new mapping structure.
+Each index will contain multiple language-based fields; refer to the [ADR](/resources/references/adr/2023-04-11-new-language-inheritance-mechanism-for-opensearch) and adjust your custom Elasticsearch definition's configuration mapping to adapt to the new mapping structure.
 
 For instance, to define your custom Elasticsearch definition (this definition will be used for later examples).
 

diff --git a/resources/guidelines/code/core/database-migations.md b/resources/guidelines/code/core/database-migations.md
@@ -33,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](/docs/resources/guidelines/code/backward-compatibility.html) for minor and patch releases and support blue-green deployment.
+As every other change, also your database changes should always be [backward compatible](/resources/guidelines/code/backward-compatibility) 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)

diff --git a/resources/guidelines/code/core/extendability.md b/resources/guidelines/code/core/extendability.md
@@ -85,7 +85,7 @@ We often use this pattern to realize **functional extensibility** and **function
 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**](/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**.
+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/) 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.
 

diff --git a/resources/guidelines/code/core/feature-flags.md b/resources/guidelines/code/core/feature-flags.md
@@ -7,7 +7,7 @@ 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 compability take a look to our [Backward Compatibility Guide](/docs/resources/guidelines/code/backward-compatibility.html)
+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](/resources/guidelines/code/backward-compatibility)
 
 ### 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:

diff --git a/resources/references/adr/2020-08-12-implement-app-system-inside-platform.md b/resources/references/adr/2020-08-12-implement-app-system-inside-platform.md
@@ -56,7 +56,7 @@ Additionally, the storefront theme files (JS and CSS) only need to be accessed d
 
 * [Custom Fields](https://docs.shopware.com/en/shopware-platform-dev-en/app-system-guide/app-base-guide?category=shopware-platform-dev-en/app-system-guide#custom-fields): An app can register it's own custom fields sets, that are displayed along the other custom fields inside the administration.
 
-* [Storefront Customizations](/docs/guides/plugins/apps/storefront/): An app should be able to customize the storefront in the same way a plugin does. This includes the theme system, custom twig templates and custom JS and CSS.
+* [Storefront Customizations](/guides/plugins/apps/storefront/): An app should be able to customize the storefront in the same way a plugin does. This includes the theme system, custom twig templates and custom JS and CSS.
 In regard to the theme system apps are treated the same way as plugins are, especially regarding the theme inheritance. Apps can be explicitly set in the inheritance chain via `@TechnicalAppName`, if they are not referenced directly they are part of the fallback `@Plugins` namespace.
 
 Extension points may be added as new features of the app system, but we have to make sure that it does not violate one of the limitations mentioned above. Additionally, it needs to be taken into account that it's possible to deploy and run that feature in the cloud environment.

diff --git a/...adr/2024-10-02-vue-2-options-api-to-vue-3-composition-api-conversion-codemod.md b/...adr/2024-10-02-vue-2-options-api-to-vue-3-composition-api-conversion-codemod.md
@@ -14,7 +14,7 @@ You can find the original version [here](https://github.com/shopware/shopware/bl
 
 ## Context
 
-Our Vue.js application currently uses the Options API, which is the traditional way of writing Vue components in Vue 2. With the release of Vue 3, the Composition API was introduced, offering improved code organization, better TypeScript support, and enhanced reusability of component logic. For more detailed information about the reasons for migrating to the Composition API, see the [documentation entry](/docs/guides/plugins/plugins/administration/system-updates/vue-native.html).
+Our Vue.js application currently uses the Options API, which is the traditional way of writing Vue components in Vue 2. With the release of Vue 3, the Composition API was introduced, offering improved code organization, better TypeScript support, and enhanced reusability of component logic. For more detailed information about the reasons for migrating to the Composition API, see the [documentation entry](/guides/upgrades-migrations/administration/vue-native).
 
 To modernize our codebase and take advantage of these benefits, we need to migrate our existing Vue 2 Options API components to use the Vue 3 Composition API. Manual conversion of numerous components would be time-consuming and error-prone. Therefore, we need an automated solution to assist in this migration process.