- or
354 results found
-
Enhanced in-app purchase API for usage-based models
We want to develop extensions that are billed entirely via IAP (comment from Shopware: IAP stands for In App Purchases) – without our own subscription logic or external billing. Typical use cases are usage-based features such as quotas (e.g., search volume per month), limits, or activations with periodic renewal.
Currently, Shopware.InAppPurchase.isActive(‘MyExtensionName’, ‘my-iap-identifier’) only returns a Boolean (purchased: true/false).
However, for usage-based models, we lack the specific billing period, e.g., to reliably reset quotas when transitioning to the new period.Our request/feature request:
In addition to isActive(), minimal contract information would be helpful, e.g.:
- Purchase or start date of the current billing period
- Billing interval (e.g., monthly, annually)
- Flag indicating whether it is a wildcard/stage environmentThis would allow usage-based features (such as search volume, API quotas, free requests, etc.) to be implemented correctly, transparently, and fairly— without having to implement a parallel subscription or billing solution alongside Shopware IAPs.
We want to develop extensions that are billed entirely via IAP (comment from Shopware: IAP stands for In App Purchases) – without our own subscription logic or external billing. Typical use cases are usage-based features such as quotas (e.g., search volume per month), limits, or activations with periodic renewal.
Currently, Shopware.InAppPurchase.isActive(‘MyExtensionName’, ‘my-iap-identifier’) only returns a Boolean (purchased: true/false).
However, for usage-based models, we lack the specific billing period, e.g., to reliably reset quotas when transitioning to the new period.Our request/feature request:
In addition to isActive(), minimal contract information would be helpful, e.g.:
- Purchase or start date of the…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.
-
Use Flow Builder for automatic refunds
If an order's status is changed to 'cashback', the Flow Builder should automatically trigger a PayPal refund for that order. This reduces the need for manual work and eases the burden on customer support.
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.
-
Create Quote-Documents before sending the Quote
Currently, in the quote module, generating quote documents is only technically possible when the quote is sent. This means that employees cannot review the details and final layout of the documents in advance or coordinate with colleagues. Especially in complex B2B processes, where quality assurance and coordination are essential, this causes unnecessary sources of error and additional effort.
Specific Improvement Proposal:
The function for generating quote documents (e.g., PDF) should be decoupled from the sending process.
It should be possible at any time—at the latest after saving the quote as a “draft”—to create, download, and review the final quote document before the quote is actually sent.
Optionally, a release workflow can be integrated, allowing, for example, the sales or back-office teams to approve or comment on the documents before they are sent to the customer.Added Value and Benefits:
Checkability: Employees can internally review quotes in advance and prevent errors in content or layout.
Transparency: The final document is visible for parallel approval processes before it is sent.
More Efficient Processes: Reduces returns, customer queries, and deletions due to faulty quotes, saving time in daily operations.
Currently, in the quote module, generating quote documents is only technically possible when the quote is sent. This means that employees cannot review the details and final layout of the documents in advance or coordinate with colleagues. Especially in complex B2B processes, where quality assurance and coordination are essential, this causes unnecessary sources of error and additional effort.
Specific Improvement Proposal:
The function for generating quote documents (e.g., PDF) should be decoupled from the sending process.
It should be possible at any time—at the latest after saving the quote as a “draft”—to create, download, and review the final quote document…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 first- and last name optional for company accounts
First- and last name should be optional if setting up a new customer entry through the administration or by using the register form IF it is a company account.
32 votes -
Extended debugging e-mail/template dispatch
Many customers customize the email templates for their shop. It often happens that certain e-mail templates are no longer sent because, for example, variables are incorrect.
Troubleshooting the cause is then very difficult and time-consuming because:
- There are no errors in the log with indications of the cause.
- The e-mail test function still works with the e-mail template because variables are ignored.
As a result, the e-mail template and the variables have to be checked with a great deal of effort and there are a lot of support tickets for this, as customers quickly reach their limits.
In order to help customers and reduce the number of support tickets, it would therefore be useful to have extended debugging for sending emails. It should be possible to recognise from which line the e-mail dispatch fails.
This would allow the customer or the support team to name and recognise the line directly and, if necessary, find the error within seconds. This leads to less time for troubleshooting and frustration for customers.
Many customers customize the email templates for their shop. It often happens that certain e-mail templates are no longer sent because, for example, variables are incorrect.
Troubleshooting the cause is then very difficult and time-consuming because:
- There are no errors in the log with indications of the cause.
- The e-mail test function still works with the e-mail template because variables are ignored.
As a result, the e-mail template and the variables have to be checked with a great deal of effort and there are a lot of support tickets for this, as customers quickly reach their limits.
In order to…
24 votes -
Add separate configuration options to distinguish between “allow payment method change after checkout” and “allow retry of an aborted paymen
To better support payment workflows, especially with PayPal, it would be highly beneficial to separate two currently combined behaviors:
At the moment, the option “Allow payment method change after checkout” also controls whether customers can retry a previously aborted payment (e.g., PayPal popup was closed by mistake).
However, enabling this option on PayPal unintentionally allows customers to change from any other payment method (e.g., Prepayment/Bank Transfer) to PayPal after the order is placed. This causes serious issues in ERP/WMS integrations where such changes are not allowed.Proposed improvement:
Introduce two independent configuration options per payment method:“Allow switching to this payment method after checkout”
“Allow retrying an aborted payment for this payment method”
Benefits:
Customers can still complete PayPal payments if they accidentally aborted the payment window.
Merchants can prevent unwanted payment method changes (e.g., Prepayment → PayPal) that break ERP workflows.
Provides clearer, more predictable, and more granular control over payment behavior.
This enhancement would significantly improve flexibility and avoid unintended side effects in multi-payment setups.
To better support payment workflows, especially with PayPal, it would be highly beneficial to separate two currently combined behaviors:
At the moment, the option “Allow payment method change after checkout” also controls whether customers can retry a previously aborted payment (e.g., PayPal popup was closed by mistake).
However, enabling this option on PayPal unintentionally allows customers to change from any other payment method (e.g., Prepayment/Bank Transfer) to PayPal after the order is placed. This causes serious issues in ERP/WMS integrations where such changes are not allowed.Proposed improvement:
Introduce two independent configuration options per payment method:“Allow switching to this…
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.
-
Add user friendliness to new language handling
Since Shopware 6.7.3.0 the language pack displays a warning, that it's recommended not to use it and that it will not work with 6.8.x anymore. Unfortunately the deinstallation of the language pack removes all translations included there (test with 6.7.4.0, with selection "Remove all data it even throws an exception).
The dev docs recommend this way https://developer.shopware.com/docs/resources/references/upgrades/core/translation/language-pack-migration.html. But not every customer is feeling comfortable being forced to use the command line. It is intended to activate / deactivate a language via the language itself. So why don't you add an install / uninstall routine in settings > language to process bin/console translation:install --locales it-IT linked to the switch's setting? Perhaps in addition whether the snippets should be installed / uninstalled?Since Shopware 6.7.3.0 the language pack displays a warning, that it's recommended not to use it and that it will not work with 6.8.x anymore. Unfortunately the deinstallation of the language pack removes all translations included there (test with 6.7.4.0, with selection "Remove all data it even throws an exception).
The dev docs recommend this way https://developer.shopware.com/docs/resources/references/upgrades/core/translation/language-pack-migration.html. But not every customer is feeling comfortable being forced to use the command line. It is intended to activate / deactivate a language via the language itself. So why don't you add an install / uninstall routine in settings > language to…1 vote -
Optionally, the net prices should remain the same, even if there are other taxes in other countries.
Currently, the net price changes if you offer products in other countries with different taxes. The gross price remains the same.
There should be an option to decide for yourself whether the net price remains the same with a variable gross price, or whether the gross price remains the same with a variable net price.
91 votes -
Improve Safety and Flexibility for Promotion Code Configuration
Context
In the current version of Shopware 6, when creating a new promotion, the field “Promotion code type” is automatically set to “No promotion code required”.
This UX choice was made intentionally to simplify creation of general cart-level discounts, which are the most common use case.However, this default selection can lead to unintended activation of promotions when a user forgets to change the option to “Fixed” or “Individual promotion code.”
In such cases, discounts may be applied to all customers instead of a limited target group, which can cause serious financial and operational issues.Problem
Users may overlook that a promotion is configured without a code, because “No code required” is preselected
This can unintentionally trigger discounts for all customers
Currently, there is no system-level control or "safeguard" to prevent this
Proposed Solutions
We suggest adding configurability or safety mechanisms for the “Promotion code type” field to reduce user errors and increase administrative control.
There are three possible options that could be implemented independently or in combination:
Require explicit selection (no default preselection)
Remove the preselected value “No promotion code required.”System-wide default configuration
Add a configuration setting in system or admin preferences allowing administrators to define the default for new promotionsOptional warning before activation
Display a confirmation or warning when activating a promotion that has no promotion code set.
Example message:
“This promotion will be applied to all customers because no promotion code is required. Are you sure you want to activate it?”
Expected Benefits
Prevents accidental large-scale discount activations
Improves administrative control and safety
Reduces support incidents and potential financial losses
Aligns the promotion workflow with enterprise-level requirements
Context
In the current version of Shopware 6, when creating a new promotion, the field “Promotion code type” is automatically set to “No promotion code required”.
This UX choice was made intentionally to simplify creation of general cart-level discounts, which are the most common use case.However, this default selection can lead to unintended activation of promotions when a user forgets to change the option to “Fixed” or “Individual promotion code.”
In such cases, discounts may be applied to all customers instead of a limited target group, which can cause serious financial and operational issues.Problem
Users may overlook that…
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.
-
Backend: Product Filtering and Customization - Filter Value
The product filters section needs more customization and can be optimized.
Here is an example of the main shortcomings:
1 - Allow the addition of custom fields and properties.
2 - Allow the use of operators such as: "Like," "=", "And," "Or," "Starts with," etc.
3 - Allow filtering by entering multiple values in a search field.8 votes -
Bitte in der Anzahl der Produktverkäufe die Produktnummer mit anzeigen (Artikelnummer)
Es wäre sehr hilfreich, die Produktnummer in der Liste der Produktverkäufe sehen zu können.
Bitte blenden Sie die Produktnummer im Analytics Plugin mit ein. (Artikelnummer)Vielen Dank
12 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.
-
"not specified" salutation handling
This is handled rather inconsistently in Shopware. In some but not all places, if you leave out the salutation, Shopware searches the database for the "not_specified" entry that comes with the installation and inserts it if found. If also sometimes inserts it just for display in the Administration if the real salutation reference is null, so you wouldn't even know the real value without looking directly into the database, but again, not always.
Crucially, that "not_specified" entry can be changed and deleted at will, so there's no guaranteed meaning behind it.
Also, sometimes like in the contact form the salutation is randomly required. You can delete it for addresses and the database has a default value of null, but then there is a non-configurable validator that won't let you through the checkout process if no salutation is given. And again, "given" can just mean that you set the "not_specified" salutation, which can have any meaning you assign to it.
This is an intransparent mess and should be changed. The very legality of requiring a salutation is now even in question. Just allow null values for all salutations in the application, it's already allowed in the DB structure, stop enforcing it in random places without a way to turn it off, and make the display name of a "null" salutation translatable via config.
This is handled rather inconsistently in Shopware. In some but not all places, if you leave out the salutation, Shopware searches the database for the "not_specified" entry that comes with the installation and inserts it if found. If also sometimes inserts it just for display in the Administration if the real salutation reference is null, so you wouldn't even know the real value without looking directly into the database, but again, not always.
Crucially, that "not_specified" entry can be changed and deleted at will, so there's no guaranteed meaning behind it.
Also, sometimes like in the contact form the…
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.
-
Display order details clearly on one page instead of using tabs (similar to Shopware 6.4)
The details of an order should be clearly displayed on one page. Unfortunately, the details are currently spread across several tabs.
Clicking around, loading the various tabs and changing details takes longer than if everything could be done on one page.
Shopware 6.4 is clearer than Shopware 6.7.
Please change this.
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.
-
Add selection field in user profile settings for measurement preferences
When a user changes the unit in a product, this change is applied at the user level and stored in the database in the
user_configtable with the keymeasurement.preferenceUnit. If there is already a dedicated entry for this in the database, it would be nice if the selection could be changed directly in the user profile.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.
-
organisation unit should be defined in new emplyee
As the organisation units are available with version 6.7, it should be possible to map the unit for new employees.
Currently only the role can be set.
Employees can only be mapped within the organisation unit when the employee is active (invitation link is clicked within the 2 hours reaction time).
If organisation units are active in the customer and units are defined, it should be possible to map it within the employee mask. For existing and new employees.
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.
-
Add empty alt tags to untagged thumbnails in image galleries
Untagged images in the gallery get an empty alt tag when not tagged, which is a good default behaviour. The thumbnails in the gallery also need this. Currently, untagged images don't get any alt tag at all. This is an accessibility problem!
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.
-
CAPTCHAs: Different keys per sales channel
You can currently only store one key pair per CAPTCHA in the Basic information. If you change the sales channel in the
Basic information and enter another key, the previous one will be overwritten.9 votes -
Image keyword assistant for logos
The image keyword assistant should be able to recognize well-known logos, not just objects.
For example, when you upload the Shopware logo, only “Logo” appears as the alt text. When you upload Facebook logo, “Symbol, sign, cross” appears, which isn't really accurate, and nothing appears at all for Instagram logo.
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.
-
delivery time as variable for email templates
enable display of delivery time per item within the e-mail template via variable
9 votes -
Better Utilization of Screen Space (UX)
The product variant management page in Shopware 6 wastes significant screen space on larger monitors, forcing unnecessary horizontal and vertical scrolling. The table is too narrow and doesn’t adapt to the available screen size, making key information harder to access.
Proposed Solution:
- Dynamically resize the table to fill the available screen space.
- Add options for compact view and column customization.
- Enable full-screen mode for data-intensive pages. These changes will enhance usability, save time, and improve the user experience.
Problem Description:
The current user interface of the Shopware 6 product variant management page does not efficiently utilize the available screen space ("real estate") on larger monitors. As shown in the provided screenshot, key issues include:
Wasted Horizontal Space: Despite having significant unused space on the left and right margins, the main table displaying product variants is confined to a narrow section of the screen. This results in truncated or hidden information that requires unnecessary scrolling, especially horizontally.
Limited Vertical Display: Similarly, the vertical space is underutilized. Only a small number of variants are visible at one time, forcing users to scroll repeatedly to view or edit the entire list.
Horizontal Scrolling for Key Information: Important columns, such as media previews and additional details, require horizontal scrolling to access. This disrupts the workflow, especially when reviewing large datasets or making bulk edits.
Suggested Solution:
Dynamic Table Resizing:
The width of the table should dynamically adjust based on the screen resolution and browser window size. Allow the table to expand horizontally to fill the available space, minimizing the need for scrolling.
Adjustable Row Height or Compact View:Introduce a "compact view" or allow users to adjust row heights, enabling more rows to be visible at once in the table without excessive scrolling.
Column Customization and Visibility Toggle:Allow users to customize which columns are displayed and their order. This flexibility would let users prioritize the most relevant information and avoid unnecessary horizontal scrolling.
Full-Screen Mode for Data-Intensive Pages:Implement a full-screen mode for data-intensive pages, such as product variant management. This feature would temporarily hide sidebars and headers, maximizing the display area for the main content.
Responsive Design Improvements:Enhance the responsive behavior of tables to make better use of large monitors while still ensuring usability on smaller devices.
User Benefits: These changes would improve efficiency and usability for users managing large datasets, reducing unnecessary scrolling and clicks. It aligns with modern UI/UX standards and ensures a smoother, more professional experience for Shopware 6 users.The product variant management page in Shopware 6 wastes significant screen space on larger monitors, forcing unnecessary horizontal and vertical scrolling. The table is too narrow and doesn’t adapt to the available screen size, making key information harder to access.
Proposed Solution:
- Dynamically resize the table to fill the available screen space.
- Add options for compact view and column customization.
- Enable full-screen mode for data-intensive pages. These changes will enhance usability, save time, and improve the user experience.
Problem Description:
The current user interface of the Shopware 6 product variant management page does not efficiently utilize the available screen space…
13 votes
- Don't see your idea?