Vue 2 had a filter system. You wrote {{ price | currency }} in a template. But Vue 3 removed filters entirely. Every plugin template using the pipe character fails at runtime. The component renders blank or throws an error.

This is the most common Shopware admin Vue 3 break. After all, filters were everywhere in Vue 2 plugins. Price display, date formatting, string truncation — all of it used filters. Vue 3 replaced them with computed() properties and utility functions.

Shopware ships its own formatting utilities. So you do not need to write your own. Use Shopware.Utils.format.currency() for prices and Shopware.Utils.format.date() for dates. Both work correctly in all Shopware 6.5 plugin contexts.

• ✦Find every broken filter fast. Run this command in your plugin root:grep -rn "| " ./src/Resources/app/administration/src --include="*.html.twig". Every line returned has a filter that needs replacing.
• ✦For currency, useShopware.Utils.format.currency(value, currencyIsoCode, locale). It handles currency symbols, decimal places, and locale formatting in one call. No custom logic needed.
• ✦For dates, useShopware.Utils.format.date(value, options). Pass a standardIntl.DateTimeFormatoptions object as the second argument. This replaces{{ date | date }}completely.

Vue 2 plugins used the Options API. All reactive data lived in a data() function. You accessed it with this.myValue anywhere in the component. But in Vue 3, setup() runs before the component instance exists. So this is undefined inside setup().

The Options API still works in Vue 3. But you must use it consistently. The break happens when a plugin mixes both APIs. It uses setup() but still calls this.xxx inside it. This is the second most common Shopware Vue.js 3 plugin error.

• ✦Find all affected files fast:grep -rn "this\." ./src/Resources/app/administration/src --include="*.js" | grep -A2 "setup()". Anythis.call inside asetup()block will fail.
• ✦The Shopware Composition API way to access props: usetoRefs(props). This converts each prop into a reactive ref. Access the value withmyProp.value. Changes to props stay reactive.
• ✦In the Shopware Composition API, replacethis.$storewithShopware.State.get('moduleName'). Shopware’s state service works withoutthis. It is accessible anywhere in a Shopware 6.5 plugin’ssetup()function.
• ✦Lifecycle hooks insidesetup()use new names. Import them from Vue:onMounted,onBeforeUnmount,onUpdated. A pure Options API component still works. You can keepmounted()as an object key. Just never mix it withsetup()code.

Many Shopware admin plugins used Shopware.Component.extend() to override core admin views. This let plugins add fields to any admin page. You could extend the product detail view or the order screen. However, Shopware 6.5 changed how overrides bind to the Vue 3 rendering tree. So in the admin, extend() no longer works correctly.

The Shopware admin Vue 3 failure is often silent. The admin loads normally. No console error appears. But the plugin’s changes are simply gone. The product detail page shows no extra fields. The order view looks untouched. This makes it one of the harder breaks to spot.

• ✦Switch fromextend()tooverride(). This is not just a rename. Theoverride()method hooks into Vue 3’s component tree correctly. Theextend()method does not. Move all reactive state into asetup()function. Useref()orreactive()instead of thedata()function.
• ✦Note:extend()still works for storefront plugins. It is only broken in the Shopware admin context. If your plugin touches both the storefront and the admin, treat them separately. The rules differ for each side.
• ✦Check component names when overriding. Shopware 6.5 renamed several core admin components. Callingoverride()on a component that no longer exists fails silently. The admin loads. Your changes never apply. Cross-check names against the Shopware component changelog for 6.5.

Shopware also updated its own admin component library at 6.5. Several components were removed. Others were split into typed versions. So a Shopware 6.5 plugin using an old component name gets a Vue warning. That slot renders nothing at all.

The most common culprit is sw-field. It was a generic field component in Shopware 6.4. It accepted a type attribute. In 6.5, each type became its own dedicated component. You must now use sw-text-field, sw-number-field, sw-select-field, and so on.

• ✦Find allsw-component names in your plugin templates:grep -rn "<sw-" ./src/Resources/app/administration/src --include="*.html.twig". Each name should appear in the Shopware 6.5 Meteor Component Library. Any name not in the library needs a replacement.
• ✦When replacingsw-field, check the props too. Typed field components have different prop names.sw-text-fieldusesv-modeldirectly.sw-number-fieldaccepts:min,:max, and:stepprops. These did not exist on the oldsw-field.
• ✦Browse the Shopware Meteor Component Library on Storybook to preview each replacement component. It shows every slot, prop, and event. This saves time when updating complex form layouts with many fields.

Vue 3 also removed several global APIs. Older plugins used them heavily. These do not always throw obvious errors. Some fail silently. Others throw a TypeError deep in a component tree. Without knowing the cause, it is hard to trace.

Run this one command across your entire Shopware 6.5 plugin source. It finds every removed API in one pass.

Each result in that output is a line to fix. Here is the replacement for each one.

• ✦Vue.set()andVue.delete()are gone. Vue 3 uses JavaScript Proxy under the hood. Direct object mutation is reactive. You can writeobj.newProp = valueand Vue will detect it. No helper needed.
• ✦The.syncmodifier maps directly tov-model:propName. If you had:title.sync="myTitle", writev-model:title="myTitle"instead. Update the child component to emitupdate:titlerather thanupdate:sync.
• ✦$listenersis also gone. In Vue 3,$attrsnow includes event listeners. If your plugin passed listeners through withv-bind="$listeners", change it tov-bind="$attrs". AddinheritAttrs: falseto the component options if needed.