- or
No existing idea results
- ~ No ideas found ~
343 results found
-
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 -
Central Management and Exclusion of Image Keywords in Shopware
Problem:
The Shopware Image Keyword Assistant generated irrelevant and misleading keywords for a product image. In this specific case, keywords such as “Kanalisation,” “Kanalschacht,” and “Loch” were detected or generated — likely based on a small detail within the image — and do not accurately represent the product. These terms are inappropriate and not acceptable from a merchant’s perspective.
Example of generated keywords:
“Loch, Abtropfen lassen, Kanalisation, Kanalschacht, Loch, Abtropfen lassen, Kanalisation, Kanalschacht, Bodenmatte, Gepäckmatte, Autoabdeckung, Kofferraummatte, Rutschfeste Matte, matte de, tappetino auto, sotto-pavimento?, antiscivolo, tappeto auto”
The terms “Kanalisation,” “Kanalschacht,” and “Loch” are clearly not relevant and do not meet expected quality standards.
Current Limitation:
At present, Shopware does not provide a way for merchants to centrally exclude or remove unwanted keywords. The only option is to manually edit keywords per media item in the media library. This becomes highly inefficient when the issue affects multiple assets (e.g., 50 images all containing the same incorrect keyword like “Kanalisation”).
Proposed Solution:
Introduce a centralized/global keyword management feature that allows merchants to:
- Define a list of excluded keywords (blacklist)
- Automatically prevent these keywords from being generated in the future
- Remove these keywords across all existing media assets in bulk
- Optionally trigger an update of affected metadata (e.g., alt texts) when keywords are removed
This would significantly improve efficiency, ensure higher data quality, and give merchants better control over automatically generated content.
Problem:
The Shopware Image Keyword Assistant generated irrelevant and misleading keywords for a product image. In this specific case, keywords such as “Kanalisation,” “Kanalschacht,” and “Loch” were detected or generated — likely based on a small detail within the image — and do not accurately represent the product. These terms are inappropriate and not acceptable from a merchant’s perspective.
Example of generated keywords:
“Loch, Abtropfen lassen, Kanalisation, Kanalschacht, Loch, Abtropfen lassen, Kanalisation, Kanalschacht, Bodenmatte, Gepäckmatte, Autoabdeckung, Kofferraummatte, Rutschfeste Matte, matte de, tappetino auto, sotto-pavimento?, antiscivolo, tappeto auto”
The terms “Kanalisation,” “Kanalschacht,” and “Loch” are clearly not relevant and do not…
3 votes -
UX improvement: Switch directly from the backend product to the frontend view.
When you do changes in backoffice of a product there should be a button from wich you can directly open a new tab with the product in frontend. So you can easily and fast check your changes
6 votes -
B2B Components: Assign existing account to company account
Shop owners occasionally report that the unusual process of registering as a B2B employee leads to them signing up normally through the frontend which creates a bit of a mess.
It would be helpful if we provided the functionality to assign normal customers as employees to a B2B enabled company account as this would save effort for everyone involved.
Taking this idea further and to avoid unnecessary manual action for shop owners, we could implement this feature for the B2B account itself so THEY can invite existing (already registered) accounts to their company and integrate them into the B2B structure. Of course, for privacy reasons, they should not see if the mail already exists when inviting.
Shop owners occasionally report that the unusual process of registering as a B2B employee leads to them signing up normally through the frontend which creates a bit of a mess.
It would be helpful if we provided the functionality to assign normal customers as employees to a B2B enabled company account as this would save effort for everyone involved.
Taking this idea further and to avoid unnecessary manual action for shop owners, we could implement this feature for the B2B account itself so THEY can invite existing (already registered) accounts to their company and integrate them into the B2B structure.…
8 votes -
Shopware Publishe - show that Drafts exist in Detailpage
when opening a cms page, I want see, that there are drafts. additionally I want be able to access them easily like I can do in listing.
1 vote -
Automatic Country Restrictions Based on Manufacturer
Many merchants need to restrict the sale of specific brands or manufacturers in certain countries due to contractual, legal, or distribution agreements.
Currently, country restrictions must be assigned manually on a product-by-product basis. This becomes error-prone and difficult to maintain, especially for large product catalogs and when new products are added regularly.
A valuable enhancement would be the ability to define country restrictions at the manufacturer level and automatically apply them to all associated products.
Key benefits include:
- Automatically inheriting country restrictions for newly created products of a manufacturer
- Reducing manual maintenance and the risk of human error
- Ensuring compliance with brand-specific distribution agreements
- Improving scalability for merchants managing large product catalogs
This would provide a more efficient and reliable way to manage international sales restrictions while significantly reducing administrative effort.
Many merchants need to restrict the sale of specific brands or manufacturers in certain countries due to contractual, legal, or distribution agreements.
Currently, country restrictions must be assigned manually on a product-by-product basis. This becomes error-prone and difficult to maintain, especially for large product catalogs and when new products are added regularly.
A valuable enhancement would be the ability to define country restrictions at the manufacturer level and automatically apply them to all associated products.
Key benefits include:
- Automatically inheriting country restrictions for newly created products of a manufacturer
- Reducing manual maintenance and the risk of human error
- Ensuring compliance…
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.
-
Packaging Unit Recommendation for B2B Products
Many B2B merchants sell products that are physically supplied in packaging units (e.g., 20 pieces per carton) while still allowing customers to order any quantity on a per-piece basis.
Currently, Shopware provides features such as tier pricing, minimum order quantities, and quantity steps. However, there is no native way to define a packaging unit for a product and use it as a recommendation rather than a restriction.
A valuable addition would be the ability to:
- Define a packaging unit size per product (e.g., 20 pieces)
- Display a recommendation in the buy box suggesting the next full packaging multiple based on the selected quantity
- Optionally provide convenience actions such as “+1 packaging unit”
- Encourage ordering full packaging units without enforcing quantity restrictions
The underlying product and inventory logic should remain unchanged:
- No product variants are required
- No separate products for packaging units are required
- Inventory should continue to be managed on the regular product level
- The cart should continue to process only the actual ordered piece quantity
This would help B2B merchants optimize logistics and packaging efficiency while maintaining maximum flexibility for customers.
Many B2B merchants sell products that are physically supplied in packaging units (e.g., 20 pieces per carton) while still allowing customers to order any quantity on a per-piece basis.
Currently, Shopware provides features such as tier pricing, minimum order quantities, and quantity steps. However, there is no native way to define a packaging unit for a product and use it as a recommendation rather than a restriction.
A valuable addition would be the ability to:
- Define a packaging unit size per product (e.g., 20 pieces)
- Display a recommendation in the buy box suggesting the next full packaging multiple based on…
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.
- Don't see your idea?