- or
No existing idea results
- ~ No ideas found ~
385 results found
-
Social Shopping / Product comparison: Media URL with sales channel domain
EN
We often receive enquiries about how image links in product comparisons or social shopping can be adjusted to use the domain of the exporting sales channel. There were already tickets for this in the old issue tracker: e.g. https://issues.shopware.com/issues/NEXT-17674.However, this ticket was then created last year https://github.com/shopware/shopware/issues/4807, reporting that CDN media were receiving the wrong domain.
Programme request:
Please adjust the URL determination for media so that the handling of media links follows the same pattern as the product links within a product comparison. Of course, it must be possible to resolve the link. CDNs must also be taken into account, whereby the request was also made that it should be possible to resolve the domains per sales channel.According to tests in Shopware 6.7.4.2, the domain from APP_URL is used during export; no adjustment to other sales channels is made. Neither AI nor humans can find any information in the (dev) documentation as to whether and, if so, how it is possible to change this behaviour. If there are already settings options for the media link, it would be necessary to document these clearly and display them in the search.
DE
Es kommt öfter die Nachfrage, wie in Produktvergleichen oder Social Shopping die Bildlinks so angepasst werden können, dass sie die Domäne des exportierenden Verkaufskanals nutzen. Da zu gab es im alten Issuetracker bereits Tickets: z.B. https://issues.shopware.com/issues/NEXT-17674.Jedoch wurde im letzten Jahr dann dieses Ticket erstellt https://github.com/shopware/shopware/issues/4807, worin gemeldet wurde, dass CDN Medien die falsche Domain erhielten.
Programmwunsch:
Bitte die URL Ermittlung für Medien so anpassen, dass die Behandlung von Medienlinks dem gleichen Schema folgt wie die Produktlinks innerhalb eines Produktvergleichs. Natürlich muss der Link aufgelöst werden können. Außerdem berücksichtigt werden müssen naturlich CDNs, wobei hier auch der Wunsch geäußert wurde, dass es ebenfalls möglich sein soll die Domänen pro Verkaufskanal aufzulösen.Gemäß Versuchen in Shopware 6.7.4.2 wird beim Export die Domäne aus der APP_URL verwendet, eine Anpassung an andere Verkaufskanäle erfolgt nicht. Weder KI noch Mensch finden in der (Dev-)Dokumentation Hinweise, ob und wenn ja wie, eine Änderung des Verhaltens möglich ist. Falls es bereits Einstellmöglichkeiten für den Medienlink gibt, wäre es notwendig diese verständlich zu dokumentieren und in der Suche anzuzeigen.
EN
We often receive enquiries about how image links in product comparisons or social shopping can be adjusted to use the domain of the exporting sales channel. There were already tickets for this in the old issue tracker: e.g. https://issues.shopware.com/issues/NEXT-17674.However, this ticket was then created last year https://github.com/shopware/shopware/issues/4807, reporting that CDN media were receiving the wrong domain.
Programme request:
Please adjust the URL determination for media so that the handling of media links follows the same pattern as the product links within a product comparison. Of course, it must be possible to resolve the link. CDNs must…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.
-
Admin content language selection
When you currently access an overview in our Admin (e.g. Product overview), the content will always be shown in the system default language, no matter what your admin user setting is. I have attached a screenshot, where you can see, that the menus overall are all in english but the content is showing the german language instead, since it's the default system language.
This really annoying since it forces me to switch in every menu the content language back to english.
My suggestion would be to take the language settings of the admin user into account and always show the content also in that language.
When you currently access an overview in our Admin (e.g. Product overview), the content will always be shown in the system default language, no matter what your admin user setting is. I have attached a screenshot, where you can see, that the menus overall are all in english but the content is showing the german language instead, since it's the default system language.
This really annoying since it forces me to switch in every menu the content language back to english.
My suggestion would be to take the language settings of the admin user into account and always show 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.
-
API extension: Make trial status for plugin rentals queryable
For extensions with usage-based features (e.g., character quotas, API limits, etc.), it would be very helpful to be able to query the current trial status of a plugin rental via API.
Specifically, the following scenario applies:
For plugins that unlock the full range of functions during the trial month (e.g., a translation plugin that can translate almost the entire shop), we are increasingly observing that users take advantage of the free month to translate the entire shop once and then cancel. Without a technical way to recognize the trial month, it is difficult to limit this fairly.A simple flag would be desirable, e.g., isTrialActive, which can be queried via API. This would allow us to activate a transparent limitation during the trial period and automatically unlock full functionality after it expires.
Example application:
During the trial month:
- quota of, for example, 100,000 characters.
- All functions can be tested realistically.
- However, the free trial month is not used as a full “free full version.”After the end of the trial: Automatic release of the full quota/scope with active rental
Such a trial flag would make it possible to design fair trial periods – both for merchants (realistic testing) and for developers (protection against abuse) – without complicated workarounds or external billing logic.For extensions with usage-based features (e.g., character quotas, API limits, etc.), it would be very helpful to be able to query the current trial status of a plugin rental via API.
Specifically, the following scenario applies:
For plugins that unlock the full range of functions during the trial month (e.g., a translation plugin that can translate almost the entire shop), we are increasingly observing that users take advantage of the free month to translate the entire shop once and then cancel. Without a technical way to recognize the trial month, it is difficult to limit this fairly.A simple flag…
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.
-
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…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.
-
Add “tax column instead of unit price” option to cart as well
In Shopware 6.7.1 the option to display either the unit price or the VAT of the respective line item was introduced. However, it only changes the list in the checkout. It would be useful to have the same option for the cart as well.
DE: In Shopware 6.7.1 wurde die Option “Steuerspalte anstatt Stückpreis” eingeführt, die entweder den Stückpreis oder die Mehrwertsteuer der jeweiligen Position anzeigt. Diese Änderung betrifft jedoch nur die Liste im Checkout. Es wäre sinnvoll, dieselbe Option auch für den Warenkorb zu haben.
3 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
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…
23 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.
-
Support for Spanish NIE Numbers in VAT/Tax ID Validation
In the merchant registration form (e.g., via the B2B Suite or customer registration), Spanish NIE numbers are currently rejected as invalid VAT/Tax IDs. However, the NIE (Número de Identidad de Extranjero) is the official fiscal identification number for foreigners in Spain and is accepted by the Spanish tax authorities.
A valid NIE follows this format:
Starts with X, Y, or Z → 7 digits → ends with a letter
Example: Y5432178PCurrently, the validation logic does not accept such values, blocking legitimate registrations from Spain-based users.
5 votes -
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 -
Settings > Log-in & sign-up: Add company name field required
Use Case: We have two sales channels (B2B and B2C) and could set this up in the B2B sales channel.
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.
-
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.
-
Revision of list prices
The implementation of strikethrough prices has been poorly and even incompletely implemented. In the ITA shop, we don't have a proper way to display a sale category, as the default function here also goes to the first tab.
And independently, the in-house solution/rule for discounted items in the dynamic product groups is incredibly slow.
The host once sent me the Slow Query. If printed out, I could wallpaper at least half the room (high ceilings in an old Berlin building).
So please take a look at the topic. Anyone who has multiple sales channels and different prices within them will wish they were back in Shopware 5. It was all easy peasy and performant.
The implementation of strikethrough prices has been poorly and even incompletely implemented. In the ITA shop, we don't have a proper way to display a sale category, as the default function here also goes to the first tab.
And independently, the in-house solution/rule for discounted items in the dynamic product groups is incredibly slow.
The host once sent me the Slow Query. If printed out, I could wallpaper at least half the room (high ceilings in an old Berlin building).
So please take a look at the topic. Anyone who has multiple sales channels and different prices within them will…
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.
-
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 -
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.
87 votes -
Logging of running flows
For monitoring the system and testing flows, it is extremely important that there is logging in the admin area.
The following information is important for logging:
- When did the flow run?
- Which trigger was activated?
- Which data was fed into the flow?
- Which data was decisive for the conditions?Zapier provides excellent logging for such systems.
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.
-
"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 salutation…
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.
-
Hide empty entities in search results
Add an option that allows to hide empty entities in search results.
One example here would be manufacturers that are not being assigned to any products in the given sales channel.
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?