- or
No existing idea results
- ~ No ideas found ~
1572 results found
-
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…
10 votes -
Custom coupon codes as variables
It should be possible to automatically send individual coupon codes via email, for example, as a variable in email templates.
3 votes -
Wero within Shopware Payments
The new Paypment sytem "Wero" should be available in Shopware Payments.
2 votes -
Expanding the Electronic Revocation Function
Current status:
Only the standard Shopware order number field is usable.Problem:
- In professional setups, the ERP system is often the primary system.
- The Shopware order number is not relevant internally.
- A custom field is used instead for the ERP order number.
- The back office works exclusively with this ERP number.Suggested improvement:
- Offer a choice in the admin panel:
- Either the standard Shopware order number
- Or a selectable custom field (e.g., ERP order number)
- Ideally, as a dropdown menu option in the admin panel.Background:
Larger retailers with multiple sales channels often use an ERP system. Therefore, this is not an isolated case.Current status:
Only the standard Shopware order number field is usable.Problem:
- In professional setups, the ERP system is often the primary system.
- The Shopware order number is not relevant internally.
- A custom field is used instead for the ERP order number.
- The back office works exclusively with this ERP number.Suggested improvement:
- Offer a choice in the admin panel:
- Either the standard Shopware order number
- Or a selectable custom field (e.g., ERP order number)
- Ideally, as a dropdown menu option in the admin panel.Background:
Larger retailers with multiple sales channels…3 votes -
Automated Calculation of Fees (Customs & Taxes) in Checkout for International Orders
Currently, Shopware 6 does not provide a native feature for automatically calculating variable fees such as customs duties, import taxes, or country-specific charges during checkout.
However, this functionality is increasingly important for international merchants to ensure a legally compliant and transparent order process.Competing platforms (e.g., Shopify) already offer this functionality as a built-in feature. It enables automated calculation and display of additional fees (e.g., customs duties, import VAT, service fees) based on product value, shipping destination, product category, or customs tariff number (HS code).
In Shopware, this can currently only be achieved through manual configuration using the shipping method price matrix, which is not dynamic and cannot handle complex calculation logic (e.g., article-based or country-based variations). Additionally, surcharges added via the price matrix are included in the cart subtotal, leading to incorrect tax and duty calculations when these are applied again on top.
Use Cases:
International Shipping: Merchants shipping outside the EU (e.g., to the US, UK, Canada, or Switzerland) need to automatically calculate and display customs and import duties.
Legal Compliance & Transparency: Customers should be informed of all applicable fees during checkout to prevent unexpected costs or returns.
Automation & Efficiency: Merchants want to automate fee calculation via integrations with external tax or logistics services (e.g., Avalara, Zonos, FedEx API, etc.) rather than maintaining manual tables.
Competitive Edge: Competing eCommerce systems like Shopify or BigCommerce already include this capability, putting Shopware at a disadvantage, especially for international merchants.
Suggested Implementation:
-
Introduce a dynamic fee calculation module within checkout, based on:
- Shipping destination
- Product item data (including tariff/HS code)
- Total cart value
- Potentially also carrier or fulfillment method
Provide API endpoints and plugin interfaces for integrating external tax or customs calculation services.
-
Add configurable admin settings to define:
- Which fee types should be calculated (customs, taxes, service fees, etc.)
- Whether the fees should be shown in the cart or added during checkout only.
The technical foundation could be a core-level extensibility module that third-party providers can build upon.
Benefits:
Increased legal compliance for international trade.
Transparent cost display for customers.
Reduced cart abandonment rates due to unexpected delivery charges.
Improved competitiveness and attractiveness for global and enterprise merchants.
Currently, Shopware 6 does not provide a native feature for automatically calculating variable fees such as customs duties, import taxes, or country-specific charges during checkout.
However, this functionality is increasingly important for international merchants to ensure a legally compliant and transparent order process.Competing platforms (e.g., Shopify) already offer this functionality as a built-in feature. It enables automated calculation and display of additional fees (e.g., customs duties, import VAT, service fees) based on product value, shipping destination, product category, or customs tariff number (HS code).
In Shopware, this can currently only be achieved through manual configuration using the shipping method…
15 votes -
Highlight incomplete CAPTCHA field in checkout
In the current Shopware SaaS checkout, which uses FriendlyCaptcha, users sometimes overlook the CAPTCHA field. After filling out all required fields, they attempt to continue the checkout process, but nothing happens. There is no indication that the CAPTCHA is missing.
While other required fields are highlighted in red or otherwise marked when incomplete, the CAPTCHA field does not receive any visual feedback. This can lead to confusion and interrupt the checkout experience.
It is therefore suggested that the CAPTCHA field be visually highlighted (e.g., marked in red) when it has not been completed, consistent with the behavior of other required fields. This improvement could help ensure a smoother and clearer checkout flow for users.
In the current Shopware SaaS checkout, which uses FriendlyCaptcha, users sometimes overlook the CAPTCHA field. After filling out all required fields, they attempt to continue the checkout process, but nothing happens. There is no indication that the CAPTCHA is missing.
While other required fields are highlighted in red or otherwise marked when incomplete, the CAPTCHA field does not receive any visual feedback. This can lead to confusion and interrupt the checkout experience.
It is therefore suggested that the CAPTCHA field be visually highlighted (e.g., marked in red) when it has not been completed, consistent with the behavior of other required…
11 votes -
Reintroduce CLI commands (functionality) for Migrations
CLI commands for migrations have been removed from release 16 (see https://github.com/shopware/shopware/issues/10825) without proper replacement.
As a result it is currently not possible to migrate with a finer selection via the CLI. One has to select an entire data category (i.e. all products) to migrate, making it more difficult and time-consuming in larger shops to debug issues.
2 votes -
Passwortfelder in Storefront mit "Passwort anzeigen"-Funktion ausstatten
In der Shopware-Storefront wäre es hilfreich, Passwortfelder standardmäßig mit einer Möglichkeit zum Ein- und Ausblenden des eingegebenen Passworts auszustatten, z. B. über ein Auge-Icon.
Das betrifft insbesondere:
Passwort-Wiederherstellung
Login / RegistrierungAus UX-Sicht ist das inzwischen ein verbreitetes Pattern und hilft Kunden, Tippfehler zu vermeiden. Gerade bei der Passwort-Wiederherstellung müssen Nutzer neue Passwörter oft mehrfach eingeben, wodurch eine Sichtbarkeitsoption die Bedienbarkeit verbessern würde.
Wichtig wäre, dass dies nur eine reine Frontend-Funktion ist und keine Änderung an Passwortlogik, Validierung, Sicherheit oder Speicherung vornimmt.
EN: In the Shopware Storefront, it would be helpful if password fields included an option to show and hide the entered password by default, for example via an eye icon.
This applies in particular to:
Password recovery
Login / registrationFrom a UX perspective, this has become a common pattern and helps customers avoid typos. Especially during password recovery, users often have to enter new passwords multiple times, so a visibility toggle would improve usability.
It would be important that this remains a purely frontend feature and does not change any password logic, validation, security, or storage.
In der Shopware-Storefront wäre es hilfreich, Passwortfelder standardmäßig mit einer Möglichkeit zum Ein- und Ausblenden des eingegebenen Passworts auszustatten, z. B. über ein Auge-Icon.
Das betrifft insbesondere:
Passwort-Wiederherstellung
Login / RegistrierungAus UX-Sicht ist das inzwischen ein verbreitetes Pattern und hilft Kunden, Tippfehler zu vermeiden. Gerade bei der Passwort-Wiederherstellung müssen Nutzer neue Passwörter oft mehrfach eingeben, wodurch eine Sichtbarkeitsoption die Bedienbarkeit verbessern würde.
Wichtig wäre, dass dies nur eine reine Frontend-Funktion ist und keine Änderung an Passwortlogik, Validierung, Sicherheit oder Speicherung vornimmt.
EN: In the Shopware Storefront, it would be helpful if password fields included an option to show and…
2 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.
3 votes -
Maximum amount of products or maximum sum for the cart
Currently, there is no elegant way to set order limits with product amounts or the total sum per order.
One can create rules via the rule builder and use them to hide shipping methods once the limit is surpassed, but there is no transparent message for the customer that there are limits or that they have been reached.
Analogous to the “Maximum quantity” in the cart settings it would be useful to set order limits similarly, perhaps on a per sales channel basis or even on a customer group basis. Once the limit has been reached, the storefront could hinder the user from adding more items to the cart with a clear error message.
Currently, there is no elegant way to set order limits with product amounts or the total sum per order.
One can create rules via the rule builder and use them to hide shipping methods once the limit is surpassed, but there is no transparent message for the customer that there are limits or that they have been reached.
Analogous to the “Maximum quantity” in the cart settings it would be useful to set order limits similarly, perhaps on a per sales channel basis or even on a customer group basis. Once the limit has been reached, the storefront could hinder…
2 votes -
Easier customization of email templates
Customizing email templates is usually quite complex and hardly feasible for the average customer. For example, adding the manufacturer's name for each item in the order confirmation.
The entire process of customizing email templates should be significantly simplified and made much more intuitive. We also receive a large number of support requests regarding this.
5 votes -
Checkbox für AGB entfernen, weil rechtlich unnötig
Laut https://www.heise.de/hintergrund/Warum-im-Netz-Checkboxen-fuer-AGB-und-Datenschutz-meist-ueberfluessig-sind-10449542.html braucht man keine Checkboxen für Datenschutzerklärung und AGB.
Durch das Entfernen der Checkbox für die AGB im Checkout ist der Checkout viel schneller und einfacher.
Bei der verlinkten Seite sind Formulierungen für den Text angegeben. Ohne Checkbox muss der Text angepasst werden.
Viele Besucher übersehen die Checkbox, klicken auf den Kaufen-Button und bekommen dann eine Fehlermeldung, dass sie erst einen Haken setzen müssen.
26 votes -
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…3 votes -
B2B: allow defining and using of multiple VAT IDs per customer account
Currently, only one VAT ID can be defined for a customer. This may be undesirable for some companies that are tightly related to other legal entities or have sub-companies they want to create orders for. In that case, multiple customer accounts would need to be created for proper invoicing.
The database structure already has a field to store a VAT ID with an address, so it would be useful to allow saving different VAT IDs depending on the address, so that customer can choose them during checkout.
7 votes -
Structured data for AI readability
I recently stumbled upon this press release by one of our partners - basically an ad for their plugin: https://www.openpr.de/news/1299320/Shopware-Shops-werden-KI-sichtbar-mitho-veroeffentlicht-KI-Agentic-Commerce-Plugin.html
However, as Shopware wants to go ahead with AI massively, the proposed features seem to be basic when it comes towards being prepared for AI readability:
- structured product and category feeds in JSON format
- llms.txt and other manifests for AI
- precise microdata and JSON descriptions of variants, prices, shipping etc.
7 votes -
Central Management and Exclusion of Image Keywords in Shopware
Problem:
The Shopware Image Keyword Assistant generated irrelevant and misleading keywords for a product image. In this specific case, keywords such as “Kanalisation,” “Kanalschacht,” and “Loch” were detected or generated — likely based on a small detail within the image — and do not accurately represent the product. These terms are inappropriate and not acceptable from a merchant’s perspective.
Example of generated keywords:
“Loch, Abtropfen lassen, Kanalisation, Kanalschacht, Loch, Abtropfen lassen, Kanalisation, Kanalschacht, Bodenmatte, Gepäckmatte, Autoabdeckung, Kofferraummatte, Rutschfeste Matte, matte de, tappetino auto, sotto-pavimento?, antiscivolo, tappeto auto”
The terms “Kanalisation,” “Kanalschacht,” and “Loch” are clearly not relevant and do not meet expected quality standards.
Current Limitation:
At present, Shopware does not provide a way for merchants to centrally exclude or remove unwanted keywords. The only option is to manually edit keywords per media item in the media library. This becomes highly inefficient when the issue affects multiple assets (e.g., 50 images all containing the same incorrect keyword like “Kanalisation”).
Proposed Solution:
Introduce a centralized/global keyword management feature that allows merchants to:
- Define a list of excluded keywords (blacklist)
- Automatically prevent these keywords from being generated in the future
- Remove these keywords across all existing media assets in bulk
- Optionally trigger an update of affected metadata (e.g., alt texts) when keywords are removed
This would significantly improve efficiency, ensure higher data quality, and give merchants better control over automatically generated content.
Problem:
The Shopware Image Keyword Assistant generated irrelevant and misleading keywords for a product image. In this specific case, keywords such as “Kanalisation,” “Kanalschacht,” and “Loch” were detected or generated — likely based on a small detail within the image — and do not accurately represent the product. These terms are inappropriate and not acceptable from a merchant’s perspective.
Example of generated keywords:
“Loch, Abtropfen lassen, Kanalisation, Kanalschacht, Loch, Abtropfen lassen, Kanalisation, Kanalschacht, Bodenmatte, Gepäckmatte, Autoabdeckung, Kofferraummatte, Rutschfeste Matte, matte de, tappetino auto, sotto-pavimento?, antiscivolo, tappeto auto”
The terms “Kanalisation,” “Kanalschacht,” and “Loch” are clearly not relevant and do not…
3 votes -
UX improvement: Switch directly from the backend product to the frontend view.
When you do changes in backoffice of a product there should be a button from wich you can directly open a new tab with the product in frontend. So you can easily and fast check your changes
6 votes -
Shopware Account Plugin License List Update
The current license list overview of the shop in the account.shopware.com is sadly not really handy for customers / agencies.
When updating to later Shopware Versions, you need mostly plugin updates to get back from a broken to a working state (e.g. 6.6 > 6.7, php bin/console fails as well):
- Therefore I have to go to said website, search for the plugin name (somehow over name / description mixed, because names are handled differently in the search)
- Then click on the plugin (when i finally found it) and get the update version.
- Another plugin must be found the same way again.
A better solution would be:
- Make the search icon search over all tab categories (rent + free + archived..)
-> faster search of single plugins
- Show the technicalName in the license list table to make it "searchable" and or via CMD/STRG+F
-> Plugin Descriptions are different in store than in plugin composer.json -> always hard to find (especially with german/english translations)
- Add function to shopware-cli that you can update / migrate plugins from custom/plugins structure to composer.json
-> handy one command to select a list of plugins to update the latest version / migrate to composerThe current license list overview of the shop in the account.shopware.com is sadly not really handy for customers / agencies.
When updating to later Shopware Versions, you need mostly plugin updates to get back from a broken to a working state (e.g. 6.6 > 6.7, php bin/console fails as well):
- Therefore I have to go to said website, search for the plugin name (somehow over name / description mixed, because names are handled differently in the search)
- Then click on the plugin (when i finally found it) and get the update version.
- Another plugin must be found the same way…
2 votes -
Expand Flow Builder for Advanced B2B and Logistics Workflows
The current Flow Builder is a powerful automation tool, but it does not provide sufficient coverage for many real-world B2B and logistics processes.
Merchants often need to implement custom workarounds because important triggers and actions for fulfillment, warehouse operations, and B2B workflows are not available out of the box.
Examples of commonly requested capabilities include:
- Shipment Ready trigger
- Warehouse and fulfillment process triggers/actions
- B2B-specific workflow triggers/actions
- Automated status changes based on logistics events
- More granular control over order and delivery processes
A valuable enhancement would be to significantly expand the available Flow Builder triggers and actions to better support advanced operational workflows.
Key benefits include:
- Reducing the need for custom development and workarounds
- Enabling merchants to automate complex fulfillment and logistics processes
- Supporting more sophisticated B2B business requirements
- Increasing flexibility and scalability for growing merchants
A broader set of native triggers and actions would allow businesses to automate critical operational processes directly within Shopware and unlock the full potential of the Flow Builder for enterprise and B2B use cases.
The current Flow Builder is a powerful automation tool, but it does not provide sufficient coverage for many real-world B2B and logistics processes.
Merchants often need to implement custom workarounds because important triggers and actions for fulfillment, warehouse operations, and B2B workflows are not available out of the box.
Examples of commonly requested capabilities include:
- Shipment Ready trigger
- Warehouse and fulfillment process triggers/actions
- B2B-specific workflow triggers/actions
- Automated status changes based on logistics events
- More granular control over order and delivery processes
A valuable enhancement would be to significantly expand the available Flow Builder triggers and actions to better support advanced…
2 votes -
Automatic Country Restrictions Based on Manufacturer
Many merchants need to restrict the sale of specific brands or manufacturers in certain countries due to contractual, legal, or distribution agreements.
Currently, country restrictions must be assigned manually on a product-by-product basis. This becomes error-prone and difficult to maintain, especially for large product catalogs and when new products are added regularly.
A valuable enhancement would be the ability to define country restrictions at the manufacturer level and automatically apply them to all associated products.
Key benefits include:
- Automatically inheriting country restrictions for newly created products of a manufacturer
- Reducing manual maintenance and the risk of human error
- Ensuring compliance with brand-specific distribution agreements
- Improving scalability for merchants managing large product catalogs
This would provide a more efficient and reliable way to manage international sales restrictions while significantly reducing administrative effort.
Many merchants need to restrict the sale of specific brands or manufacturers in certain countries due to contractual, legal, or distribution agreements.
Currently, country restrictions must be assigned manually on a product-by-product basis. This becomes error-prone and difficult to maintain, especially for large product catalogs and when new products are added regularly.
A valuable enhancement would be the ability to define country restrictions at the manufacturer level and automatically apply them to all associated products.
Key benefits include:
- Automatically inheriting country restrictions for newly created products of a manufacturer
- Reducing manual maintenance and the risk of human error
- Ensuring compliance…
2 votes
- Don't see your idea?