From fea9932a9c80061c47080d53dbe865b5a450c9bc Mon Sep 17 00:00:00 2001
From: shopwareBot <shopwareBot@users.noreply.github.com>
Date: Fri, 4 Sep 2026 07:04:47 +0200
Subject: [PATCH 1/5] Update
 guides/upgrades-migrations/administration/vue-native.md for PR #20006:
 feat(administration): shim for sfc override templates to twig templates

---
 .../administration/vue-native.md              | 192 +++++++++++++++++-
 1 file changed, 189 insertions(+), 3 deletions(-)

diff --git a/guides/upgrades-migrations/administration/vue-native.md b/guides/upgrades-migrations/administration/vue-native.md
index 4c5cd09d5c..545894d061 100644
--- a/guides/upgrades-migrations/administration/vue-native.md
+++ b/guides/upgrades-migrations/administration/vue-native.md
@@ -108,6 +108,126 @@ The following table shows the current status of both systems and the direction t
 | Twig.js blocks             | Standard     | Will be deprecated and removed once the migration to native blocks is complete |
 | Native blocks (`sw-block`) | Experimental | Will become the standard for core components and extensions                    |
 
+#### Overriding Twig-based core components from native `.vue` files
+
+During the migration period, you can write Administration overrides as native `.vue` files even when the core component you target still uses Twig.js.
+
+Use this approach when:
+
+- your plugin already uses native Vue SFC overrides
+- the core component has not yet been migrated to native blocks
+- you want to keep your extension on the native override path where possible
+
+A native override still follows the same `*.override.vue` convention:
+
+```vue
+<template>
+    <sw-block extends="sw-text-field">
+        <sw-block-parent />
+
+        <span class="my-help-text">{{ helpText }}</span>
+    </sw-block>
+</template>
+
+<script setup>
+defineProps({
+    helpText: {
+        type: String,
+        required: false,
+        default: '',
+    },
+});
+</script>
+```
+
+If the targeted Twig component contains a matching block, the override is mounted into that block during template resolution.
+
+#### How to choose the correct target block
+
+For Twig-based core components, the `extends` value must match the original Twig block name you want to replace or extend.
+
+Example Twig core template:
+
+```twig
+{% block sw-text-field %}
+    <input type="text" v-model="value" @change="onChange">
+{% endblock %}
+```
+
+Matching native override:
+
+```vue
+<template>
+    <sw-block extends="sw-text-field">
+        <sw-block-parent />
+        <span class="my-help-text">Extra content</span>
+    </sw-block>
+</template>
+```
+
+If your override does not render, verify the following first:
+
+1. The file name matches `*.override.vue`
+2. The block name in `extends` matches the Twig block name exactly
+3. Your override file is part of the Administration build
+4. The target block structure is supported by the compatibility bridge described below
+
+#### Supported migration scenario
+
+This hybrid setup is intended for the migration period:
+
+- **Core component:** Twig.js template
+- **Plugin override:** native `*.override.vue`
+
+You can use this to migrate plugin overrides incrementally instead of waiting until every core component has been converted to native Vue blocks.
+
+#### Limitations of native overrides against Twig templates
+
+This bridge does not provide full parity with native-to-native overrides.
+
+Use a legacy Twig override instead if the target Twig block uses a structure that cannot host a single `sw-block` insertion point.
+
+In particular, blocks that contain multiple named slot templates are not supported.
+
+Example of an unsupported Twig block structure:
+
+```twig
+{% block sw_order_list_content %}
+    <template #content>
+        ...the whole order list
+    </template>
+
+    <template #sidebar>
+        <sw-sidebar>
+            ... filter-panel ...
+        </sw-sidebar>
+    </template>
+{% endblock %}
+```
+
+For blocks like this, keep using the legacy Twig-based extension technique until the core component is migrated.
+
+#### Troubleshooting native overrides for Twig components
+
+If your native override renders nothing, work through this checklist:
+
+1. **Check the file name**
+   - Use the `*.override.vue` suffix
+
+2. **Check the block name**
+   - `extends="..."` must match the Twig block exactly
+
+3. **Check whether the target is Twig or native**
+   - For native core components, use the native override path as usual
+   - For Twig core components, only supported block structures can be bridged
+
+4. **Inspect the original Twig template**
+   - Look for a single block content area
+   - If the block contains several sibling `<template #...>` slot templates, use a Twig override instead
+
+5. **Rebuild the Administration**
+   - Override target detection happens during the Administration build process
+
 ### 3. Vuex to Pinia
 
 #### Why Make This Change?
@@ -282,6 +402,34 @@ const props = defineProps({
 </script>
 ```
 
+#### Extension override against a legacy Twig core component
+
+If the core component still uses Twig.js, you can still keep the native override file format as long as the targeted Twig block is supported by the bridge.
+
+```vue
+<template>
+    <sw-block extends="sw-text-field">
+        <sw-block-parent />
+
+        <span class="my-help-text">{{ helpText }}</span>
+    </sw-block>
+</template>
+
+<script setup>
+const props = defineProps({
+    helpText: {
+        type: String,
+        required: false,
+        default: '',
+    },
+});
+</script>
+```
+
+Use this pattern when you want to migrate extension overrides to SFCs before the corresponding core component has been migrated.
+
+If the target Twig block uses unsupported structures, fall back to a classic Twig override.
+
 #### Extension new component
 
 ```javascript
@@ -302,12 +450,46 @@ Shopware.Component.register('your-crazy-ai-field', {
 
 Once the migration is complete and the new systems have left the experimental state, registering components via `Shopware.Component.register` with the Options API or Twig.js templates will no longer be possible. This will only happen in a future major version.
 
+## Build behavior for native override files
+
+Administration override files following the `*.override.vue` naming convention are processed during the Administration build.
+
+For native overrides that target Twig-based core components, the build scans the override template for referenced block targets and registers those targets before runtime template resolution.
+
+You do not need to register those targets manually.
+Your task as an extension author is to:
+
+1. create the override as `*.override.vue`
+2. reference the target block through `<sw-block extends="...">`
+3. rebuild the Administration so the override target is detected
+
+Example:
+
+```vue
+<template>
+    <sw-block extends="sw-product-detail-base__advanced-prices">
+        <sw-block-parent />
+        <div class="my-plugin-extra-content">...</div>
+    </sw-block>
+</template>
+```
+
+Because target detection is build-time based, keep these recommendations in mind:
+
+- use explicit `extends="block-name"` values
+- avoid patterns that hide the target block name from template analysis
+- rebuild after renaming override files or changing block targets
+
 ## FAQ
 
 **Will existing extensions built with the Options API continue to work?**
 
 When you only use `Shopware.Component.register`, yes. If you use `Shopware.Component.extend`/`Shopware.Component.override` on components that have been migrated to the Composition API, you need to use the Composition API extension approach for those.
 
+**Can I write a native `*.override.vue` file for a core component that still uses Twig?**
+
+Yes, for supported Twig block structures. Use `<sw-block extends="...">` with the original Twig block name. If the block structure is unsupported, use a legacy Twig override.
+
 **How can I prepare my development team for the transition to Composition API?**
 
 I would recommend building a simple Vue application using the Composition API. You can do so by following [official guides](https://vuejs.org/guide/extras/composition-api-faq.html).
@@ -322,7 +504,7 @@ Yes, as long as you stick to the limitations from the migration paths above.
 
 **How will the migration from Twig.js templates to .vue files affect my existing component overrides?**
 
-You will need to migrate your overrides to the native block implementation once the components you are overriding have been migrated to `.vue` files.
+You will need to migrate your overrides to the native block implementation once the components you are overriding have been migrated to `.vue` files. During the migration period, supported Twig core components can also be targeted by native `*.override.vue` files.
 
 **What tools or resources will be available to help migrate existing components?**
 
@@ -342,9 +524,13 @@ They will stop working once Twig.js support is removed. This will only happen in
 
 **Can I already use the native blocks and Composition API in my extensions today?**
 
-Yes! Both systems are available as experimental features. You can add new components using SFC and native blocks. But you can't extend core components using the old systems or vice versa. Keep in mind that experimental APIs can still change.
+Yes. You can add new components using SFC and native blocks. You can also use native `*.override.vue` files for migrated core components and for many legacy Twig-based core components with supported block structures. Keep in mind that experimental APIs can still change.
+
+**Which Twig blocks are not good candidates for native overrides yet?**
+
+Blocks containing multiple named slot templates, or similar structures without a single safe insertion point, should still be overridden through legacy Twig techniques.
 
 **Which extensions are affected by these changes?**
 
 - Apps aren't affected at all
-- Plugins need to respect the discussed changes
+- Plugins need to respect the discussed changes
\ No newline at end of file

From eea207c6ab10b8bd48fb9c218c7aa1c5cb8fa355 Mon Sep 17 00:00:00 2001
From: shopwareBot <shopwareBot@users.noreply.github.com>
Date: Fri, 4 Sep 2026 07:04:49 +0200
Subject: [PATCH 2/5] Update guides/upgrades-migrations/administration/index.md
 for PR #20006: feat(administration): shim for sfc override templates to twig
 templates

---
 guides/upgrades-migrations/administration/index.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/guides/upgrades-migrations/administration/index.md b/guides/upgrades-migrations/administration/index.md
index 2d01354dc4..66db5c5bda 100644
--- a/guides/upgrades-migrations/administration/index.md
+++ b/guides/upgrades-migrations/administration/index.md
@@ -7,7 +7,9 @@ nav:
 
 # Administration
 
-These guides cover architectural changes and migration paths affecting Administration extensions, helping you prepare plugins for major system transitions. Depending on the version, some changes—for example, Vue 3, Pinia, and Vite—may have already been completed:
+These guides cover architectural changes and migration paths affecting Administration extensions, helping you prepare plugins for major system transitions. Depending on the migration stage of the component you work with, you may use native Vue extensions against fully migrated components and, for many cases, against legacy Twig-based core components through the compatibility guidance in the native Vue migration guide.
+
+Use these guides for the corresponding extension strategy:
 
 * [Vue 3 migration](./vue3)
 * [Meteor components](./meteor-components)
@@ -16,4 +18,6 @@ These guides cover architectural changes and migration paths affecting Administr
 * [Vue migration build removal](./vue-migration-build)
 * [Native Vue implementation](./vue-native)
 
-For automated detection and fixing of supported Administration migration patterns, see the [Shopware CLI automatic refactoring](../../../products/tools/cli/automatic-refactoring.md) guide.
+If you want to override Administration components with `.vue` files, start with [Native Vue implementation](./vue-native). That guide explains when a native override can target a legacy Twig-based core component, how Twig blocks are matched, and which Twig structures still require legacy Twig overrides.
+
+For automated detection and fixing of supported Administration migration patterns, see the [Shopware CLI automatic refactoring](../../../products/tools/cli/automatic-refactoring.md) guide.
\ No newline at end of file

From 8cbef8dd3fea74cc482012522bcb4c07a01bca8b Mon Sep 17 00:00:00 2001
From: shopwareBot <shopwareBot@users.noreply.github.com>
Date: Fri, 4 Sep 2026 07:04:50 +0200
Subject: [PATCH 3/5] Update
 guides/upgrades-migrations/administration/vue-migration-build.md for PR
 #20006: feat(administration): shim for sfc override templates to twig
 templates

---
 .../administration/vue-migration-build.md     | 170 +++++++++++++++++-
 1 file changed, 169 insertions(+), 1 deletion(-)

diff --git a/guides/upgrades-migrations/administration/vue-migration-build.md b/guides/upgrades-migrations/administration/vue-migration-build.md
index 94a887bd3f..6197f273e2 100644
--- a/guides/upgrades-migrations/administration/vue-migration-build.md
+++ b/guides/upgrades-migrations/administration/vue-migration-build.md
@@ -142,6 +142,174 @@ this.myObject.key = 'value';
 delete this.myObject.key;
 ```
 
+## Using native `.vue` overrides with legacy Twig-based administration components
+
+During the administration migration, you can write native Vue single-file component overrides even when the targeted core administration component still renders its template through Twig.
+
+Use this approach when you want to keep your extension in native `.vue` format instead of maintaining a Twig override.
+
+### When to use this approach
+
+Use a native `.vue` override if all of the following are true:
+
+- your extension is already migrated to Vue 3
+- the core administration component is still Twig-based
+- you only need to replace or extend supported Twig blocks
+- the override template renders a normal component structure without unsupported multi-slot Twig block layouts
+
+If the target Twig block is not supported by the compatibility layer, keep using the legacy Twig override technique for that component.
+
+### Basic override structure
+
+Create your administration override component in `.vue` format and target the same component name you would use for other administration overrides.
+
+Example registration:
+
+```js
+import template from './sw-product-list-override.vue';
+
+Shopware.Component.override('sw-product-list', {
+    template,
+});
+```
+
+Example override template:
+
+```vue
+<template>
+    {% block sw_product_list_grid %}
+    <div class="my-product-list-grid">
+        <sw-data-grid
+            v-bind="$attrs"
+            v-on="$attrs"
+        />
+    </div>
+    {% endblock %}
+</template>
+```
+
+### How block targeting works
+
+When you use a native `.vue` override against a Twig-based core component, the override must still target Twig block names that exist in the original core template.
+
+Use the original Twig component template to identify the correct block name:
+
+```twig
+{% block sw_product_list_grid %}
+    <sw-data-grid
+        :data-source="products"
+    />
+{% endblock %}
+```
+
+Then reference that same block in your `.vue` override:
+
+```vue
+<template>
+    {% block sw_product_list_grid %}
+    <div class="my-product-list-grid">
+        <sw-data-grid
+            :data-source="products"
+        />
+    </div>
+    {% endblock %}
+</template>
+```
+
+If the block name does not match a block in the target Twig template, your override is not rendered.
+
+### Recommended migration workflow
+
+1. Check whether the target administration component is still Twig-based.
+2. Inspect the core template and identify the block you want to override.
+3. Create a native `.vue` override and wrap your replacement content in the matching Twig block.
+4. Rebuild the administration.
+5. Verify the rendered output in the browser.
+6. If the override is not rendered, confirm that:
+   - the component name in `Shopware.Component.override(...)` is correct
+   - the Twig block name matches the core template exactly
+   - the target block does not use an unsupported slot structure
+
+### Unsupported Twig block structures
+
+Some Twig blocks cannot be targeted reliably through a native `.vue` override.
+
+In particular, avoid this approach for blocks that contain multiple named slot templates, for example:
+
+```twig
+{% block sw_order_list_content %}
+    <template #content>
+        ...
+    </template>
+
+    <template #sidebar>
+        <sw-sidebar>
+            ...
+        </sw-sidebar>
+    </template>
+{% endblock %}
+```
+
+For blocks like this, continue using a Twig-based override.
+
+### Troubleshooting native-to-Twig overrides
+
+If your native override is not rendered:
+
+- verify the override is registered with the correct component name
+- verify the targeted Twig block exists in the core component
+- verify the block is not one of the unsupported multi-slot structures
+- rebuild the administration so the override template is processed again
+- test with a minimal override first to confirm the block is reachable
+
+Minimal test override:
+
+```vue
+<template>
+    {% block sw_product_list_grid %}
+    <div style="padding: 16px; background: #ffe9a8;">
+        Override reached
+    </div>
+    {% endblock %}
+</template>
+```
+
+If the test override renders, the block is supported and your original implementation should be reviewed for template or runtime errors.
+
+## Build-time handling of override templates
+
+Administration override templates are processed during the build.
+
+For native `.vue` overrides that target Twig-based core components, the build step analyzes the override template for Twig block usage. To make this work reliably:
+
+- keep the targeted Twig block names directly inside the override template
+- avoid generating block names dynamically
+- rebuild the administration after changing block names or moving override templates
+
+A typical extension setup looks like this:
+
+```js
+import overrideTemplate from './sw-order-list-override.vue';
+
+Shopware.Component.override('sw-order-list', {
+    template: overrideTemplate,
+});
+```
+
+```vue
+<template>
+    {% block sw_order_list_actions %}
+    <div class="my-order-list-actions">
+        <sw-button size="small" variant="primary">
+            Custom action
+        </sw-button>
+    </div>
+    {% endblock %}
+</template>
+```
+
+Because block detection happens from the override template source, use explicit Twig block declarations in the file that you pass as `template`.
+
 ## Conclusion
 
-In Shopware 6.7, the Vue migration build was removed entirely. To ensure compatibility, all plugins must be updated to Vue 3 following the official migration guide. If you encounter challenges during migration, refer to the official Vue 3 documentation or seek assistance from the Shopware developer community.
+In Shopware 6.7, the Vue migration build was removed entirely. To ensure compatibility, all plugins must be updated to Vue 3 following the official migration guide. If you encounter challenges during migration, refer to the official Vue 3 documentation or seek assistance from the Shopware developer community.
\ No newline at end of file

From 964512a31de2bd76f307b6012d43866201084104 Mon Sep 17 00:00:00 2001
From: shopwareBot <shopwareBot@users.noreply.github.com>
Date: Fri, 4 Sep 2026 07:04:51 +0200
Subject: [PATCH 4/5] Update guides/upgrades-migrations/administration/vite.md
 for PR #20006: feat(administration): shim for sfc override templates to twig
 templates

---
 .../administration/vite.md                    | 114 +++++++++++++++++-
 1 file changed, 112 insertions(+), 2 deletions(-)

diff --git a/guides/upgrades-migrations/administration/vite.md b/guides/upgrades-migrations/administration/vite.md
index 61df8be77e..491242614e 100644
--- a/guides/upgrades-migrations/administration/vite.md
+++ b/guides/upgrades-migrations/administration/vite.md
@@ -61,6 +61,92 @@ export default defineConfig({
 
 This is a very basic example. The Vite config can be much more complex and powerful. You can find more information about the Vite config in the [Vite documentation](https://vite.dev/config/). Depending on your webpack config, the migration can vary greatly.
 
+### Use native Vue overrides with legacy Twig components
+
+During the Administration migration, a plugin can use native Vue `*.override.vue` files even when the targeted core component still uses a Twig template.
+
+Use this approach when:
+
+- your extension is written as native Vue SFCs
+- the core Administration component you want to override is still Twig-based
+- a plain `*.override.vue` file would otherwise render nothing
+
+#### How to create the override
+
+1. Create an override component that targets the existing component name.
+2. Implement the desired block override in the SFC template.
+3. Build or watch the Administration as usual.
+
+Example structure:
+
+```text
+src/Resources/app/administration/src/
+├── component/
+│   └── sw-product-list/
+│       └── sw-product-list.override.vue
+└── main.ts
+```
+
+Example override:
+
+```vue
+<template>
+    <sw-block name="sw_product_list_smart_bar_actions">
+        <template #default="{ blockProps }">
+            <mt-button variant="primary">
+                My custom action
+            </mt-button>
+        </template>
+    </sw-block>
+</template>
+```
+
+Build the Administration:
+
+```bash
+composer build:js:admin
+```
+
+Or run the watcher:
+
+```bash
+composer watch:admin
+```
+
+If the targeted Twig block is supported, the override is injected into the legacy Twig component automatically.
+
+#### When to use Twig overrides instead
+
+Keep using legacy Twig-based overrides if your target block structure cannot be mapped safely into a native `sw-block` host.
+
+A known unsupported pattern is a Twig block that contains multiple named slot templates:
+
+```twig
+{% block sw_order_list_content %}
+    <template #content>
+        ...
+    </template>
+
+    <template #sidebar>
+        <sw-sidebar>
+            ...
+        </sw-sidebar>
+    </template>
+{% endblock %}
+```
+
+For structures like this, continue using the legacy Twig extension technique for that component.
+
+#### Troubleshooting native overrides against Twig components
+
+If your `*.override.vue` file is loaded but nothing is rendered:
+
+1. Confirm that the core target component is still Twig-based.
+2. Confirm that your override uses the correct Twig block name.
+3. Rebuild the Administration to ensure block detection runs again.
+4. Check whether the target block contains multiple named slot templates. If so, use a Twig-based override instead.
+5. Test with `composer watch:admin` and reload the Administration to verify the override is registered in development mode.
+
 ## Implementation details
 
 In this section, we'll document the implementation details of the new Vite setup.
@@ -90,6 +176,7 @@ The script will do the following:
 1. Get all bundles/plugins from the `<shopwareRoot>/var/plugins.json`
 2. Call `build` from Vite for each plugin
 3. The `build` function of Vite will automatically load `vite.config` files from the path of the entry file.
+4. During override processing, `*.override.vue` files are scanned for target block usage so mixed native-Vue-to-Twig override scenarios can be prepared before runtime template resolution.
 
 ### Dev mode/HMR server
 
@@ -143,7 +230,30 @@ const { ref } = window['Shopware']['Vue'];
 
 ### override-component
 
-Registering `*.override.vue` files automatically. It will search for all files matching the override pattern and automatically import them into the bundle/plugin entry file. Additionally, these imports will be registered as override components by calling `Shopware.Component.registerOverrideComponent`. This ensures that all overrides are loaded immediately when the bundle/plugin script is injected. To learn more about the new overrides, take a look at the Vue native docs right next to this file.
+Registering `*.override.vue` files automatically. It will search for all files matching the override pattern and automatically import them into the bundle/plugin entry file. Additionally, these imports will be registered as override components by calling `Shopware.Component.registerOverrideComponent`. This ensures that all overrides are loaded immediately when the bundle/plugin script is injected.
+
+When an override targets a legacy Twig-based component, the build step also analyzes the override template for referenced block names. Those targets are registered before runtime so the Twig template system can attach `sw-block` hosts where supported.
+
+Use this behavior as follows:
+
+1. Create a `*.override.vue` file for the component you want to extend.
+2. Reference the intended block explicitly in the template.
+3. Run `composer build:js:admin` or `composer watch:admin`.
+4. Verify the block is rendered in Administration.
+
+Example:
+
+```vue
+<template>
+    <sw-block name="sw_dashboard_index_content_intro_content_headline">
+        <template #default>
+            <h1>Custom headline</h1>
+        </template>
+    </sw-block>
+</template>
+```
+
+If the target is unsupported by the Twig compatibility layer, use the legacy Twig override approach for that specific component. To learn more about the new overrides, take a look at the Vue native docs right next to this file.
 
 ### twigjs
 
@@ -155,4 +265,4 @@ A quick note on HMR (Hot Module Replacement). Vite is only capable of reloading
 
 ## Performance
 
-Vite can build the core Administration in ~18s on my system. This is a saving of over 50% compared to Webpack. In dev mode, it's similar but not directly comparable. The Vite dev server starts instantly, moving the loading time to the first request. Webpack, on the other hand, compiles ahead of time until the server is ready.
+Vite can build the core Administration in ~18s on my system. This is a saving of over 50% compared to Webpack. In dev mode, it's similar but not directly comparable. The Vite dev server starts instantly, moving the loading time to the first request. Webpack, on the other hand, compiles ahead of time until the server is ready.
\ No newline at end of file

From 73ee4a16c4615891816edc279b77c0cbb5a6a40f Mon Sep 17 00:00:00 2001
From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com>
Date: Fri, 4 Sep 2026 09:42:36 +0000
Subject: [PATCH 5/5] Fix Markdown trailing newlines

Co-authored-by: bojanrajh <117360292+bojanrajh@users.noreply.github.com>
---
 guides/upgrades-migrations/administration/index.md              | 2 +-
 guides/upgrades-migrations/administration/vite.md               | 2 +-
 .../upgrades-migrations/administration/vue-migration-build.md   | 2 +-
 guides/upgrades-migrations/administration/vue-native.md         | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/guides/upgrades-migrations/administration/index.md b/guides/upgrades-migrations/administration/index.md
index 66db5c5bda..14f5abb7ae 100644
--- a/guides/upgrades-migrations/administration/index.md
+++ b/guides/upgrades-migrations/administration/index.md
@@ -20,4 +20,4 @@ Use these guides for the corresponding extension strategy:
 
 If you want to override Administration components with `.vue` files, start with [Native Vue implementation](./vue-native). That guide explains when a native override can target a legacy Twig-based core component, how Twig blocks are matched, and which Twig structures still require legacy Twig overrides.
 
-For automated detection and fixing of supported Administration migration patterns, see the [Shopware CLI automatic refactoring](../../../products/tools/cli/automatic-refactoring.md) guide.
\ No newline at end of file
+For automated detection and fixing of supported Administration migration patterns, see the [Shopware CLI automatic refactoring](../../../products/tools/cli/automatic-refactoring.md) guide.
diff --git a/guides/upgrades-migrations/administration/vite.md b/guides/upgrades-migrations/administration/vite.md
index 491242614e..5b0446650b 100644
--- a/guides/upgrades-migrations/administration/vite.md
+++ b/guides/upgrades-migrations/administration/vite.md
@@ -265,4 +265,4 @@ A quick note on HMR (Hot Module Replacement). Vite is only capable of reloading
 
 ## Performance
 
-Vite can build the core Administration in ~18s on my system. This is a saving of over 50% compared to Webpack. In dev mode, it's similar but not directly comparable. The Vite dev server starts instantly, moving the loading time to the first request. Webpack, on the other hand, compiles ahead of time until the server is ready.
\ No newline at end of file
+Vite can build the core Administration in ~18s on my system. This is a saving of over 50% compared to Webpack. In dev mode, it's similar but not directly comparable. The Vite dev server starts instantly, moving the loading time to the first request. Webpack, on the other hand, compiles ahead of time until the server is ready.
diff --git a/guides/upgrades-migrations/administration/vue-migration-build.md b/guides/upgrades-migrations/administration/vue-migration-build.md
index 6197f273e2..b629df756e 100644
--- a/guides/upgrades-migrations/administration/vue-migration-build.md
+++ b/guides/upgrades-migrations/administration/vue-migration-build.md
@@ -312,4 +312,4 @@ Because block detection happens from the override template source, use explicit
 
 ## Conclusion
 
-In Shopware 6.7, the Vue migration build was removed entirely. To ensure compatibility, all plugins must be updated to Vue 3 following the official migration guide. If you encounter challenges during migration, refer to the official Vue 3 documentation or seek assistance from the Shopware developer community.
\ No newline at end of file
+In Shopware 6.7, the Vue migration build was removed entirely. To ensure compatibility, all plugins must be updated to Vue 3 following the official migration guide. If you encounter challenges during migration, refer to the official Vue 3 documentation or seek assistance from the Shopware developer community.
diff --git a/guides/upgrades-migrations/administration/vue-native.md b/guides/upgrades-migrations/administration/vue-native.md
index 545894d061..ebcbd2b4a0 100644
--- a/guides/upgrades-migrations/administration/vue-native.md
+++ b/guides/upgrades-migrations/administration/vue-native.md
@@ -533,4 +533,4 @@ Blocks containing multiple named slot templates, or similar structures without a
 **Which extensions are affected by these changes?**
 
 - Apps aren't affected at all
-- Plugins need to respect the discussed changes
\ No newline at end of file
+- Plugins need to respect the discussed changes