- or
348 results found
-
Länderauswahl im Checkout für digitale und physische Produkte getrennt steuern
aktuell lassen sich die im Checkout verfügbaren Länder pro Verkaufskanal festlegen. Wäre es möglich, diese Einstellung für digitale und physische Produkte getrennt zu steuern?
Physische Waren können oft nicht in alle Länder geliefert werden oder verursachen hohe Versandkosten. Digitale Produkte hingegen lassen sich weltweit verkaufen.
At present, it is possible to specify which countries are available at checkout for each sales channel. Would it be possible to control this setting separately for digital and physical products?
Physical goods often cannot be delivered to all countries or incur high delivery costs. Digital products, on the other hand, can be sold worldwide.
1 vote -
Kundenspezifische Preise im admin / Customer specific pricing in admin
DE:
Kundenspezifische Preise sollte in Kunden > Übersicht > Kunde > neuer Reiter > Kundenspezifische Preise
einsehbar sein.Felder:
Suchfeld, welches nach Name und SKU suchen kann
SKU | Produktname | Nettopreis | Bruttopreis
Docu
https://docs.shopware.com/de/shopware-6-de/erweiterungen/kundenspezifische-preiseHinweis: es geht um die Preise die per API bei der Beyond Edition eingespielt werden und nicht B2B component individual-pricing
https://docs.shopware.com/en/shopware-6-en/commercial-features/b2b-components?category=shopware-6-en/features/commercial#individual-pricingEN:
Customer-specific prices should be visible under Customers > Overview > Customer > New Tab > Customer-specific prices.
Fields:
Search field (searching by name and SKU)
SKU | Product Name | Net Price | Gross Price
Documentation
https://docs.shopware.com/en/shopware-6-en/extensions/customer-specific-pricingNote: This refers to the prices imported via API for the Beyond Edition, not the B2B component for individual pricing.
https://docs.shopware.com/en/shopware-6-en/commercial-features/b2b-components?category=shopware-6-en/features/commercial#individual-pricingDE:
Kundenspezifische Preise sollte in Kunden > Übersicht > Kunde > neuer Reiter > Kundenspezifische Preise
einsehbar sein.Felder:
Suchfeld, welches nach Name und SKU suchen kann
SKU | Produktname | Nettopreis | Bruttopreis
Docu
https://docs.shopware.com/de/shopware-6-de/erweiterungen/kundenspezifische-preiseHinweis: es geht um die Preise die per API bei der Beyond Edition eingespielt werden und nicht B2B component individual-pricing
https://docs.shopware.com/en/shopware-6-en/commercial-features/b2b-components?category=shopware-6-en/features/commercial#individual-pricingEN:
Customer-specific prices should be visible under Customers > Overview > Customer > New Tab > Customer-specific prices.
Fields:
Search field (searching by name and SKU)
SKU | Product Name | Net Price | Gross Price
Documentation
https://docs.shopware.com/en/shopware-6-en/extensions/customer-specific-pricingNote: This refers to the…
2 votes -
Show attributes and properties in Quick Search for items without variants
In Quick Search, attributes and properties are already displayed on the right for items with variants. This information is currently unavailable for items without variants.
Please enable attributes and properties to be displayed on the right for items without variants as well, following the same presentation used for items with variants.
Benefit:
This additional information would make it easier to distinguish between similar items and find the right item more quickly.Suggested implementation:
Display the existing attributes and properties of items without variants in the results view, preferably using the same format as for items with variants.1 vote -
Custom coupon codes as variables
It should be possible to automatically send individual coupon codes via email, for example, as a variable in email templates.
3 votes -
Automated Calculation of Fees (Customs & Taxes) in Checkout for International Orders
Currently, Shopware 6 does not provide a native feature for automatically calculating variable fees such as customs duties, import taxes, or country-specific charges during checkout.
However, this functionality is increasingly important for international merchants to ensure a legally compliant and transparent order process.Competing platforms (e.g., Shopify) already offer this functionality as a built-in feature. It enables automated calculation and display of additional fees (e.g., customs duties, import VAT, service fees) based on product value, shipping destination, product category, or customs tariff number (HS code).
In Shopware, this can currently only be achieved through manual configuration using the shipping method price matrix, which is not dynamic and cannot handle complex calculation logic (e.g., article-based or country-based variations). Additionally, surcharges added via the price matrix are included in the cart subtotal, leading to incorrect tax and duty calculations when these are applied again on top.
Use Cases:
International Shipping: Merchants shipping outside the EU (e.g., to the US, UK, Canada, or Switzerland) need to automatically calculate and display customs and import duties.
Legal Compliance & Transparency: Customers should be informed of all applicable fees during checkout to prevent unexpected costs or returns.
Automation & Efficiency: Merchants want to automate fee calculation via integrations with external tax or logistics services (e.g., Avalara, Zonos, FedEx API, etc.) rather than maintaining manual tables.
Competitive Edge: Competing eCommerce systems like Shopify or BigCommerce already include this capability, putting Shopware at a disadvantage, especially for international merchants.
Suggested Implementation:
-
Introduce a dynamic fee calculation module within checkout, based on:
- Shipping destination
- Product item data (including tariff/HS code)
- Total cart value
- Potentially also carrier or fulfillment method
Provide API endpoints and plugin interfaces for integrating external tax or customs calculation services.
-
Add configurable admin settings to define:
- Which fee types should be calculated (customs, taxes, service fees, etc.)
- Whether the fees should be shown in the cart or added during checkout only.
The technical foundation could be a core-level extensibility module that third-party providers can build upon.
Benefits:
Increased legal compliance for international trade.
Transparent cost display for customers.
Reduced cart abandonment rates due to unexpected delivery charges.
Improved competitiveness and attractiveness for global and enterprise merchants.
Currently, Shopware 6 does not provide a native feature for automatically calculating variable fees such as customs duties, import taxes, or country-specific charges during checkout.
However, this functionality is increasingly important for international merchants to ensure a legally compliant and transparent order process.Competing platforms (e.g., Shopify) already offer this functionality as a built-in feature. It enables automated calculation and display of additional fees (e.g., customs duties, import VAT, service fees) based on product value, shipping destination, product category, or customs tariff number (HS code).
In Shopware, this can currently only be achieved through manual configuration using the shipping method…
16 votes -
Shopware Account Plugin License List Update
The current license list overview of the shop in the account.shopware.com is sadly not really handy for customers / agencies.
When updating to later Shopware Versions, you need mostly plugin updates to get back from a broken to a working state (e.g. 6.6 > 6.7, php bin/console fails as well):
- Therefore I have to go to said website, search for the plugin name (somehow over name / description mixed, because names are handled differently in the search)
- Then click on the plugin (when i finally found it) and get the update version.
- Another plugin must be found the same way again.
A better solution would be:
- Make the search icon search over all tab categories (rent + free + archived..)
-> faster search of single plugins
- Show the technicalName in the license list table to make it "searchable" and or via CMD/STRG+F
-> Plugin Descriptions are different in store than in plugin composer.json -> always hard to find (especially with german/english translations)
- Add function to shopware-cli that you can update / migrate plugins from custom/plugins structure to composer.json
-> handy one command to select a list of plugins to update the latest version / migrate to composerThe current license list overview of the shop in the account.shopware.com is sadly not really handy for customers / agencies.
When updating to later Shopware Versions, you need mostly plugin updates to get back from a broken to a working state (e.g. 6.6 > 6.7, php bin/console fails as well):
- Therefore I have to go to said website, search for the plugin name (somehow over name / description mixed, because names are handled differently in the search)
- Then click on the plugin (when i finally found it) and get the update version.
- Another plugin must be found the same way…
3 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
Badge : Product bought on / Produkt gekauft am
EN:
It should be a badge for already purchased products and tha last purchased date.
Naming: "Product purchased on" or "Item bought on". Like Amazon.DE:
Es sollte ein Badge geben um Produkte zu kennzeichnen, die bereits gekauft wurden sind und hier das Datum des letzten Kaufs anzeigen. So macht es beispielsweise auch Amazon.2 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
Make inherited objects scrollable/inspectable
In Categories > Layout:
eventhough a layout-section (for example a text) might be inherited from the assigned layout, make it scrollable so i can look through the text and dont need to go into the category itself.1 vote -
Reintroduce CLI commands (functionality) for Migrations
CLI commands for migrations have been removed from release 16 (see https://github.com/shopware/shopware/issues/10825) without proper replacement.
As a result it is currently not possible to migrate with a finer selection via the CLI. One has to select an entire data category (i.e. all products) to migrate, making it more difficult and time-consuming in larger shops to debug issues.
2 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
Allow saving changes by pressing Enter in the Admin
Allow saving changes by pressing Enter in the Admin
Description:
In Shopware 5, it was possible to save many changes simply by pressing the Enter key after editing a field. This made product maintenance much faster because users did not have to move their hand from the keyboard to the mouse to click Save or the checkmark.In Shopware 6, after editing fields such as prices, users always have to click the save/checkmark button with the mouse.
For merchants maintaining hundreds or thousands of products every day, this results in many unnecessary mouse clicks and slows down the workflow.
Expected behavior
After editing a field (for example a price), pressing Enter should:
Confirm the edited value.
Save or apply the change (depending on the context).
Allow the user to continue working without using the mouse.This should work consistently throughout the Shopware Admin where appropriate.
Benefits
Faster product maintenance.
Better keyboard workflow.
Fewer mouse movements.
Increased productivity for power users.
Similar workflow to Shopware 5, making migration easier.Allow saving changes by pressing Enter in the Admin
Description:
In Shopware 5, it was possible to save many changes simply by pressing the Enter key after editing a field. This made product maintenance much faster because users did not have to move their hand from the keyboard to the mouse to click Save or the checkmark.In Shopware 6, after editing fields such as prices, users always have to click the save/checkmark button with the mouse.
For merchants maintaining hundreds or thousands of products every day, this results in many unnecessary mouse clicks and slows down the workflow.
Expected…
2 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
Passwortfelder in Storefront mit "Passwort anzeigen"-Funktion ausstatten
In der Shopware-Storefront wäre es hilfreich, Passwortfelder standardmäßig mit einer Möglichkeit zum Ein- und Ausblenden des eingegebenen Passworts auszustatten, z. B. über ein Auge-Icon.
Das betrifft insbesondere:
Passwort-Wiederherstellung
Login / RegistrierungAus UX-Sicht ist das inzwischen ein verbreitetes Pattern und hilft Kunden, Tippfehler zu vermeiden. Gerade bei der Passwort-Wiederherstellung müssen Nutzer neue Passwörter oft mehrfach eingeben, wodurch eine Sichtbarkeitsoption die Bedienbarkeit verbessern würde.
Wichtig wäre, dass dies nur eine reine Frontend-Funktion ist und keine Änderung an Passwortlogik, Validierung, Sicherheit oder Speicherung vornimmt.
EN: In the Shopware Storefront, it would be helpful if password fields included an option to show and hide the entered password by default, for example via an eye icon.
This applies in particular to:
Password recovery
Login / registrationFrom a UX perspective, this has become a common pattern and helps customers avoid typos. Especially during password recovery, users often have to enter new passwords multiple times, so a visibility toggle would improve usability.
It would be important that this remains a purely frontend feature and does not change any password logic, validation, security, or storage.
In der Shopware-Storefront wäre es hilfreich, Passwortfelder standardmäßig mit einer Möglichkeit zum Ein- und Ausblenden des eingegebenen Passworts auszustatten, z. B. über ein Auge-Icon.
Das betrifft insbesondere:
Passwort-Wiederherstellung
Login / RegistrierungAus UX-Sicht ist das inzwischen ein verbreitetes Pattern und hilft Kunden, Tippfehler zu vermeiden. Gerade bei der Passwort-Wiederherstellung müssen Nutzer neue Passwörter oft mehrfach eingeben, wodurch eine Sichtbarkeitsoption die Bedienbarkeit verbessern würde.
Wichtig wäre, dass dies nur eine reine Frontend-Funktion ist und keine Änderung an Passwortlogik, Validierung, Sicherheit oder Speicherung vornimmt.
EN: In the Shopware Storefront, it would be helpful if password fields included an option to show and…
2 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
Typographically correct quotation marks in product description
The quotation marks around the product name in the product description are typographically incorrect.
Since these are hard-coded in the TWIG file component/product/description.html.twig, one suggestion would be to insert a new snippet here that renders the name with the appropriate quotation marks depending on the language.For example:
<h2 class="product-detail-description-title">
{{ 'detail.descriptionTitle'|trans|sw_sanitize }} {{ "custom.quotedName"|trans({'%name%': product.translated.name}) }}
</h2>Snippet custom.quotedName
e.g. DE: „%name%“ EN: “%name%” FR: «%name%»1 vote -
Bulk edit: Configuration GARANT Label at product
It should also be possible to edit GARANT settings (on the product) via the bulk edit function. Otherwise, performing this manually for every product involves a great deal of effort.
1 vote -
Structured data for AI readability
I recently stumbled upon this press release by one of our partners - basically an ad for their plugin: https://www.openpr.de/news/1299320/Shopware-Shops-werden-KI-sichtbar-mitho-veroeffentlicht-KI-Agentic-Commerce-Plugin.html
However, as Shopware wants to go ahead with AI massively, the proposed features seem to be basic when it comes towards being prepared for AI readability:
- structured product and category feeds in JSON format
- llms.txt and other manifests for AI
- precise microdata and JSON descriptions of variants, prices, shipping etc.
8 votes -
Maximum amount of products or maximum sum for the cart
Currently, there is no elegant way to set order limits with product amounts or the total sum per order.
One can create rules via the rule builder and use them to hide shipping methods once the limit is surpassed, but there is no transparent message for the customer that there are limits or that they have been reached.
Analogous to the “Maximum quantity” in the cart settings it would be useful to set order limits similarly, perhaps on a per sales channel basis or even on a customer group basis. Once the limit has been reached, the storefront could hinder the user from adding more items to the cart with a clear error message.
Currently, there is no elegant way to set order limits with product amounts or the total sum per order.
One can create rules via the rule builder and use them to hide shipping methods once the limit is surpassed, but there is no transparent message for the customer that there are limits or that they have been reached.
Analogous to the “Maximum quantity” in the cart settings it would be useful to set order limits similarly, perhaps on a per sales channel basis or even on a customer group basis. Once the limit has been reached, the storefront could hinder…
2 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
dynamic product group: preview should include the SKU / dynamische Produktgruppe mit Produktnummer in Vorschau
EN:
The dynamic product groups > preview > should include SKUDE:
Die dynamische Produktgruppe > Vorschau > sollte die SKU / Produktnummer beinhalten2 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
Easier customization of email templates
Customizing email templates is usually quite complex and hardly feasible for the average customer. For example, adding the manufacturer's name for each item in the order confirmation.
The entire process of customizing email templates should be significantly simplified and made much more intuitive. We also receive a large number of support requests regarding this.
5 votes -
Support href/Links in Custom Notification Text Snippets
Currently, the Shopware 6 Custom Notification plugin does not support adding clickable links using <a href="...">...</a> within text snippets.
It would be useful if text snippets used by Custom Notifications supported links. This would allow notifications not only to display information but also to direct users to relevant pages or actions.
Example:
For more information, click <a href="/example">here</a>.This would make Custom Notifications more flexible and useful, for example when linking to specific pages, actions, documentation, or additional information.
1 vote -
Quantity-based surcharges in Custom Products
Current Situation / Problem:
Custom Products allow merchants to offer additional services or configurations (e.g. sawing, drilling, processing) with fixed surcharges per selected option.
These surcharges are currently static and independent of the ordered quantity of the main product.While tiered pricing can be configured on the product level, it cannot be applied to Custom Product options or their surcharges.
Concrete Use Case
A merchant sells steel beams (e.g. HEB / HEA) and offers optional processing services via Custom Products.Example: Option “Sawing”
- Sub-options: Fixed cut, Center cut, Mitre cut
- Current behavior: fixed surcharge, e.g. €15 per cut
Desired behavior:
The price per cut should change depending on the ordered quantity of the main product, for example:- 1–3 items → €15 per cut
- 4–10 items → €10 per cut
- 11+ items → €7 per cut
The price tier is not based on the number of selected options, but on the product quantity in the cart.
Why Existing Features Are Not Sufficient:
- Advanced pricing on the product level applies globally to the product quantity, but does not affect Custom Product surcharges
- Rule-based surcharges can be enabled or disabled, but do not support tiered pricing
- Product variants are not a viable alternative because:
- They would result in a very large number of variants
- Custom Products are intentionally used for flexible, customer-specific configurationsBusiness Value / Benefits:
Relevant use case for:
- Metal processing
- Cutting and machining services
- Printing, engraving, personalizationKey benefits:
- Realistic representation of volume-based discounts for services
- Reduction of manual pricing agreements and individual offers
- Increased competitiveness for B2B shopsAvoidance of workarounds or external pricing logic
Current Situation / Problem:
Custom Products allow merchants to offer additional services or configurations (e.g. sawing, drilling, processing) with fixed surcharges per selected option.
These surcharges are currently static and independent of the ordered quantity of the main product.While tiered pricing can be configured on the product level, it cannot be applied to Custom Product options or their surcharges.
Concrete Use Case
A merchant sells steel beams (e.g. HEB / HEA) and offers optional processing services via Custom Products.Example: Option “Sawing”
- Sub-options: Fixed cut, Center cut, Mitre cut
- Current behavior: fixed surcharge, e.g. €15 per cut
Desired behavior:…
5 votes -
Allow customers to manage subscriptions in STATE_PAYMENT_FAILED
Currently, subscriptions with the state STATEPAYMENTFAILED can no longer be managed by the customer through the storefront customer account.
While the subscription itself remains active and its next execution date continues to be calculated, the available subscription actions are no longer displayed. As a result, customers cannot react to a failed payment themselves, for example by pausing or cancelling the subscription.
The subscription can still be managed through the Administration, which means customers need to contact the merchant's support team to make these changes.
Current behavior:
When a subscription enters STATEPAYMENTFAILED, the customer cannot use the subscription management actions in the customer account.In particular, the customer cannot:
- pause the subscription,
- cancel the subscription,
- otherwise manage the subscription from the storefront,
- retry or resolve the failed payment through the subscription interface.
Management through the Administration remains possible.
Expected / desired behavior:
Customers should retain appropriate self-service options when a subscription is in STATEPAYMENTFAILED.At minimum, customers should be able to cancel the subscription themselves. Ideally, the available actions could also include:
- pausing the subscription,
- retrying or resolving the failed payment,
- changing the payment method where technically supported.
Additional request:
Consider providing a secure mechanism that allows customers to react directly from a payment-failed/reminder email, especially to cancel the subscription, without first having to navigate manually to the customer account. If authentication is required, this could potentially be implemented through an appropriately secured customer/account flow.Motivation / business value:
A failed payment is precisely a situation in which customers may need to take action on their subscription. Preventing storefront management in this state creates an unnecessary dependency on merchant support.Providing self-service capabilities would:
- reduce merchant support requests,
- allow customers to react immediately to failed payments,
- improve the subscription customer experience,
- avoid situations where an active subscription can only be cancelled by contacting the merchant.
Acceptance criteria proposal:
- A subscription in STATEPAYMENTFAILED can be cancelled by the customer in the storefront.
- The cancellation action is available without requiring intervention through the Administration.
- The system clearly communicates the failed payment state to the customer.
- Where supported by the payment integration, the customer is offered a way to resolve/retry the failed payment.
- The feasibility of pause and payment-method-change actions for STATEPAYMENTFAILED is evaluated independently from cancellation.
- A secure direct-action flow from transactional emails is evaluated for cancellation and/or payment recovery.
Currently, subscriptions with the state STATEPAYMENTFAILED can no longer be managed by the customer through the storefront customer account.
While the subscription itself remains active and its next execution date continues to be calculated, the available subscription actions are no longer displayed. As a result, customers cannot react to a failed payment themselves, for example by pausing or cancelling the subscription.
The subscription can still be managed through the Administration, which means customers need to contact the merchant's support team to make these changes.
Current behavior:
When a subscription enters STATEPAYMENTFAILED, the customer cannot use the…1 vote
- Don't see your idea?