- or
No existing idea results
- ~ No ideas found ~
1528 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 vote -
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 vote -
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 vote -
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 vote -
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 vote -
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 votes -
Separate customer e-mail address for sending invoices (billing address)
Deutsch:
Die Erfahrung zeigt, dass die meisten Geschäftskunden eine eigene E-Mail-Adresse für den Rechnungsempfang haben, um ihre Buchhaltung zu organisieren und Rechnungen zentral zu sammeln. Aus diesem Grund sollte Shopware 6 es den Kunden ermöglichen, nicht nur eine separate Rechnungsadresse, sondern auch eine separate E-Mail-Adresse für den Rechnungsempfang anzugeben. Diese sollte dann auch zum Export (via API etc.) in das ev. angebundene ERP zur Verfügung stehen.Englisch:
Experience shows that most business customers have a separate email address for receiving invoices in order to organise their accounting and collect invoices centrally. For this reason, Shopware 6 should allow customers to specify not only a separate billing address, but also a separate email address for receiving invoices. This should then also be available for export (via API etc.) to any connected ERP.Deutsch:
Die Erfahrung zeigt, dass die meisten Geschäftskunden eine eigene E-Mail-Adresse für den Rechnungsempfang haben, um ihre Buchhaltung zu organisieren und Rechnungen zentral zu sammeln. Aus diesem Grund sollte Shopware 6 es den Kunden ermöglichen, nicht nur eine separate Rechnungsadresse, sondern auch eine separate E-Mail-Adresse für den Rechnungsempfang anzugeben. Diese sollte dann auch zum Export (via API etc.) in das ev. angebundene ERP zur Verfügung stehen.Englisch:
Experience shows that most business customers have a separate email address for receiving invoices in order to organise their accounting and collect invoices centrally. For this reason, Shopware 6 should allow customers to…5 votes -
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 votes -
Migrate advanced search configuration to all Storefronts
The configuration options in the advanced search are numerous and complex to maintain.
If you want to set boostings, actions and synoyms in all storefronts, the same configuration has to be made 24 times in our case, although we only have 4 different languages.
This maintenance effort could be considerably simplified by a migration feature/option.9 votes -
Add hreflang support across multiple sales channels
Currently hreflang only applies to different domains within one sales channel. It would be useful to be able to define other languages for hreflang tags across multiple sales channels (i.e. separate sales channels for EU and US, linking to each other)
8 votes -
Use Thumbnails for Property Images in Filter
Please adjust the default template
Resources/views/storefront/component/listing/filter/filter-property-select.html.twig
so that when images are assigned to properties, the appropriate thumbnail images are used instead of the full original images.Currently, the original image is loaded, which can negatively impact page load performance.
In our instance, I’ve already implemented a manual fix by replacing:
{% set media = element.media.url %}
with:
{% set media = element.media.thumbnails | filter(t => t.width == 100 and t.height == 100) | first.url %}This ensures that a 100x100 thumbnail is used when available.
4 votes -
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.
31 votes -
Advanced product catalogue -> display new products but deactivate buy function
Extend the existing Advanced Product Catalog functionality
The existing Advanced Product Catalog should be extended to allow new added products and categories in the shop to be visible in the storefront but not purchasable by default (Not Show Add to Basket Button).
Only after explicitly adding them to the active B2B catalog should they become available for purchase. This enables merchants to showcase their full product range—e.g. for previews, B2B catalogs, or product teasers—without making new items immediately orderable. It supports better assortment planning, pre-marketing, and channel-specific catalog management.
3 votes -
Customer-specific product restriction like min/max/stacking for order quantity
Customer-related product restriction such as min/max/staggered quantity per order. The values on the product are currently Global.
In the B2B case in particular, you want to be able to set the minimum or maximum quantity of this product that the customer can order per customer. As this rule can differ per customer or customer group, it cannot currently be implemented as the rule applies globally for the product.
3 votes -
Media: Media search with storage location information
If, for example, you search for an image in the media, you will receive the image and some additional details, but it is not clear in which folder within a potentially large structure the image is located.
In order to check the storage location, it is essential to have information about where the file is located or the option to open the folder directly under “Actions.”
3 votes -
Language inheritance for Custom Fields
Just like other fields in the products (title, description, etc.) the custom fields should inherit the values from a parent language unless overwritten. Currently, they just remain empty.
7 votes -
B2B Components - Allow default permissions for new accounts or customer groups
There should be an option to set default permissions for new user accounts, perhaps based on customer group assignment. Currently the only way to automatically enable B2B Components features is through a custom registration form.
8 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 vote -
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
- Don't see your idea?