- or
No existing idea results
- ~ No ideas found ~
330 results found
-
Hide legal guarantee notice for B2B customers within mixed B2B/B2C sales channels
Currently, the legal guarantee notice in the checkout can be enabled or disabled per sales channel using the option “Show legal guarantee notice on checkout page.”
For B2B customers, this notice is generally not required. However, in practice, B2B and B2C customers are not always separated into different sales channels. It is common for both customer types to use the same sales channel.
It would therefore be helpful to introduce an additional condition for controlling the visibility of the legal guarantee notice. For example, the system could check the customer’s account type (private/business) or their customer group.
This would allow merchants to hide the legal guarantee notice for B2B customers while continuing to display it to B2C customers within the same sales channel.
Currently, the legal guarantee notice in the checkout can be enabled or disabled per sales channel using the option “Show legal guarantee notice on checkout page.”
For B2B customers, this notice is generally not required. However, in practice, B2B and B2C customers are not always separated into different sales channels. It is common for both customer types to use the same sales channel.
It would therefore be helpful to introduce an additional condition for controlling the visibility of the legal guarantee notice. For example, the system could check the customer’s account type (private/business) or their customer group.
This would allow…
2 votes -
Display subscription number for each order in the Admin
In the order overview in the Admin:
when looking at the list of orders, I currently cannot see from which subscription an order was created.It would make it easier to display the subscription number in the order details, to be able to know which subscription created the new order.
2 votes -
Improvement of Extension and Update Management
The management and updating of extensions could be made more efficient and transparent, especially for shops with a larger number of installed plugins.
The following improvements would be particularly helpful:
- Display the date of the last update in addition to the installation date of an extension
- History of activation and deactivation events for an extension
- Multi-selection for extensions, allowing multiple plugins to be activated, deactivated, or updated at once
- Central overview of available plugin updates and changelogs, so changes can be reviewed before updating without having to open each plugin individually
- More meaningful error messages during Shopware updates if a specific extension prevents the update, ideally identifying the affected extension directly
- Ability to enable maintenance mode directly from the update process
- Ability to trigger a backup before an update, ideally from the same central update workflow
Background:
During an update to Shopware 6.7.14.0, the update process via the Administration was repeatedly aborted without providing any clear indication of which extension was causing the issue.To identify the cause, extensions had to be deactivated individually and the update process retried each time. The Shopware update was eventually performed via the console, after which all extensions had to be activated individually again.
Especially for shops with many installed extensions, this process is very time-consuming. Multi-selection, combined with a clear indication of which extension is blocking an update, could significantly simplify both troubleshooting and the update process itself.
Reviewing upcoming plugin updates also currently requires many individual steps. To check what has changed, each plugin needs to be opened separately, its changelog located, and the user then has to navigate back to the extension management. A central overview of all available updates showing plugin name, current version, new version, and changelog would make preparing for updates considerably easier.
In addition, it would be useful to consolidate the functions relevant to a safe update process in one central location. Maintenance mode, backups, extension compatibility checks, plugin updates, and the Shopware update itself could become part of one structured update workflow.
Benefits:
Such an improvement to extension and update management would:- Reduce the amount of manual work required during updates
- Simplify troubleshooting of incompatible or problematic extensions
- Shorten maintenance windows and potential downtime
- Make update preparation clearer and more transparent
- Provide a safer and more structured overall update process
The management and updating of extensions could be made more efficient and transparent, especially for shops with a larger number of installed plugins.
The following improvements would be particularly helpful:
- Display the date of the last update in addition to the installation date of an extension
- History of activation and deactivation events for an extension
- Multi-selection for extensions, allowing multiple plugins to be activated, deactivated, or updated at once
- Central overview of available plugin updates and changelogs, so changes can be reviewed before updating without having to open each plugin individually
- More meaningful error messages during Shopware updates if a…
2 votes -
B2B Components - Quotes - Show requesting employee
Show requesting employee in the quote details in the admin. Preferably also in the quote overview in an additional column. Currently we only show the B2B customer / Debtor but we are not giving any details about the employee that requested an offer / quote.
2 votes -
Avoiding errors with Shopware Payments partial refund
This is a proposal of a SW Payments user:
They wanted to refund a partial amount of an order. Unfortunately the whole order was refunded.It would be helpful, if there was a "check form" which repeats the data of the refund and must be approved.
Perhaps a refund stop can be part of the resolution center.
2 votes -
Inheritance of elements in CMS pages
DE:
Aktuelle Systematik seitens Shopware:Man kann CMS-Seiten erstellen und in diesen innerhalb Sektionen verschiedene Blöcke und Elemente definieren. Nun habe ich die Möglichkeit in Kategorien entweder für jede Seite ein eigenes CMS-Layout zuzuweisen. Ebenso kann man aber auch das gleiche CMS-Layout mehreren Seiten zuweisen. Hier hat man dann die Möglichkeit die Inhalte der im Layout festgelegten Elemente zu individualisieren.
Nun entsteht dadurch folgende Problematik:
Angenommen ich habe 50 Kategorie-Seiten, welche alle das gleiche vorgegebene CMS-Layout nutzen. Dann habe ich nur die Möglichkeit die Inhalte der Blöcke/Elemente zu bearbeiten, kann aber nicht die Blöcke/Sektionen auf diverse Unterseiten vererben.
Sollte somit z.B. der Fall auftreten, dass ich von 10 dieser 50 Seiten mit dem gleichen Layout an erster Stelle keinen Slider mehr möchte (aber das restliche Layout soll beibehalten werden, bzw. der Aufbau aller darauf folgenden Elemente), so ist aktuell die einzige Möglichkeit für diese 10 Unterseiten neue Layouts anzulegen.
Diese Problematik lässt sich nun hochskalieren. Nehmen wir nun an, wir wollen von den 50 Seiten, auf 10 Seiten an erster Stelle keinen Slider und von diesen 10 Seiten soll bei 4 Seiten an letzter Stelle ein anderes Element sein, müsste ich nochmals diese 4 Seiten neu erstellen.
Obwohl von diesen 50 Seiten das Grundlayout bis auf einige Blöcke identisch ist, muss ich aktuell für jegliche Abweichung am Grundlayout neue eigene Seiten erstellen und kann nicht festlegen, dass z.B. Sektionen in einem CMS-Layout vererbbar sind.
Über eine Lösung seitens Shopware würden wir uns sehr freuen, das würde die Contentbearbeitung bei umfangreichen Inhalten mit mehr als 1000 Seiten enorm vereinfachen und wäre ein wirklicher Mehrwert.
ENG:
It is possible to create CMS pages and define different blocks and elements within sections. Categories can either be assigned their own individual CMS layout per page, or the same CMS layout can be assigned to multiple pages. In this case, the content of the elements defined in the layout can be customized individually.This leads to the following problem:
Assume there are 50 category pages that all use the same predefined CMS layout. In this scenario, it is only possible to edit the content of the blocks and elements, but it is not possible to inherit blocks or sections across different subpages.
For example, if on 10 of these 50 pages the slider should no longer appear as the first element (while the rest of the layout, including the structure of all subsequent elements, should remain the same), the only current solution is to create new layouts for these 10 subpages.
This issue can be scaled further. If, for instance, out of the 50 pages, 10 pages should not have a slider as the first element, and out of those 10 pages, 4 pages should have a different element at the last position, those 4 pages would again need to be created separately.
Although the base layout of these 50 pages is largely identical except for a few blocks, any deviation from the base layout currently requires creating entirely new pages. It is not possible to define sections within a CMS layout as inheritable.
We would greatly appreciate a solution from Shopware, as this would significantly simplify content management for large setups with more than 1,000 pages and would provide real added value.
DE:
Aktuelle Systematik seitens Shopware:Man kann CMS-Seiten erstellen und in diesen innerhalb Sektionen verschiedene Blöcke und Elemente definieren. Nun habe ich die Möglichkeit in Kategorien entweder für jede Seite ein eigenes CMS-Layout zuzuweisen. Ebenso kann man aber auch das gleiche CMS-Layout mehreren Seiten zuweisen. Hier hat man dann die Möglichkeit die Inhalte der im Layout festgelegten Elemente zu individualisieren.
Nun entsteht dadurch folgende Problematik:
Angenommen ich habe 50 Kategorie-Seiten, welche alle das gleiche vorgegebene CMS-Layout nutzen. Dann habe ich nur die Möglichkeit die Inhalte der Blöcke/Elemente zu bearbeiten, kann aber nicht die Blöcke/Sektionen auf diverse Unterseiten vererben.
Sollte somit…
12 votes -
Option for B2B Components order related mails send to customer Orga employee mail
In B2B environments, orders are often placed by employees acting on behalf of their organization. Currently, Shopware sends order confirmation emails only to the primary email address of the customer account (Main Account).
However, in many cases, it is desirable for the employee who submitted the order to also receive — or solely receive — the order confirmation email or documents.
To address this, a new configuration option should be added to the customer or organization settings, allowing administrators to define the default behavior for order confirmation emails.
Functional Proposal:
Add a setting in the B2B customer configuration:
Option A: Send order confirmation to the organization’s main (default) email address.
Option B: Send order confirmation to the email address of the employee who placed the order.
The setting should be adjustable per organization.
Optionally, allow sending to both addresses.
In B2B environments, orders are often placed by employees acting on behalf of their organization. Currently, Shopware sends order confirmation emails only to the primary email address of the customer account (Main Account).
However, in many cases, it is desirable for the employee who submitted the order to also receive — or solely receive — the order confirmation email or documents.
To address this, a new configuration option should be added to the customer or organization settings, allowing administrators to define the default behavior for order confirmation emails.
Functional Proposal:
Add a setting in the B2B customer configuration:
Option A:…
12 votes -
Enhanced Pricing Flexibility for Subscriptions
Current Limitation
At the moment, the same base product price is used for both one-time purchases and subscription purchases. This limits flexibility in commercial models and pricing strategies.Requested Enhancements
Option to Hide the One-Time Purchase Price
It should be possible to hide the one-time purchase option entirely for products that are primarily intended to be sold as subscriptions. This would allow merchants to position certain products as “subscription-only” without displaying a regular purchase alternative.Individual Pricing per Subscription Interval
If the one-time purchase price remains visible, merchants should have the ability to define separate prices per subscription interval (e.g., monthly, quarterly, yearly).
Currently, the same product price is used as the calculation basis for both one-time and subscription models, regardless of the selected interval.Example Use Case
One-time purchase: €25.000
Monthly subscription: €480
Quarterly subscription: €985
Annual subscription: €2.500In addition to pricing flexibility, we require enhanced control over how shipping costs are calculated for subscription products.
Requested Options
Merchants should be able to configure whether shipping costs are:
Charged for every subscription delivery,
Charged only once (e.g., for the initial order), or
Charged upfront for the minimum subscription interval (e.g., calculated once for the full minimum term).
Currently, there is no flexible configuration for subscription-specific shipping logic.
Current Limitation
At the moment, the same base product price is used for both one-time purchases and subscription purchases. This limits flexibility in commercial models and pricing strategies.Requested Enhancements
Option to Hide the One-Time Purchase Price
It should be possible to hide the one-time purchase option entirely for products that are primarily intended to be sold as subscriptions. This would allow merchants to position certain products as “subscription-only” without displaying a regular purchase alternative.Individual Pricing per Subscription Interval
If the one-time purchase price remains visible, merchants should have the ability to define separate prices per subscription interval (e.g.,…8 votes -
Simultaneous display of gross prices and net prices
Shopware 6 currently requires potential customers to be registered and logged in in order to display the correct prices (gross or net).
For potential customers visiting a shop, they will always be shown one of the two prices only (gross price seems to be the default), which is only the right price for one of the two customer groups (private or commercial).
One obvious solution to this problem would be displaying both gross and net prices simultaneously on article pages and on category pages, one price more prominent than the other (see attached screenshots from our current shop solution).
This can even make sense in case a customer is logged in, e.g. a private customer searching for articles for his private use and stumbling across an article that would be of use for his (own) company -- and vice versa!
I am not yet too familiar with Shopware yet, so I do not know all the configuration details yet, but maybe the following UX makes sense:
Instead of just having two radio buttons "display gross prices" and "display net prices" for a customer (group), show four radio buttons:
( ) display gross prices
( ) display net prices
( ) display both prices, gross prices first
( ) display both prices, net prices firstI guess there is some kind of "default" customer group everyone not logged in belongs to (that would probably make the most sense), so above 4-radio-button list could be configured for the default group, too, but if no such group exists or cannot be created, then have that 4-radio-button list also somewhere in the settings for default price display.
For shipping only within Germany, it should say "incl. 19 % German VAT" and "excl. 19 % German VAT" (well, the default VAT that is configured somewhere).
For shipping within the EU, you probably could get away with exactly the same as for shipping within Germany, as long as VATID-customers see "0 % VAT", because of Intra-Community deliveries (EU) being tax-exempt, if valid VAT identification number is provided by the buyer.
For world-wide deliveries and for digital products, I cannot give any advice -- IANAL, after all.
Finally, to give my request some backing, aside from votes (which probably not everyone knows about), I searched the forums for all posts that show the OP wants the same: simultaneous display of gross prices and net prices, and here is what I found on the first few search result pages (didn't go through all of them):
https://forum.shopware.com/t/brutto-netto-preise-gleichzeitig-anzeigen-lassen-plugin/92842
https://forum.shopware.com/t/preise-brutto-nett-anzeigen-aenderungen-in-twig-werden-nicht-angewendet/106348
https://forum.shopware.com/t/brutto-und-netto-preise-anzeigen/93185/4
https://forum.shopware.com/t/wie-kann-ich-in-artikelbeschreibung-brutto-netto-zeigen/8015
https://forum.shopware.com/t/auf-dokumentenvorlagen-brutto-und-netto-preise-anzeigen/102628
https://forum.shopware.com/t/b2b-neben-netto-auch-bruttopreise-anzeigen/23731
https://forum.shopware.com/t/netto-und-brutto-preise-anzeigen/46064
https://forum.shopware.com/t/brutto-nettopreis-im-store/85727
https://forum.shopware.com/t/brutto-und-nettopreis-zugleich-darstellbar/54258
https://forum.shopware.com/t/brutto-netto-auf-artikeldetailseite/38072
https://forum.shopware.com/t/zusatzlich-zu-den-brutto-preisen-auch-netto-preise-anzeigen/12547Thank you for your consideration!
P.S.: If I somehow missed that this is a feature already present (in the community edition), please point me in the right direction, decline this request, and let me slowly vanish by walking backwards into a hedge, like Homer Simpson.
Shopware 6 currently requires potential customers to be registered and logged in in order to display the correct prices (gross or net).
For potential customers visiting a shop, they will always be shown one of the two prices only (gross price seems to be the default), which is only the right price for one of the two customer groups (private or commercial).
One obvious solution to this problem would be displaying both gross and net prices simultaneously on article pages and on category pages, one price more prominent than the other (see attached screenshots from our current shop solution).
This…
2 votes -
Allow approvers to edit orders in B2B-Approval-Workflows
Problem Description:
In the current B2B approval workflow, users with an Approver can only approve or reject orders that are subject to approval rules.
Even if the role permissions are explicitly set to allow order-related actions, the approver cannot make any changes to the order before approving it.
This is a limitation for real-world B2B processes, where ordering mistakes are common and must be corrected by the approver instead of rejecting and recreating the order.
Current Behavior:
When an order requires approval:
- The approver can only approve or reject the order
- The approver cannot:
- Change product quantities
- Remove order positions
- Change payment method
- Change shipping method
- Edit billing or shipping addresses
- Write a comment on the order, regardless of approvalThis behavior applies even if the corresponding permissions are assigned to the approver role.
Expected Behavior:
Approvers should be able to edit an order before approval, according to the permissions defined for their role.
If the role permissions allow it, an approver should be able to:
- Remove order line items
- Adjust product quantities
- Change payment method
- Change shipping method
- Edit billing and shipping addresses
- Regardless of approval or rejection, write a comment on the orderThe approval decision (approve/reject) should then apply to the modified order.
Business Impact:
In B2B commerce, approval workflows are meant to:
- Correct ordering mistakes
- Ensure compliance with company rules
- Avoid unnecessary rejections and re-ordersRestricting approvers to only approve or reject orders leads to:
- Inefficient workflows
- Increased manual effort
- Poor user experience for B2B customersThis behavior does not reflect common B2B purchasing processes, where approvers are expected to correct errors rather than reject orders entirely.
Problem Description:
In the current B2B approval workflow, users with an Approver can only approve or reject orders that are subject to approval rules.
Even if the role permissions are explicitly set to allow order-related actions, the approver cannot make any changes to the order before approving it.
This is a limitation for real-world B2B processes, where ordering mistakes are common and must be corrected by the approver instead of rejecting and recreating the order.
Current Behavior:
When an order requires approval:
- The approver can only approve or reject the order
- The approver cannot:
- Change product quantities…8 votes -
Cloud: Storing individual files in the root directory
Cloud customers frequently need a simple way to place files in the root directory. In most cases, this is required for website authentication with Google. Currently, the available methods for customers are quite complicated (e.g., creating a custom app). A more user-friendly solution should be provided.
2 votes -
Custom fields from apps cannot be repositioned.
Custom fields from apps cannot be repositioned. This means that, for example, such fields end up in product locations that are potentially completely unsuitable and irrelevant.
According to the software vendor, this is due to the Shopware core. This should be adjusted.
Feedback from the manufacturer:
"If you create custom fields within an app, these cannot be edited in the Shopware admin panel. This is a limitation of Shopware, and unfortunately, we cannot change it. Within an app, custom fields are only 'defined' in an XML file. No programming is done here to determine how and where the field is displayed. This is decided by Shopware in the core."Custom fields from apps cannot be repositioned. This means that, for example, such fields end up in product locations that are potentially completely unsuitable and irrelevant.
According to the software vendor, this is due to the Shopware core. This should be adjusted.
Feedback from the manufacturer:
"If you create custom fields within an app, these cannot be edited in the Shopware admin panel. This is a limitation of Shopware, and unfortunately, we cannot change it. Within an app, custom fields are only 'defined' in an XML file. No programming is done here to determine how and where the field is…4 votes -
Commercial: improve organization units for shopping lists
Currently, the organization unit field on shopping lists is purely an informational indicator from which unit the list was originally created.
The following improvements should be added to give this more utility:
- The OU field should be definable during creation (i.e. by admins or the customer account) and changeable / re-assignable afterwards when needed.
- Role permissions should be added that define which lists from which OU an employee can see - this allows better separation between units which should not see lists from other departments.
4 votes -
Offline/Developer mode for the commercial plugin in local development environments
Partners and agencies often work on multiple client projects simultaneously. Consequently, a local development environment may contain extensions for various clients, even though those extensions are neither actively used nor tested there.
The commercial plugin currently checks installed extensions and their license status but cannot distinguish between an extension that is merely part of the local development environment and one that is actually in use. In development environments, this can lead to unexpected license checks or subsequent actions.
An optional offline or developer mode for local development environments—intended exclusively for non-production systems—would be beneficial. Alternatively, a way to clearly designate local development environments as such would help, allowing license checks to be adjusted accordingly.
Added value:
- Better support for agencies and partners managing multiple client projects.
- Fewer unintended license conflicts in local development environments.
- Improved developer experience with no impact on production systems.Partners and agencies often work on multiple client projects simultaneously. Consequently, a local development environment may contain extensions for various clients, even though those extensions are neither actively used nor tested there.
The commercial plugin currently checks installed extensions and their license status but cannot distinguish between an extension that is merely part of the local development environment and one that is actually in use. In development environments, this can lead to unexpected license checks or subsequent actions.
An optional offline or developer mode for local development environments—intended exclusively for non-production systems—would be beneficial. Alternatively, a way to clearly designate…
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.
-
Digital Sales Room - Live Queue & Direct Call Functionality
Enhance the Digital Sales Room by introducing a real-time interaction feature (Button Frontend) that allows customers to directly request live consultations with available presenters, including a queue system for managing demand.
Use Case Example:
A customer browsing the Onlineshop has a question about a product or offering. Instead of waiting for a scheduled session, they can immediately request a consultation. If no presenter is available, they are placed in a queue and connected as soon as possible.
This feature would significantly enhance the flexibility and usability of the Digital Sales Room, turning it into a hybrid tool that supports both events and real-time customer engagement.
Enhance the Digital Sales Room by introducing a real-time interaction feature (Button Frontend) that allows customers to directly request live consultations with available presenters, including a queue system for managing demand.
Use Case Example:
A customer browsing the Onlineshop has a question about a product or offering. Instead of waiting for a scheduled session, they can immediately request a consultation. If no presenter is available, they are placed in a queue and connected as soon as possible.
This feature would significantly enhance the flexibility and usability of the Digital Sales Room, turning it into a hybrid tool that supports both…
5 votes -
Artikelübersichtstabelle (Kataloge|Produkte) | Improve product lists
Es wäre sehr hilfreich, wenn im Backend bei der Artikelübersicht weitere Spalten zur Ansicht ein-/ausgeblendet werden könnten, so wie in SW5. Wenn man eine schnelle Übersicht haben will, welche Artikel z.B. eine bestimmte Eigenschaft haben.
Filterbar sind Eigenschaften auch nicht. Dies wäre eine hilfreiche alternative Funktion.
So ist eine Pflege mehrerer Artikel sehr umständlich. Da war SW5 deutlich besser.
Diese Funktionalität wäre für mich eigentlich eine Standardfunktion. Wann wird hier nachgebessert?
–
It would be very helpful if additional columns could be toggled on or off in the backend product overview, just like in SW5—for instance, to get a quick overview of which products have a specific property.
Properties cannot be filtered either; that would be a useful alternative feature.
As it stands, managing multiple products is very cumbersome. SW5 was significantly better in this regard.
To me, this is essentially a standard feature. When will this be improved?
Es wäre sehr hilfreich, wenn im Backend bei der Artikelübersicht weitere Spalten zur Ansicht ein-/ausgeblendet werden könnten, so wie in SW5. Wenn man eine schnelle Übersicht haben will, welche Artikel z.B. eine bestimmte Eigenschaft haben.
Filterbar sind Eigenschaften auch nicht. Dies wäre eine hilfreiche alternative Funktion.
So ist eine Pflege mehrerer Artikel sehr umständlich. Da war SW5 deutlich besser.
Diese Funktionalität wäre für mich eigentlich eine Standardfunktion. Wann wird hier nachgebessert?
–
It would be very helpful if additional columns could be toggled on or off in the backend product overview, just like in SW5—for instance, to get a quick…
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.
-
Warning in Administration when APP_DEBUG=1 is enabled in production environment
In a productive Shopware 6 installation, APPDEBUG=1 may temporarily be enabled during troubleshooting and then unintentionally remain active afterward. Based on our findings, this causes Shopware to output a noindex directive in the storefront, even when APPENV=prod is explicitly set.
This creates a critical SEO risk because the issue can easily go unnoticed and may ultimately lead to the shop being removed from the Google index.
Problem:
Currently, there seems to be no visible warning in the Administration when a production environment is running with APP_DEBUG=1Expected Behavior:
If APPENV=prod and APPDEBUG=1 are detected at the same time, Shopware should clearly warn administrators about this potentially dangerous configuration.Possible implementations could include:
- a visible warning message in the Administration dashboard
- a dedicated system health check
- a notification explaining the potential SEO impactBenefit:
Such a warning would help prevent accidental SEO issues caused by forgotten debug configurations in production environments.In a productive Shopware 6 installation, APPDEBUG=1 may temporarily be enabled during troubleshooting and then unintentionally remain active afterward. Based on our findings, this causes Shopware to output a noindex directive in the storefront, even when APPENV=prod is explicitly set.
This creates a critical SEO risk because the issue can easily go unnoticed and may ultimately lead to the shop being removed from the Google index.
Problem:
Currently, there seems to be no visible warning in the Administration when a production environment is running with APP_DEBUG=1Expected Behavior:
If APPENV=prod and APPDEBUG=1 are detected at the…4 votes -
Admin: ability to display all products of category including subcategories
Currently, one cannot display all products from a category including subcategories in the administration. Both the filter on the product page and the assigned products page of the category will only display directly assigned products.
It would be helpful to have a filter option to display products of subcategories as well. Otherwise, one would need to use workarounds via dynamic product groups, the API, or Import/Export.
5 votes -
Import/Export Cheapest price (last 30 days)
There should be a way to import/export the cheapest price (last 30 days).
There is a regulationPrice in the price field for this purpose, but it cannot currently be mapped.
12 votes -
wish list: sending the whole wish list to cart
It would be nice to send the whole wish list to cart at once via one click.
2 votes
- Don't see your idea?