From f355312acc9f345295034d8889f4210abacdf00e Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Tue, 7 Apr 2026 14:01:23 +0000 Subject: [PATCH 1/8] Initial plan From 40c21b56c3568049e348b236129d38659c85dced Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Tue, 7 Apr 2026 14:07:00 +0000 Subject: [PATCH 2/8] Fix broken links in link checker report Agent-Logs-Url: https://github.com/shopware/docs/sessions/38ddef6d-fa21-4767-8b8d-baf084dbea89 Co-authored-by: Isengo1989 <8600299+Isengo1989@users.noreply.github.com> --- .github/workflows/validate-external-links.yml | 2 +- guides/development/extensions/architecture/extendability.md | 2 +- guides/development/monetization/quality-guidelines.md | 2 +- .../How-to-define-your-custom-Elasticsearch-definition.md | 2 +- resources/guidelines/code/core/database-migations.md | 2 +- resources/guidelines/code/core/extendability.md | 2 +- resources/guidelines/code/core/feature-flags.md | 2 +- .../adr/2020-08-12-implement-app-system-inside-platform.md | 2 +- ...2-options-api-to-vue-3-composition-api-conversion-codemod.md | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/.github/workflows/validate-external-links.yml b/.github/workflows/validate-external-links.yml index 7d55371cc6..95124ab6f2 100644 --- a/.github/workflows/validate-external-links.yml +++ b/.github/workflows/validate-external-links.yml @@ -18,7 +18,7 @@ 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 index c9e9e8af2d..bb455a606a 100644 --- 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 index 09b523c6ee..6e7439e612 100644 --- 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/products/extensions/advanced-search/How-to-define-your-custom-Elasticsearch-definition.md b/products/extensions/advanced-search/How-to-define-your-custom-Elasticsearch-definition.md index 079c02c038..7cc55e3580 100644 --- a/products/extensions/advanced-search/How-to-define-your-custom-Elasticsearch-definition.md +++ b/products/extensions/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 index 770eb40815..8ad4146828 100644 --- 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 index d2c1ae6a0f..cc23e1ee36 100644 --- 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 index 12962858ea..caadbe87f6 100644 --- 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 index 1366c96aad..8b78206bbe 100644 --- 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/resources/references/adr/2024-10-02-vue-2-options-api-to-vue-3-composition-api-conversion-codemod.md b/resources/references/adr/2024-10-02-vue-2-options-api-to-vue-3-composition-api-conversion-codemod.md index 07468dba6d..04a86c743f 100644 --- a/resources/references/adr/2024-10-02-vue-2-options-api-to-vue-3-composition-api-conversion-codemod.md +++ b/resources/references/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. From c69e671619259346fedfe5226ad707155b05dc69 Mon Sep 17 00:00:00 2001 From: Micha Hobert Date: Thu, 9 Apr 2026 11:01:28 +0200 Subject: [PATCH 3/8] Apply suggestion from @Copilot Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- .github/workflows/validate-external-links.yml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/.github/workflows/validate-external-links.yml b/.github/workflows/validate-external-links.yml index 95124ab6f2..c246c6a336 100644 --- 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" --exclude "/resources/admin-extension-sdk" + 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 From 867a97f65bc5e9bf9c95582ba6b38ff787c0e9d6 Mon Sep 17 00:00:00 2001 From: Micha Date: Thu, 9 Apr 2026 11:12:44 +0200 Subject: [PATCH 4/8] fix/links --- guides/development/extensions/architecture/extendability.md | 2 +- products/cli/command-types.md | 2 +- .../How-to-define-your-custom-Elasticsearch-definition.md | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/guides/development/extensions/architecture/extendability.md b/guides/development/extensions/architecture/extendability.md index bb455a606a..fe9ef54301 100644 --- 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**](/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**](../../../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/products/cli/command-types.md b/products/cli/command-types.md index 4e647c40a7..e3fbddf434 100644 --- a/products/cli/command-types.md +++ b/products/cli/command-types.md @@ -31,7 +31,7 @@ shopware-cli extension fix /path/to/your/extension shopware-cli project fix /path/to/your/project ``` -Always back up or version your code before running refactoring commands, as they will modify files in place. [Learn more here](../../products/cli/automatic-refactoring.md). +Always back up or version your code before running refactoring commands, as they will modify files in place. [Learn more here](automatic-refactoring.md). ### Project commands diff --git a/products/extensions/advanced-search/How-to-define-your-custom-Elasticsearch-definition.md b/products/extensions/advanced-search/How-to-define-your-custom-Elasticsearch-definition.md index 7cc55e3580..9c519fc752 100644 --- a/products/extensions/advanced-search/How-to-define-your-custom-Elasticsearch-definition.md +++ b/products/extensions/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](/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). @@ -78,7 +78,7 @@ class YourCustomElasticsearchDefinition extends AbstractElasticsearchDefinition } /** - * Build a bool query when searching your custom ES definition, by default we use the Shopware\Commercial\AdvancedSearch\Domain\Search\SearchLogic + * Build a bool query when searching your custom ES definition, by default we use the Shopware\Commercial\AdvancedSearch\Domain\Search\SearchLogic */ public function buildTermQuery(Context $context, Criteria $criteria): BoolQuery { @@ -86,7 +86,7 @@ class YourCustomElasticsearchDefinition extends AbstractElasticsearchDefinition } /** - * fetch data from storage to push to elasticsearch cluster when indexing data + * fetch data from storage to push to elasticsearch cluster when indexing data */ public function fetch(array $ids, Context $context): array { From dd2ae736c163e18ddff2fed7851f259b3787d886 Mon Sep 17 00:00:00 2001 From: Micha Date: Thu, 9 Apr 2026 11:28:24 +0200 Subject: [PATCH 5/8] fix/links --- resources/guidelines/code/core/database-migations.md | 2 +- resources/guidelines/code/core/extendability.md | 2 +- resources/guidelines/code/core/feature-flags.md | 2 +- .../adr/2020-08-12-implement-app-system-inside-platform.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/resources/guidelines/code/core/database-migations.md b/resources/guidelines/code/core/database-migations.md index 8ad4146828..770eb40815 100644 --- 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](/resources/guidelines/code/backward-compatibility) 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) diff --git a/resources/guidelines/code/core/extendability.md b/resources/guidelines/code/core/extendability.md index cc23e1ee36..d2c1ae6a0f 100644 --- 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**](/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**](/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. diff --git a/resources/guidelines/code/core/feature-flags.md b/resources/guidelines/code/core/feature-flags.md index caadbe87f6..12962858ea 100644 --- 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](/resources/guidelines/code/backward-compatibility) +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: 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 index 8b78206bbe..1366c96aad 100644 --- 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](/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](/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. 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. From 30799c9ce2ce65016546c57b3009cb731587c2a2 Mon Sep 17 00:00:00 2001 From: Micha Date: Thu, 9 Apr 2026 11:29:30 +0200 Subject: [PATCH 6/8] fix/adr-links --- ...2-options-api-to-vue-3-composition-api-conversion-codemod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/resources/references/adr/2024-10-02-vue-2-options-api-to-vue-3-composition-api-conversion-codemod.md b/resources/references/adr/2024-10-02-vue-2-options-api-to-vue-3-composition-api-conversion-codemod.md index 04a86c743f..07468dba6d 100644 --- a/resources/references/adr/2024-10-02-vue-2-options-api-to-vue-3-composition-api-conversion-codemod.md +++ b/resources/references/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](/guides/upgrades-migrations/administration/vue-native). +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). 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. From b1cad0bda6f83dc4a359e804f786764599d0fce6 Mon Sep 17 00:00:00 2001 From: Micha Hobert Date: Thu, 9 Apr 2026 11:30:01 +0200 Subject: [PATCH 7/8] Apply suggestion from @bojanrajh Co-authored-by: Bojan Rajh <117360292+bojanrajh@users.noreply.github.com> --- guides/development/monetization/quality-guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guides/development/monetization/quality-guidelines.md b/guides/development/monetization/quality-guidelines.md index 6e7439e612..64d9fd7611 100644 --- 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](/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. +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 From 935f72302443fe9102edab98a2df98166e3363a5 Mon Sep 17 00:00:00 2001 From: Micha Date: Thu, 9 Apr 2026 16:53:10 +0200 Subject: [PATCH 8/8] add/new-path-and-go-back-to-old-config --- .github/workflows/validate-external-links.yml | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/.github/workflows/validate-external-links.yml b/.github/workflows/validate-external-links.yml index c246c6a336..9f011834b9 100644 --- a/.github/workflows/validate-external-links.yml +++ b/.github/workflows/validate-external-links.yml @@ -18,16 +18,7 @@ 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" - --exclude "/resources/admin-extension-sdk" + 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-path '(^|/)resources/guidelines/code/core(/|$)' - name: Find Link Checker Issue uses: micalevisk/last-issue-action@v2