- or
No existing idea results
- ~ No ideas found ~
385 results found
-
Form field company name also for B2C shops
An additional field for entering a company name should be added to the registration form. There are often B2C customers who wish to have their order delivered to their work address. An optional form field for company names is therefore required.
1 voteGathering 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.
-
Improve checkout message performance
The AI-generated checkout message sometimes takes 10 seconds to generate if there are many products in the shopping cart.
Many customers close the page during this time. It would be better if the messages were generated in the background beforehand or if a faster AI model were used.
4 votes -
Automatically remind users who abandon the shopping cart
Automatic reminder for shopping basket cancellations. Optionally with an incentive such as a discount code. Remind users who abandon their shopping basket (including guests) and optionally bring them back to the shop.
17 votes -
Inheritable category and menu visibility in organizational units (B2B)
Currently, category and product visibility settings can only be explicitly configured per category within organizational units.
When a parent category is selected, the subcategories beneath it are not automatically included.
This leads to the following problems with extensive category structures (several hundred subcategories):
- very high manual maintenance effort
- increased susceptibility to errors
- poor maintainability when structural changes are made
- limited scalability in a B2B contextIn addition, the main menu must be controlled indirectly via individual assignments to the contained categories, as a blanket menu activation is not possible.
Target Image:
- Selecting a parent category should optionally include all subcategories automatically.
- Menu visibility should be configurable independently of individual assignments.
- Reduction of administrative effort for complex B2B structures.Specific Improvement Suggestions
A) Inheritable Category Visibility
Option 1: "Include Subcategories" CheckboxWhen selecting a category in the organizational unit:
☐ Automatically include subcategories
Behavior:
- Recursively activates all child categories.
- New subcategories are automatically included.
- Optionally overridable at the subcategory level.Technically feasible:
- Flag at the category assignment level
- Recursive query in the CategoryTreeLoader
- Lazy resolution in the Visibility ResolverB) Global Menu Sharing
New option in the organizational unit:☐ Show full main menu
Behavior:
- Menu structure is displayed
- Visibility of individual products remains adjustable
- Alternatively: Combination with category filter logicOptional:
- Visibility only structural (navigation visible, product access checked)Benefits
For Customers
- Massive time savings
- Significantly improved maintainability
- Scalability for large catalogs
- Fewer misconfigurationsFor Shopware
- Stronger B2B positioning
- Reduced support requests
- Less need for custom development
- Competitive advantage with enterprise customersCurrently, category and product visibility settings can only be explicitly configured per category within organizational units.
When a parent category is selected, the subcategories beneath it are not automatically included.
This leads to the following problems with extensive category structures (several hundred subcategories):
- very high manual maintenance effort
- increased susceptibility to errors
- poor maintainability when structural changes are made
- limited scalability in a B2B contextIn addition, the main menu must be controlled indirectly via individual assignments to the contained categories, as a blanket menu activation is not possible.
Target Image:
- Selecting a parent category…4 votes -
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…
1 voteGathering 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 pasting prices with comma as decimal separator
Title:
Allow pasting prices with comma as decimal separatorDescription:
Currently, Shopware 6 does not accept prices that are pasted with a comma as the decimal separator.For example:
12,95 → only 12 is inserted (the decimal part is ignored)
This is inconvenient for European merchants, because prices are often copied from:
Excel
ERP systems
Supplier price lists
Websiteswhere the comma is the standard decimal separator.
Expected behavior
When a user pastes a price such as:
12,95
1234,56Shopware should automatically convert it to the correct internal decimal format instead of discarding everything after the comma.
This would improve usability significantly and prevent incorrect prices from being entered.
Benefit
Better user experience
Fewer input errors
Better support for European number formats
Faster product maintenanceTitle:
Allow pasting prices with comma as decimal separatorDescription:
Currently, Shopware 6 does not accept prices that are pasted with a comma as the decimal separator.For example:
12,95 → only 12 is inserted (the decimal part is ignored)
This is inconvenient for European merchants, because prices are often copied from:
Excel
ERP systems
Supplier price lists
Websiteswhere the comma is the standard decimal separator.
Expected behavior
When a user pastes a price such as:
12,95
1234,56Shopware should automatically convert it to the correct internal decimal format instead of discarding everything after the comma.
This would improve…
1 voteGathering 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 for CMS elements to be hidden on category pages when product listing page is not the first page
When a category layout contains some text or images together with the product listing element, that text or element may be indexed by search engines multiple times for each page of the listing, leading to duplicate indexing and results.
It would be helpful if certain elements could be hidden once the customer or the indexing bot navigates through the listing pages, or a URL contains the ?p= parameter. This would prevent redundant indexing.
3 votes -
sorting by publication date should also be possible ascending and descending order
When sorting products by publication date, it should also be possible to choose between ascending and descending order. Now only descending is possible
Man sollte bei der Produktsortierung nach Erscheinungsdatum auch ab- oder aufsteigend auswählen können. Aktuell nur ist nur absteigend möglich
1 voteGathering 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.
-
Option to hide editing tools in the image editor
It would be great if there were a way to hide the editing tools in the image editor.
The advantage of this is that they would no longer take up a large portion of the screen.1 voteGathering 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 beinhalten1 voteGathering 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.
-
Incorrect plugin names and icons displayed for partner accounts
We have noticed that we see different plugin names and icons in a customer’s extension list than the customer does.
After checking, we found that the data shown to the customer is correct and matches the respective plugin definitions. When we log out of our partner account, ottscho@ottscho.de, the correct data is displayed again. As soon as we log back in, the incorrect data reappears.
It seems that plugin data is retrieved differently for partner accounts and is currently displayed incorrectly. Please investigate this issue. It is extremely inconvenient when a customer refers to a plugin that we cannot find because it is shown under a different name in our account.
In this case, the plugin is called “Gutscheine für Gratisartikel” for the customer, while it appears as “Kostenloser Artikel mit Gutschein im Warenkorb” for us. However, “Gutscheine für Gratisartikel” is the correct current name according to the composer.json file and the database.
The second plugin named “Gutscheine für Gratisartikel” also displays a different icon for us, even though the plugin was freshly installed.
Original Anfrage
Wir haben festgestellt, dass wir andere Plugin Bezeichnungen und Icons in der Erweiterungsliste eines Kunden sehen als er. Bei der Nachprüfung hat sich ergeben, dass die Daten welche der Kunde sieht die korrekten Daten aus den jeweiligen Plugin Definitionen sind. Bei ausloggen aus unserem Partner Account ottscho@ottscho.de wurden auch wieder die korrekten Daten angezeigt. Bei einloggen wieder die falschen. Scheinbar werden die Daten bei einem Partneraccount anders herangezogen, und zwar falsch. Bitte prüfen, das ist äußerst unschön, wenn der Kunde von einem Plugin spricht welches wir gar nicht finden, weil wir nach einem anderen Namen suchen.
In dem Fall war es das Plugin "Gutscheine für Gratisartikel" was bei uns "Kostenloser Artikel mit Gutschein im Warenkorb" heißt. Ersteres ist aber der korrekte aktuelle Name laut composer.json und Datenbank. Auch das zweite Plugin "Gutscheine für Gratisartikel" hat bei uns ein anderes Icon, obwohl das Plugin frisch installiert wurde
We have noticed that we see different plugin names and icons in a customer’s extension list than the customer does.
After checking, we found that the data shown to the customer is correct and matches the respective plugin definitions. When we log out of our partner account, ottscho@ottscho.de, the correct data is displayed again. As soon as we log back in, the incorrect data reappears.
It seems that plugin data is retrieved differently for partner accounts and is currently displayed incorrectly. Please investigate this issue. It is extremely inconvenient when a customer refers to a plugin that we cannot…
1 voteGathering 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.
-
Change configuration category layout / homepage configuration
Recurring support tickets indicate that the shop's homepage configuration is not centralized enough.
Firstly, the shop's homepage is determined by the category layout. Secondly, the homepage can also be set within the category itself (under the "General" tab -> "Homepage" option).
These numerous different configuration options conflict with each other and lead to unnecessary support tickets. The configuration should therefore be simplified.
5 votes -
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:…
4 votes -
Toggle for readonly custom-fields
It would be nice to have a toggle for custom fields to mark them readonly (at least in the UI).
We often have the case that custom field values are imported from other systems (like a PIM) and should not be modified through the Shopware Admin UI. But it's nontheless nice to see their values there.
So it would be a really nice option to be able to mark them as readonly.1 voteGathering 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 the display of search suggestions configurable in the backend
When searching for customers in the backend, the first name and surname are displayed first, which is not ideal for B2B customers. In this case, it would be better to display the company name.
We would therefore like an option that allows us to choose which piece of information is displayed first in the search suggestion. The screenshot illustrates the relevant section in the backend.
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.
-
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 -
Adjustment of Document File Names with Placeholders for Customer Data
Shopware does not support the use of placeholders for customer number, customer name, company name, and date in document file names. This makes efficient and precise management of generated files more challenging.
To optimize the categorization and archiving of documents, it would be highly beneficial to allow placeholders for the mentioned customer data in both the prefix and suffix of the file name. This would significantly simplify the handling of documents and improve the overall user experience of the software.
We kindly request that this functionality be integrated into a future version.
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…
4 votes -
Enable swiping of product images in the gallery
When a customer views a product page on a mobile device, it is possible to swipe through the different product images.
However, once the gallery (full screen) is opened, it is no longer possible to navigate through the images by swiping, and only the arrow keys can be used.
This behavior is not transparent and therefore not comprehensible to the customer, making it feel like an error.
4 votes -
Shopware Analytics - allow selection of common (and custom?) separators
Currently, we're using comma as a separator for Shopware Analytics exports. Turns out that this is not a one-size-fits-all solution because commas are not that unusual and can appear in product names as well.
OnPrem, this is a relatively simple customisation I imagine, but Shopware Analytics is also used in cloud shops, where this approach is not possible.
Hence, it would be nice if no individual customization is required at all and we offer some sort of setting or something in the Admin itself so shop owners can comfortably set their own separator which best fits their setup.
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?