- or
No existing idea results
- ~ No ideas found ~
1545 results found
-
The scrollbar in the category tree needs to be more user-friendly.
If the shop has a complex category structure, navigating the categories in the admin area can quickly become very confusing. It often requires clicking and using the scroll bar, which is located at the very end of the category tree. This means users have to repeatedly scroll to the end of the tree, which is very time-consuming and needs to be simplified.
3 votes -
Test
Test
1 vote -
Landingpages Canonical-Link setzen
Landingpages sollten auch einen (wählbaren) Canonical-Link erhalten. So wie Kategorieseiten und Produktseiten.
Landing pages should also have a selectable canonical link, just like category pages and product pages.
1 vote -
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…
1 vote -
payment method per customer
Default payment method should be available per customer so that we can use this information for
- customer account
- Reports
- order confirmation2 votes -
Optional inclusion of “free shipping” products in cart value for threshold rules
Use case
We configure shipping so that standard shipping is free from a minimum order value (e.g. 50 €), using price-based shipping costs on the shipping method.
Current behaviour
Products marked “free shipping” are excluded from the value used for all shipping price calculations (via getWithoutDeliveryFree() in DeliveryCalculator::matches()). That means:
If the cart mixes free-shipping and regular products, only the non–free-shipping lines count toward the threshold.
Example: total cart 60 €, but only 40 € from non–free-shipping lines → the customer is below the 50 € free-shipping threshold and pays shipping, even though the visible cart total is above 50 €.Expected / desired behaviour
For price-based rules (minimum order value / free shipping from X €), we need the full cart value (or a configurable choice) to determine the tier, not only the sum excluding free-shipping products.
Products marked “free shipping” should still ship without their own fee when they are the only items, but when combined with other products, they should count toward the threshold so behaviour matches merchant and customer expectations.Suggestion
Please consider one of:
A configuration option on the shipping method or globally: “include free-shipping products in cart value for price-based shipping rules”, oran extension point (e.g. protected method, strategy, or event) so projects can implement this without forking DeliveryCalculator.
Use case
We configure shipping so that standard shipping is free from a minimum order value (e.g. 50 €), using price-based shipping costs on the shipping method.
Current behaviour
Products marked “free shipping” are excluded from the value used for all shipping price calculations (via getWithoutDeliveryFree() in DeliveryCalculator::matches()). That means:
If the cart mixes free-shipping and regular products, only the non–free-shipping lines count toward the threshold.
Example: total cart 60 €, but only 40 € from non–free-shipping lines → the customer is below the 50 € free-shipping threshold and pays shipping, even though the visible cart total is above 50…2 votes -
Product visibility: Only when customer has specific prices
There have been a few requests by B2B shop owners where the challenge is as follows:
Products should only be visible IF the observer/customer has specific prices for them. Basically, this means that no products are visible UNLESS the customer has a set price for it.
From the perspective of a former B2B procurement manager: This is a relatively common thing to see. I purchased tools for the manufacturing personnel, for example. I'd contact the potential suppliers once a year, we'd sit down, talk projected order volumes, figures and conditions.
After that was all negotiated, I'd get a price list for the various categories with individual prices, bonuses, conditions and so forth and the supplier would set it up on their end so that I could place orders online (if I wanted to) in their shop. Strictly speaking, I'd find all/most of the other items in their shop as well, but I would have preferred if I didn't - so my line of thinking aligns with the requests we got about this in Support, because I already negotiated every item which was relevant to the company I represented ahead of time - I don't need and don't want to see things I had no interest in and likely have no price list for either.
So - two birds with one stone:
1) The observer sees all the items they have a specific price for
2) The observer does not need to filter what is/was relevant to themThe implementation screams B2B Components. But I think the implementation is potentially simpler if done via Dynamic Access:
If we had a condition which checks whether or not the observer has custom prices of any sort (be it via customer group - this should be the first condition in my mind - extended prices OR customer specific prices, we'd have all the rest covered already.
There have been a few requests by B2B shop owners where the challenge is as follows:
Products should only be visible IF the observer/customer has specific prices for them. Basically, this means that no products are visible UNLESS the customer has a set price for it.
From the perspective of a former B2B procurement manager: This is a relatively common thing to see. I purchased tools for the manufacturing personnel, for example. I'd contact the potential suppliers once a year, we'd sit down, talk projected order volumes, figures and conditions.
After that was all negotiated, I'd get a price list…
3 votes -
Increase value for "items per page" on customer > addresses (make it configurable)
Increase value for "items per page" on customer > addresses:
- Add values "250" and "500"
- Make default value for "items per Page" configurable so it can be set to <>25
2 votes -
Low Visibility of Required Confirmation Checkbox in Checkout Process
Hello,
We are currently using the “Outdoor” theme. Our products offer several customizable options, and before customers can proceed to checkout, they must confirm that their selected product configuration is correct by checking the confirmation box.
However, the checkbox is currently barely visible, which may cause customers to overlook it. As a result, some customers might abandon the checkout process because they do not notice that confirmation is required before proceeding to payment.
We would appreciate it if the visibility of the checkbox could be improved to make the checkout process clearer and more user-friendly.
Thank you !
0 votesHi Michael,
thanks for reaching out and for the detailed feedback!
We advice you to reach out to the "Outdoor" theme vendor (Themeware https://store.shopware.com/en/tcinn85265076285m/themeware-outdoor-pro-sales-increasing-and-customizable.html ) for support in this case.
Kind regards,
Sandor
-
Payment method change after order receipt with new payment method
Currently, when changing the payment method of an existing order (/account/order/edit-payment), the rule engine is not re-executed.
Instead, Shopware continues to use the payment methods that were available at the time the original order was placed.
This results in the following scenarios not being handled correctly:
- Payment methods become valid for the customer retroactively (e.g., based on tags, customer groups, or rules) → but do not appear in the selection.
- Rules change retroactively (e.g., "Always valid" is added) → no update occurs.
- Changes to customer data, addresses, or order items are not reflected.This means that customers cannot select an updated payment method, even if they meet the requirements after placing the order.
The payment method cannot currently be changed in the admin panel either.
When changing the payment method for an existing order, the payment methods should be determined dynamically based on current data and rules – not based on historical data.
The customer should therefore always see all currently valid payment methods.
Currently, when changing the payment method of an existing order (/account/order/edit-payment), the rule engine is not re-executed.
Instead, Shopware continues to use the payment methods that were available at the time the original order was placed.
This results in the following scenarios not being handled correctly:
- Payment methods become valid for the customer retroactively (e.g., based on tags, customer groups, or rules) → but do not appear in the selection.
- Rules change retroactively (e.g., "Always valid" is added) → no update occurs.
- Changes to customer data, addresses, or order items are not reflected.This means that customers…
5 votes -
Support immutable promotion versions behind stable promotion codes
Currently, Shopware locks certain promotion discount settings after a promotion has been used in an order. For example, the discount amount can no longer be changed once the promotion was applied at least once.
From a data integrity perspective, this is understandable: changing the discount definition after it has already been used could affect order recalculation, order editing, tax distribution, or historical consistency.
However, from a merchant perspective this creates a practical limitation. A commonly used promotion code such as WELCOME cannot easily be reused with a changed discount configuration. The merchant either has to create a new visible code, or the existing promotion becomes effectively frozen.Suggested improvement
Shopware could support immutable promotion versions behind a stable public promotion code.
The customer-facing code would remain unchanged, for example:Internally, Shopware would resolve this code to a concrete promotion version.
Example:
Code: WELCOME
Version 1:internal promotion/version ID: abc123
valid from: 2026-01-01
valid until: 2026-03-31
discount: 10%
used for existing orders / historical order edits only
Version 2:
internal promotion/version ID: def456
valid from: 2026-04-01
valid until: open
discount: 15%
used for new carts and new orders
Expected behaviorFor new carts and new orders, the entered code WELCOME should resolve to the currently active promotion version.
For existing orders, order edits, recalculations, or similar historical operations, Shopware should continue to use the originally applied promotion version.
In other words:
New checkout:
WELCOME → latest active promotion version
Existing order edit:
use the promotion version that was originally applied to this orderThe old version should not remain generally usable just because it was valid in the past. It should only be used where there is already a concrete historical reference, for example on an existing order that originally used that version.
Why this would help
This would preserve historical calculation integrity while allowing merchants to keep stable, recognizable promotion codes.
It would also avoid forcing merchants to create new customer-facing codes every time they want to adjust a promotion. Common codes such as WELCOME, SUMMER, or BLACKWEEK could stay the same while their internal discount definition is versioned safely.
Possible implementation approach
Instead of modifying a promotion discount definition after first usage, Shopware could create a new immutable promotion version.
The admin UI could offer an action such as:
Create new version of this promotion
This new version would inherit the existing configuration, allow changes to the discount settings, and become the active version for future carts.
Existing orders would continue to reference the previous version.
Benefits
Keeps historical order data stable
Avoids recalculation inconsistencies
Allows merchants to reuse established promotion codes
Improves usability in the Administration
Provides a cleaner alternative to permanently locked discount fields
Makes promotion changes explicit and traceable
Additional contextThis is not meant as a request to allow direct editing of already-used discount definitions. The goal is to keep those definitions immutable, but introduce a versioning layer so that the same public promotion code can safely point to a newer internal promotion version for future orders.
Currently, Shopware locks certain promotion discount settings after a promotion has been used in an order. For example, the discount amount can no longer be changed once the promotion was applied at least once.
From a data integrity perspective, this is understandable: changing the discount definition after it has already been used could affect order recalculation, order editing, tax distribution, or historical consistency.
However, from a merchant perspective this creates a practical limitation. A commonly used promotion code such as WELCOME cannot easily be reused with a changed discount configuration. The merchant either has to create a new visible code,…1 vote -
Warenkorb Spalte "Produktnummer" auch für Angebote
Im Backend besteht derzeit im Warenkorb von Angeboten keine Möglichkeit, die Spalte „Produktnummer“ einzublenden, um die Artikelnummern der hinzugefügten Produkte direkt sehen zu können.
Da diese Funktion bei Aufträgen bereits verfügbar ist, wäre es sinnvoll und hilfreich, die Anzeige der Produktnummer auch für Angebote zu ermöglichen.
___EN below_______
Shopping cart column "Product number" also for offers: Currently, in the backend, there is no option to display the "Product number" column in the shopping cart for offers, so that the article numbers of the added products can be viewed directly. Since this function is already available for orders, it would be useful and helpful to enable the display of the product number for offers as well.
Im Backend besteht derzeit im Warenkorb von Angeboten keine Möglichkeit, die Spalte „Produktnummer“ einzublenden, um die Artikelnummern der hinzugefügten Produkte direkt sehen zu können.
Da diese Funktion bei Aufträgen bereits verfügbar ist, wäre es sinnvoll und hilfreich, die Anzeige der Produktnummer auch für Angebote zu ermöglichen.
___EN below_______
Shopping cart column "Product number" also for offers: Currently, in the backend, there is no option to display the "Product number" column in the shopping cart for offers, so that the article numbers of the added products can be viewed directly. Since this function is already available for orders, it…
1 vote -
B2B Components: add CSV bulk import of Employees and Addresses
Some customers may receive the request from business partners to create a lot of employee account with different addresses (see for example support case #SWAG-322222).
Currently each employee and address would need to be added by hand or via the API. Bulk importing as a CSV would make this a lot easier.
3 votes -
AI: Productstreams / Crossselling
Little has happened since the introduction of AI.
The use of AI to generate customer-specific product streams for cross-selling would be indispensable and a major step forward. For example, based on order history. This is very important for the customer.
Cross-selling is currently very rigid. AI could be used to analyze the customer's order and then make specific suggestions. This would be a huge step and benefit for customers and a game changer.
15 votes -
Add more granular permissions for PayPal
Currently, every admin user with the permission to edit an order (order.editor) can issue refunds of PayPal payments. It would be very helpful to add more granular permissions so that employees can modify orders but cannot issue refunds.
4 votes -
Quick check for plugin and dependency updates compatible with current Shopware version
Right now, there’s no quick way to see which plugin or dependency updates are actually compatible with the installed Shopware version.
composer outdated shows all new versions, ignoring compatibility.
The Admin popup just says “updates available” without details.
It would be very helpful to have a CLI command and/or an Admin view that lists only installable updates based on the current Shopware version.
7 votes -
Extended Product Visibility Control - Separate Search Settings
Enhance visibility control options for products in product listing and search listing.
Per product visibility setting, the following options are currently available:
Visible (All)
Hide in product listings
Hide in product listings and searchWith the current logic, it is only possible to:
Hide a product from listings, or
Hide it from both listings and search.However, it is not possible to keep a product visible in listings (e.g., categories, sliders, cross-sellings) while hiding it only from search results.
Requested Enhancement
Introduce an additional visibility option:
Visible in listings but hidden in search
This would allow merchants to control product discoverability more precisely without removing products from structured browsing contexts. Greater flexibility for B2B and enterprise use cases.
Enhance visibility control options for products in product listing and search listing.
Per product visibility setting, the following options are currently available:
Visible (All)
Hide in product listings
Hide in product listings and searchWith the current logic, it is only possible to:
Hide a product from listings, or
Hide it from both listings and search.However, it is not possible to keep a product visible in listings (e.g., categories, sliders, cross-sellings) while hiding it only from search results.
Requested Enhancement
Introduce an additional visibility option:
Visible in listings but hidden in search
This would allow merchants to control product…
2 votes -
Feedback regarding voucher/promotion response in the shopping cart
Topic: Missing User Feedback for Unactivated Coupon Promotions
Description:
When a customer enters a coupon code linked to a promotion during checkout, it is technically validated.If the promotion cannot be activated due to the current contents of the shopping cart (e.g., due to product category or discount restrictions), the customer receives no feedback on the front end.
From the customer's perspective, nothing happens – even though the code would be valid.
Current Behavior (Default):
- Coupon is checked in the background.
- No error message or information is displayed if conditions are not met.
- The customer does not know whether the code is invalid or if there are simply no matching items in the shopping cart at the moment.Expected Behavior / Improvement Suggestion:
- Display of feedback such as:
"The coupon has been accepted, but there are currently no matching items in the shopping cart."
- Alternatively: A generic message stating that the coupon will be activated as soon as matching items are added to the shopping cart.Rationale:
- Increases transparency and customer trust.
- Avoids frustration caused by seemingly "non-functional" coupons.
- Improves user experience without impacting existing promotion logic.Suggested implementation:
- Add an informational message to the frontend (e.g., in the sw-promotion-code-form or via AddCodeError/AddCodeSuccess handling).
- Alternatively: A backend event hook that checks promotions and provides a flag or message object.Topic: Missing User Feedback for Unactivated Coupon Promotions
Description:
When a customer enters a coupon code linked to a promotion during checkout, it is technically validated.If the promotion cannot be activated due to the current contents of the shopping cart (e.g., due to product category or discount restrictions), the customer receives no feedback on the front end.
From the customer's perspective, nothing happens – even though the code would be valid.
Current Behavior (Default):
- Coupon is checked in the background.
- No error message or information is displayed if conditions are not met.
- The customer does not…5 votes -
B2B Components: Include divergent mail addresses in search results
Shop owners sometimes report having difficulties finding B2B root accounts when provided with little more than a mail address of an employee in case it is not conforming to the companies' mail structure.
For example:
Our B2B root account is company@example.com.
Our employee's mail address is employee@shopware.com.Since the mail addresses don't match, when searching for employee@shopware.com, we will find no results for customers. This is sometimes the case where entire departments have separate mail addresses like a purchase department.
So the request is to have an option to index employee mail addresses and associate them with the B2B account for search results.
Shop owners sometimes report having difficulties finding B2B root accounts when provided with little more than a mail address of an employee in case it is not conforming to the companies' mail structure.
For example:
Our B2B root account is company@example.com.
Our employee's mail address is employee@shopware.com.Since the mail addresses don't match, when searching for employee@shopware.com, we will find no results for customers. This is sometimes the case where entire departments have separate mail addresses like a purchase department.
So the request is to have an option to index employee mail addresses and associate them with…
3 votes -
Enable Variant Changes Directly in the Shopping Basket and Checkout
Currently, when customers want to change a variant of a product already added to the shopping basket — for example, choosing a different size or color — they are required to leave the basket or checkout and navigate back to the product detail page. This process interrupts the purchasing flow and increases the likelihood of order cancellations or customer frustration.
With this enhancement, customers should be able to easily modify product variants directly from the basket or checkout interface.
Functional Proposal:
Add a variant selector for each product line item in the shopping basket and checkout.
When a customer changes a variant, the system automatically updates the line item’s price, stock information, and product image accordingly.
Currently, when customers want to change a variant of a product already added to the shopping basket — for example, choosing a different size or color — they are required to leave the basket or checkout and navigate back to the product detail page. This process interrupts the purchasing flow and increases the likelihood of order cancellations or customer frustration.
With this enhancement, customers should be able to easily modify product variants directly from the basket or checkout interface.
Functional Proposal:
Add a variant selector for each product line item in the shopping basket and checkout.
When a customer changes…
5 votes
- Don't see your idea?