Shopware

Appearance

Release notes Shopware 6.7.0.0

17.6.2025

Release notes Shopware 6.7.0.0 ​

Abstract ​

Shopware 6.7.0.0 is a major release containing breaking changes. Please read this document and the linked resources carefully.

This release was built with the help of the community. Thanks for supporting us with pull requests (code contributions) and during the RC phase by providing feedback and testing the release under production-like conditions.

Please note that with this release, marked as stable, the major series v6.5 will not be provided with extended maintenance and support any longer. Instead, the series v6.6 will become the new "extended support" version from now on. Release Policy

The Shopware 6.7.0.0 release is focused on core changes instead of features. It provides a foundation for adding new features throughout future minor releases.

System requirements ​

  • tested on PHP 8.2 and 8.4
  • tested on MySQL 8 and MariaDB 11

See below for more information on the current minimum versions.

Improvements ​

Webpack to vite migration for the administration ​

We are switching the build system for our administration from webpack to vite. This means that when your plugins depends on a custom webpack.config.js file, you'll need to migrate it to a vite.config.js file.

Additionally, this means that you will need to distribute a separate plugin version starting for 6.7, when you extend the administration to distribute the correct build files. For more information please take a look at the docs.

Removal of Vue 2 compatibility layer ​

The Vue 2 compatibility layer has been removed from the administration. This means that all components that still rely on Vue 2 features need to be updated. This ensures that our administration stays future-proof and we can make use of the most recent Vue 3 features.

For detailed explanation of what was covered by the compatibility layer and what needs to be updated, please refer to the Vue docs.

Migration from Vuex to Pinia ​

For Vue 3, the default state management library has become Pinia, therefore we are migrating from Vuex to Pinia, to stay as close to the default as possible. When you use default stores in your plugin you need to switch from Shopware.State (Vuex) to Shopware.Store (Pinia). Adding your own Vuex stores is still possible, however it is recommended that you switch to Pinia as well.

Vuex breaking change ​

Due to the migration from Vuex to Pinia, the Vuex helper utils have been renamed to avoid conflicts with Pinia helpers. If you are still using Vuex, please update your code accordingly:

    mapState -> mapVuexState
    mapMutations -> mapVuexMutations
    mapGetters -> mapVuexGetters
    mapActions -> mapVuexActions

For more information refer to the docs.

vue-i18n v10 Update ​

We have updated vue-i18n to version 10, which introduces a significant change by removing the tc function. In Shopware, $tc remains available on Vue components, but it now internally references the t function from vue-i18n.

  • While this change works for most use cases, some specific function overloads are no longer supported.
  • For a comprehensive list of deprecated features and migration strategies, refer to the official vue-i18n migration guide.

Please review your existing translation calls, test components that heavily rely on translation methods and consider updating to the recommended t function where possible.

Cache Rework ​

Delayed Cache Invalidation ​

The cache invalidation will be delayed by default. This means that the cache will be invalidated in regular intervals and not immediately. This will lead to better cache hit rates and way less (duplicated) cache invalidations, which will improve efficiency and scalability of the system. As this feature is now active by default, the previous shopware.cache.invalidation.delay configuration has been removed.

The default interval is 5 mins and can be changed by adjusting the run interval of the shopware.invalidate_cache scheduled task.

Removal of Store-API route caching ​

The Store-API route caching has been removed. This means that the Cached*Route classes will be removed. This solves some weird states when the HTTP-Cache was invalidated separately from the route cache. Additionally, the cache hit rate for the Store-API was low, so the performance impact should be minimal, but the amount of cache items and cache invalidations will be reduced. This overall should lead to more effective cache resource usage.

The header and footer are now loaded via ESI. This allows to cache the header and footer separately from the rest of the page. Two new routes \header and \footer were added to receive the rendered header and footer.

The rendered header and footer are included into the page with the Twig function render_esi, which calls the previously mentioned routes. Two new templates src/Storefront/Resources/views/storefront/layout/header.html.twig and src/Storefront/Resources/views/storefront/layout/footer.html.twig were introduced as new entry points for the header and footer. Make sure to adjust your template extensions to be compatible with the new structure.

The block names are still the same, so it might become necessary to extend from the new templates.

Major Library Updates ​

We upgraded the following libraries to their latest versions:

  • DBAL 4.x: When you are using DBAL directly, please check the upgrade guide.
  • PHPUnit 11.x: You need to adjust your tests to the new PHPUnit version.
  • Dompdf 3.x: Please check your document templates, if they are still rendered as expected.
  • oauth2-server 9.x: We don't expect you are affected by this change on the code level, however the library does not support some requests that are not spec-compliant, look at the detailed upgrade guide.

Accessibility Compliance ​

In alignment with the European Accessibility Act (EAA) we made significant accessibility improvements.

  • Storefront product box accessibility: Removed duplicate links around the product image in product cards. Affected template: Resources/views/storefront/component/product/card/box-standard.html.twig.
  • Storefront base font-size: The base font-size of the storefront is updated to the browser standard of 1rem (16px).
  • Change Storefront language and currency drop down items to buttons: The .top-bar-list-item elements inside the "top-bar" dropdown menus will contain <button> elements instead of a hidden <input type="radio"> elements.
  • Change Storefront order items and cart line-items from <div> to <ul> and <li>: several generic <div> elements representing lists are changed to <ul> and <li> elements. This effects the account order overview area as well as the cart line-item templates.
  • Storefront pagination is using anchor links instead of radio inputs
  • Use <button> elements instead of <a> to open modal windows
  • New translation keys with button modal triggers: Some modal triggers are inside translation texts. With 6.7 new translation keys are used that have buttons instead of links. There are also new translation parameters to avoid too much HTML and modal logic inside the translation strings.
  • Storefront icons that are rendered via {% sw_icon 'icon-name' %} will apply aria-hidden="true" by default so they are hidden for screen readers. In most scenarios icons are of decorative nature and should therefore not be read as "graphic" by the screen reader.

More information regarding accessibility and the European Accessibility Act can be found in the Shopware blog.

Changed Functionality ​

Some functionality changed in a way that might be noticeable for merchants. Additionally, this means that changes over the administration (e.g. adjusting configured flows, mail templates) might be needed to adjust to the new behavior.

Vat Ids will be validated case sensitive ​

Vat Ids will now be checked for case sensitivity, which means that most Vat Ids will now have to be upper case, depending on their validation pattern. For customers without a company, this check will only be done on entry, so it is still possible to checkout with an existing lower case Vat Id. For customers with a company, this check will be done at checkout, so they will need to change their Vat Id to upper case.

Custom field names and field set names validation ​

Custom field names and field set names will be validated to not contain hyphens or dots, they must be valid Twig variable names. Existing custom fields continue to work, however the validation will be enforced on new custom fields.

Removal of deprecated properties of CustomerDeletedEvent ​

The deprecated properties customerId, customerNumber, customerEmail, customerFirstName, customerLastName, customerCompany and customerSalutationId of CustomerDeleteEvent have finally been removed and cannot be accessed anymore in a mail template when sending a mail via the Checkout > Customer > Deleted flow trigger.

Rule builder: Condition customerDefaultPaymentMethod removed ​

  • Removed condition customerDefaultPaymentMethod from rule builder, since customers do not have default payment methods anymore
  • Existing rules with this condition will be automatically migrated to the new condition paymentMethod, so the currently selected payment method

Flow builder: Trigger checkout.customer.changed-payment-method removed ​

  • Removed trigger checkout.customer.changed-payment-method from flow builder, since customers do not have default payment methods anymore
  • Existing flows will be automatically disabled with Shopware 6.7 and removed in a future via destructive migration.

Direct debit default payment: State change removed ​

The default payment method "Direct debit" will no longer automatically change the order state to "in progress". Use the flow builder instead, if you want the same behavior.

New technicalName property for payment and shipping methods ​

The technicalName property is now required for payment and shipping methods in the API. The technical_name column have been made non-nullable for the payment_method and shipping_method tables in the database.

Plugin developers now must specify a technicalName for their payment and shipping methods. Please note: If no technical name is specified before the migration is run, a temporary placeholder temporary_<method-id> will be used instead.

Merchants must review their custom created payment and shipping methods for the new technicalName property and update their methods through the administration accordingly.

API ​

We made some breaks in the API, which might affect your extensions or custom integrations.

Non spec-compliant /api/oauth/token requests are not supported anymore ​

Due to an upgrade of the "league/oauth2-server" library, some requests that are not spec-compliant with the OAuth spec are not supported anymore. Especially scopes now needed to be provided as scope parameter and as a space-delimited list of strings.

diff
grant_type: 'password',
client_id: 'administration',
- scopes: ['write', 'admin'],
+ scope: 'write admin',
username: user,
password: pass,

Removal of /api/oauth/authorize route ​

Removed API route /api/oauth/authorize (\Core\Framework\Api\Controller\AuthController::authorize method) without replacement.

Core ​

We made some changes in the PHP core, which might affect your plugins.

Native types for PHP class properties ​

All PHP class properties now have a native type. If you have extended classes with properties, which didn't have a native type before, make sure you now add them as well.

The customer entity does not have all associations loaded by default anymore. This change reduces the amount of data loaded in the Store-API Register Route and Register related events to improve the performance.

Payment: Reworked payment handlers ​

  • The payment handlers have been reworked to provide a more flexible and consistent way to handle payments.
  • The new AbstractPaymentHandler class should be used to implement payment handlers. A supports method now determines whether the recurring and refund methods can be used for a specific payment method. All other methods are invoked during every payment process, though your payment handler may not need to implement all of them.
  • The following interfaces have been deprecated and consolidated into the new AbstractPaymentHandler:
    • AsyncPaymentHandlerInterface
    • PreparedPaymentHandlerInterface
    • SyncPaymentHandlerInterface
    • RefundPaymentHandlerInterface
    • RecurringPaymentHandlerInterface
  • Synchronous and asynchronous payments have been unified to return an optional redirect response. This response defines whether the customer is redirected to a payment provider or immediately returned to the order completion page.
  • Payment handlers from plugins now receive only the orderTransactionId, request information (if applicable, e.g., not for recurring payments), and a Context. Any additional data required to process the payment must be retrieved by the payment handler itself to reduce database load. This also minimizes dependency on the SalesChannelContext, which may contain information that does not accurately reflect the order (e.g., customer addresses may differ from the order’s addresses). For apps: the same information as before is sent to the app server.

Payment: Capture step of prepared payments removed ​

  • The method capture has been removed from the PreparedPaymentHandler interface. This method is no longer being called for apps.
  • Use the pay method instead for capturing previously validated payments.

New technicalName property for payment and shipping methods ​

The technicalName property will be required for payment and shipping methods in the API. The technical_name column will be made non-nullable for the payment_method and shipping_method tables in the database.

Plugin developers will be required to supply a technicalName for their payment and shipping methods.

Merchants must review their custom created payment and shipping methods for the new technicalName property and update their methods through the administration accordingly.

Removal of Custom Entities for Plugins ​

Custom Entities for plugins support has been removed. It's no longer possible to create a Resources/config/entities.xml file in your plugin to create DAL entities. This has been removed for performance reasons. Our recommendation is to use regular EntityDefinition or an attribute based entity.

Bulletproofing Plugin Migrations ​

  • Creation timestamp is now validated
  • Plugin migrations are now removed before calling uninstall()
  • Required foreign key in mapping definition for many-to-many associations
  • Change in entity extensions
  • Logger is required for ScheduledTaskHandler
  • Elasticsearch: Return type of AbstractElasticsearchDefinition::buildTermQuery changed to BuilderInterface
  • Parameter names of some \Shopware\Core\Framework\Migration\MigrationStep changed
  • Changed PromotionGatewayInterface
  • ImportExport signature changes
  • SitemapHandleFactoryInterface::create method signature change
  • Removal of AuthController::authorize
  • TreeUpdater::batchUpdate signature change
  • Removal of CreateSchemaCommand:
  • Removal of SchemaGenerator:
  • AccountService refactoring
  • Removed CustomFieldRule comparison methods:
  • AbstractCartOrderRoute::order method signature change
  • Removal of MailTemplate deprecations
  • Unification of Cache constants
  • Domain Exception Handling Please see domain exception handling ADR
  • Removal of ConfigurationNotFoundException
  • Changed thrown exceptions in TranslationsSerializer
  • Deprecated ImportExport domain exception
  • Removal of obsolete method in DefinitionValidator
  • Removal of deprecated exceptions
  • Entity class throws different exceptions
  • Attributes classes made final
  • Moved notifications from admin to core

Administration ​

We made some changes in the administration, which might affect your extensions.

Administration removed associations ​

  • Removed calculationRule association in shippingMethodCriteria() in sw-settings-shipping-detail.
  • Removed conditions association in ruleFilterCriteria() and shippingRuleFilterCriteria() in sw-settings-shipping-price-matrix

Removal of sw-dashboard-statistics and associated component sections and data sets ​

The component sw-dashboard-statistics (src/module/sw-dashboard/component/sw-dashboard-statistics) has been removed without replacement.

The associated component sections sw-chart-card__before and sw-chart-card__after were removed, too. Use sw-dashboard__before-content and sw-dashboard__after-content instead.

Additionally, the associated data sets sw-dashboard-detail__todayOrderData and sw-dashboard-detail__statisticDateRanges were removed. In both cases, use the Admin API instead.

Replace isEmailUsed with isEmailAlreadyInUse: ​

Replace isEmailUsed with isEmailAlreadyInUse in sw-users-permission-user-detail.

Component replacement with Meteor Component Library ​

We switched the usage of basic components from custom components to the meteor component library. For more details take a look at the according ADR.

More information about how you can automate the update with codemods will be available soon.

In short this means we replaced the following components:

  • sw-popover with mt-floating-ui
  • sw-tabs with mt-tabs
  • sw-select-field with mt-select
  • sw-textarea-field with mt-textarea
  • sw-datepicker with mt-datepicker
  • sw-password-field with mt-password-field
  • sw-colorpicker with mt-colorpicker
  • sw-external-link with mt-external-link
  • sw-skeleton-bar with mt-skeleton-bar
  • sw-email-field with mt-email-field
  • sw-url-field with mt-url-field
  • sw-progress-bar with mt-progress-bar
  • sw-button with mt-button
  • sw-icon with mt-icon
  • sw-card with mt-card
  • sw-text-field with mt-text-field
  • sw-switch-field with mt-switch
  • sw-number-field with mt-number-field
  • sw-loader with mt-loader
  • sw-checkbox-field with mt-checkbox

Note that these new components follow the standard Vue conventions for passing the value to the component. In short, when a two-way binding is needed the v-model="myValue" attribute should be used. If only the value should be passed to the component :model-value=myValue should be used, but then the @update:model-value needs to be implemented. For more information refer to the Vue documentation.

We have moved the notification entity, collection and definition to core. You should update your code to reference the new classes. The old classes are deprecated.

Deprecated notification controller ​

\Shopware\Administration\Controller\NotificationController is now moved to core \Shopware\Core\Framework\Notification\Api\NotificationController - if you type hint on this class, please update it. The HTTP route is still the same. The old class is deprecated.

Mitigate Meteor components migration with deprecated components ​

To support extension developers and ensure compatibility between Shopware 6.6 and Shopware 6.7, a new prop called deprecated has been added to Shopware components.

Storefront ​

We made some changes in the Storefront, which might affect your plugins and themes.

  • Removals due to the introduction of ESI for header and footer
  • FooterPagelet changes
  • ThemeFileImporterInterface & ThemeFileImporter Removal
  • Removal of setTwig method in StorefrontController
  • Removal of deprecated product review loading logic in Storefront
  • Removal of Storefront sw-skin-alert SCSS mixin
  • Removal of Storefront alert class alert-has-icon styling
  • Removal of Storefront alert inner container alert-content
  • Update polyfills and browser-support
  • Major upgrades of NPM packages
  • Removal of NPM packages
  • Added new functions and tokens to complete the Twig integration

App System ​

We made some changes in the app-system, which might affect your apps.

  • Manifest version increased
  • Payment: payment states
  • Payment: finalize step
  • Payment: onlyAvailable flag removed from CheckoutGatewayRoute

Hosting & Configuration ​

We made some changes in the configuration and setup, which might affect your project setups.

  • XKeys module now required for Varnish read more.
  • Config keys changes due to improved redis connection handling
  • Service bundle needs to be enabled explicitly
  • Search server now provides OpenSearch/Elasticsearch shards and replicas
  • Message queue size limit at 256KB
  • Fine-grained caching is removed
  • SQL_SET_DEFAULT_SESSION_VARIABLE has no effect anymore
  • Removal of RSA JWT secrets
  • Document renderer structure change
  • AbstractDocumentRenderer render workflow

Please consider to read the complete Upgrade Guide for more information and details about this major release.

Fixed bugs ​

With this major release 200+ bugs have been fixed, between them a lot of what you guys reported during the RC phase - thanks for that! Find an (incomplete) list of fixed bugs here: https://github.com/shopware/shopware/milestone/1?closed=1

Credits ​

Thanks to all our contributors for helping us improve Shopware with every pull request!

More resources ​

Get in touch ​

Our community slack is the perfect place to discuss with the community, find help and make new friends. See you there 😉

Newsletter
Copyright © shopware AG - All rights reserved