119 results found

1. 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 environment

   This 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… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  In-App Purchases  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Gathering 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.

2. Whitelist-Based Cache Key Handling for URL Parameters

   Currently, Shopware allows excluding certain URL parameters from the cache key to save storage. However, this exclusion list keeps growing, making maintenance cumbersome. Instead of excluding parameters, a whitelist approach could offer more control and efficiency.

   Analysis:

   I tracked URL parameters in a default Shopware installation—from listing to PDP, filtering, and placing an order. These 19 parameters were captured (more possible):
   cluster, keys, language, limit, locale, manufacturer, max-price, min-price, no-aggregations, order, orderId, p, paid, properties, rating, redirected, slots, timezone, search

   Instead of maintaining an ever-growing exclusion list, switching to an allowlist approach would ensure that only essential parameters impact the cache key.

   Proposed Solution:

   • Allowlist Configuration – Define a clear set of parameters that should be part of the cache key instead of excluding specific ones.
   • Event for developers – Introduce an event to allow developers to modify the allowlist dynamically.
   • Control by config – Provide a config option to adjust the allowlist as needed.

   This approach simplifies maintenance, optimizes cache storage, and ensures that only relevant parameters affect cache variations. 🚀

   https://github.com/shopware/shopware/blob/d8e5f78c01ed7c349993d116e37611ac3494ad05/src/Core/Framework/Resources/config/packages/shopware.yaml#L19

   Currently, Shopware allows excluding certain URL parameters from the cache key to save storage. However, this exclusion list keeps growing, making maintenance cumbersome. Instead of excluding parameters, a whitelist approach could offer more control and efficiency.

   Analysis:

   I tracked URL parameters in a default Shopware installation—from listing to PDP, filtering, and placing an order. These 19 parameters were captured (more possible):
   cluster, keys, language, limit, locale, manufacturer, max-price, min-price, no-aggregations, order, orderId, p, paid, properties, rating, redirected, slots, timezone, search

   Instead of maintaining an ever-growing exclusion list, switching to an allowlist approach would ensure that only essential parameters impact the… more

   4 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   Declined  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Not enough interest

   
   

   We’re closing this idea because it has not received significant interest or activity over the past 12 months. This helps us keep the idea portal focused on the topics that are most relevant to our community.

   
   

   Thank you for taking the time to submit and support it. We’ll continue to monitor customer needs and may reconsider the topic if interest grows in the future.

3. Filter visibility by selected sales channels

   For products, there is an option to set visibility for selected sales channels.
   
   This setting determines whether a product appears in search results or in the product listing.
   
   However, to see what is set for a product here, you have to open the product page and then click the settings button again.

   It would be nice to have an option right here in the product overview to filter by visibility settings.

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Gathering 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.

4. Migration: Automatic placeholders for missing values

   Customer migrations are tedious and involve a lot of work, as data records are often not transferred to Shopware 6 because they are missing from Shopware 5.

   For example, if the salutation of a customer is not filled in Shopware 5, but the field has become a mandatory field in Shopware 6. Or the first name.

   To make migrations much easier, the migration wizard should store a meaningful placeholder in such cases so that the data is transferred correctly.

   Within Shopware 6, you can then search for these placeholders and adjust the entries. This takes away the frustration that many customers experience during a migration.

   Customer migrations are tedious and involve a lot of work, as data records are often not transferred to Shopware 6 because they are missing from Shopware 5.

   For example, if the salutation of a customer is not filled in Shopware 5, but the field has become a mandatory field in Shopware 6. Or the first name.

   To make migrations much easier, the migration wizard should store a meaningful placeholder in such cases so that the data is transferred correctly.

   Within Shopware 6, you can then search for these placeholders and adjust the entries. This takes away the frustration that many… more

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Migration & Im-/Export  ·  Delete…  ·  Admin →
   Declined  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Not enough interest

   
   

   We’re closing this idea because it has not received significant interest or activity over the past 12 months. This helps us keep the idea portal focused on the topics that are most relevant to our community.

   
   

   Thank you for taking the time to submit and support it. We’ll continue to monitor customer needs and may reconsider the topic if interest grows in the future.

5. Product visibility options in dynamic product group

   EN
   If a product’s visibility is set to ‘Hide in product lists and search’, the product will not be displayed in the storefront. If a dynamic product group is to be used for a product comparison or product export that includes these products, then
   - the shop operator has no way of querying the product visibility settings
   - the products are exported in a feed and are therefore visible (externally) after all.

   DE
   
   Wenn in einem Produkt die Produktsichtbarkeit auf in Produklisten und Suche ausblenden gestellt ist, werden die Produkt in der Storefront entsprechend nicht angezeigt. Wenn eine Dynamische Produktgruppe für einen Produktvergleicht / Produktexport genutzt werden soll, in dem diese Produkte enthalten sind, dann
   - gibt es für den Shopbetreiber keine Möglichkeit die Optionen der Produktsichtbarkeit abzufragen
   - die Produkte werden in einem Feed exportiert und somit dann doch (extern) sichtbar.

   EN
   If a product’s visibility is set to ‘Hide in product lists and search’, the product will not be displayed in the storefront. If a dynamic product group is to be used for a product comparison or product export that includes these products, then
   - the shop operator has no way of querying the product visibility settings
   - the products are exported in a feed and are therefore visible (externally) after all.

   DE
   
   Wenn in einem Produkt die Produktsichtbarkeit auf in Produklisten und Suche ausblenden gestellt ist, werden die Produkt in der Storefront entsprechend nicht angezeigt. Wenn eine Dynamische… more

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

6. B2B Suite - Make orders more visual

   Already placed orders should be able to be filtered by products as well. A list of all products that also shows the product with a picture makes repeat ordering easier than having to search for the desired product from an old order.

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Declined  ·  0 comments  ·  B2B  ·  Delete…  ·  Admin →

7. More possibilities for SEO

   The basic approach and usability are quite good, but it fails in details that have a big impact:
   - Files are made visible along with ID in the URLs, this provides dead links when files are updated. We provide datasheets that are kept up to date. Currently we have 2,000 dead links and had to have the URL adjusted ourselves.
   - With reference to point 1: There is no tool for redirects.
   - The ID issue also exists with images.
   - The image files are too large due to the zoom on the product detail page, unless you use webp as the format.
   - The technical SEO still has a lot of play: pages in different languages are often not recognized as separate pages, load times are too large, etc.
   - Canonical tags are not always recognized by search engines
   - You can't deindex pages in the backend (e.g. notepad, shopping cart, or pages behind the login), this must always be done via htaccess. Here, however, usually only the agency has access
   - Not all pages of the store can be accessed and managed, e.g. notepad.
   - URLs for products are taken over on the basis of the name, but should be written exclusively in lower case.
   - A blog is still on the roadmap

   The basic approach and usability are quite good, but it fails in details that have a big impact:
   - Files are made visible along with ID in the URLs, this provides dead links when files are updated. We provide datasheets that are kept up to date. Currently we have 2,000 dead links and had to have the URL adjusted ourselves.
   - With reference to point 1: There is no tool for redirects.
   - The ID issue also exists with images.
   - The image files are too large due to the zoom on the product detail page, unless you use webp… more

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  SEO  ·  Delete…  ·  Admin →
   Declined  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Not enough interest

   
   

   We’re closing this idea because it has not received significant interest or activity over the past 12 months. This helps us keep the idea portal focused on the topics that are most relevant to our community.

   
   

   Thank you for taking the time to submit and support it. We’ll continue to monitor customer needs and may reconsider the topic if interest grows in the future.

8. New rules for rule builder based on products searches and sold

   Permit to use the rule builder to define a dynamic group of products based on the YTD sold or on the most searched products. This will help creating Cross-Sell and Up-sell dynamic groups with the most interesting products automatically

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
   Declined  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Not enough interest

   
   

   We’re closing this idea because it has not received significant interest or activity over the past 12 months. This helps us keep the idea portal focused on the topics that are most relevant to our community.

   
   

   Thank you for taking the time to submit and support it. We’ll continue to monitor customer needs and may reconsider the topic if interest grows in the future.

9. Change product detail page layout for more than 25 items

   EN
   
   If a separate layout has been designed for some products, for example because these products have a special property for which there should be an explanation, then I can select the products under Content > Experience worlds > Layout assignment > Assign layout. However, the selection list is limited to 25 elements. To do this, we have added a filter to filter the selection for additional products. However, this only works as long as the search terms are different.

   If I have 80 products with, for example, ‘variant’ in the name, I can only select 25, after which further products could only be selected if there was another unique criteria with which further products could be selected. The only other alternative is to select each product individually and then change the layout manually.

   It is not possible to link the products to the layout via a dynamic product group and it is also not possible to set a new layout in the additional change.

   DE
   
   Wenn für einige Produkte ein eigenes Layout entworfen wurde, beispielsweise weil diese Produkte eine spezielle Eigenschaft haben, zur der es eine Erläuterung geben soll, dann kann ich unter Inhalte > Erlebniswelten > Layout-Zuweisung > Layout zuweisen die Produkte auswählen. Jedoch ist die Auswahlliste auf 25 Elemente beschränkt. Dafür haben wir den Filter eingebaut, mit dem die Auswahl auf weitere Produkte gefiltert wird. Das funktioniert aber nur so lange, wie die Suchbegriffe unterschiedlich ausfallen.

   Haben ich 80 Produkte mit zum Beispiel "Variante" im Namen kann ich nur 25 auswählen, danach gingen weitere nur noch, wenn es ein weiteres eindeutiges Kriterium gäbe, mit dem weitere Produkte ausgewählt werden können. Die einzige andere Alternative jedes Produkt einzeln auszuwählen und dann das Layout manuell zu ändern.

   Es ist nicht möglich die Produkte über eine Dynamische Produktgruppe mit dem Layout zu verbinden und auch in der Mehränderung kann kein neues Layout gesetzt werden.

   EN
   
   If a separate layout has been designed for some products, for example because these products have a special property for which there should be an explanation, then I can select the products under Content > Experience worlds > Layout assignment > Assign layout. However, the selection list is limited to 25 elements. To do this, we have added a filter to filter the selection for additional products. However, this only works as long as the search terms are different.

   If I have 80 products with, for example, ‘variant’ in the name, I can only select 25, after which… more

   4 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  User Experience  ·  Delete…  ·  Admin →
   Declined  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Not enough interest

   
   

   We’re closing this idea because it has not received significant interest or activity over the past 12 months. This helps us keep the idea portal focused on the topics that are most relevant to our community.

   
   

   Thank you for taking the time to submit and support it. We’ll continue to monitor customer needs and may reconsider the topic if interest grows in the future.

10. I am trying to customize SEO URL slugs and encountered an issue

    When I use variable meta-title in the url template, it works only for main products, not for variants, even if there is meta title inheritance enabled. But even when I check html of the variant page, meta title is not there. I don't know if you made it on purpose or it is a bug, but it means: I cannot use meta title variable for variants when creating a url.

    This lead to my other thought: let's turn Use single canonical URL for all variants - because of course we do not want google to mark it as duplicates when we are using inheritance for all the descriptions and stuff. But when I turn it on, you force me to pick one of the variants. But I don't logically want it to be one of the variants, i want it to be main product. That leads me to another problem that I tried to solve with you: main product cant have the same product number as variant. So I cannot create variant as main product - so I cannot use it as main product for canonical URL. BUT! I think you would tell me: change storefront presentation, lets go to Product-Variants-Storefront presentation-Product lsitings and instead of Main product you could pick one variant and go with it. But I don't want to do it, because if I choose it as "Main product" in the storefront it is more beneficial since it shows, that there are more variants and price starts at.... You know what I mean? I don't want the specific size of the product be as main variant, you actually told me not to, since you require variant and main product to have different product number.

    This is actually really frustrating. Because I want it (as it should be):
    - main product - main URL - it is main product page that I want to be crawled by search engines
    - variants - url with whatever slug added to the main product URL, but I don't want Google to crawl it.
    Sounds pretty easy, right? And it even works like that, just not in case if I want to use MetaTitle as a slug.

    You give me these:
    - main product - main URL (i want to use meta title for that and you allow it since it is in the list of supported variants)
    - variant - can't use meta title - it makes it different url, which is ugly and not practical
    - seo canonical - can use only variant, not meta title, so basically I have many duplicate pages and it takes us down from Google.

    When I use variable meta-title in the url template, it works only for main products, not for variants, even if there is meta title inheritance enabled. But even when I check html of the variant page, meta title is not there. I don't know if you made it on purpose or it is a bug, but it means: I cannot use meta title variable for variants when creating a url.

    This lead to my other thought: let's turn Use single canonical URL for all variants - because of course we do not want google to mark it as duplicates when… more

    5 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  SEO  ·  Delete…  ·  Admin →
    Declined  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Not enough interest

    
    

    We’re closing this idea because it has not received significant interest or activity over the past 12 months. This helps us keep the idea portal focused on the topics that are most relevant to our community.

    
    

    Thank you for taking the time to submit and support it. We’ll continue to monitor customer needs and may reconsider the topic if interest grows in the future.

11. Kundenspezifische Preise im admin / Customer specific pricing in admin

    DE:

    Kundenspezifische Preise sollte in Kunden > Übersicht > Kunde > neuer Reiter > Kundenspezifische Preise
    einsehbar sein.

    Felder:

    Suchfeld, welches nach Name und SKU suchen kann

    SKU | Produktname | Nettopreis | Bruttopreis

    Docu
    https://docs.shopware.com/de/shopware-6-de/erweiterungen/kundenspezifische-preise

    Hinweis: es geht um die Preise die per API bei der Beyond Edition eingespielt werden und nicht B2B component individual-pricing
    https://docs.shopware.com/en/shopware-6-en/commercial-features/b2b-components?category=shopware-6-en/features/commercial#individual-pricing

    EN:

    Customer-specific prices should be visible under Customers > Overview > Customer > New Tab > Customer-specific prices.

    Fields:

    Search field (searching by name and SKU)

    SKU | Product Name | Net Price | Gross Price

    Documentation
    https://docs.shopware.com/en/shopware-6-en/extensions/customer-specific-pricing

    Note: This refers to the prices imported via API for the Beyond Edition, not the B2B component for individual pricing.
    https://docs.shopware.com/en/shopware-6-en/commercial-features/b2b-components?category=shopware-6-en/features/commercial#individual-pricing

    DE:

    Kundenspezifische Preise sollte in Kunden > Übersicht > Kunde > neuer Reiter > Kundenspezifische Preise
    einsehbar sein.

    Felder:

    Suchfeld, welches nach Name und SKU suchen kann

    SKU | Produktname | Nettopreis | Bruttopreis

    Docu
    https://docs.shopware.com/de/shopware-6-de/erweiterungen/kundenspezifische-preise

    Hinweis: es geht um die Preise die per API bei der Beyond Edition eingespielt werden und nicht B2B component individual-pricing
    https://docs.shopware.com/en/shopware-6-en/commercial-features/b2b-components?category=shopware-6-en/features/commercial#individual-pricing

    EN:

    Customer-specific prices should be visible under Customers > Overview > Customer > New Tab > Customer-specific prices.

    Fields:

    Search field (searching by name and SKU)

    SKU | Product Name | Net Price | Gross Price

    Documentation
    https://docs.shopware.com/en/shopware-6-en/extensions/customer-specific-pricing

    Note: This refers… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Zusätzliche Spalte und Kommentarfeld bei SW6 Backend Bestellungen I Additional column and comment field for SW6 backend orders

    Aktuell steht bei SW6 Backend Bestellungen nur ein Feld, mit Dropdown Menü für die Suche nach Artikelnummer oder Artikelname zur Verfügung. Oder die leere Positionszeile.

    In SW5 gab es bei Backendbestellungen je eine Spalte für Artikelnummer und eine für Artikelname, Preis, Steuer, etc. Man konnte die Artikelnummer verwenden, den Artikelnamen, Preis, Steuer etc. bearbeiten und die Bestellung mit den überschriebenen Daten anlegen. Damit war alles geregelt und konnte sauber an Kunden, Lager, etc. übergeben werden.

    Diese weitere Spalte bei den Backend Bestellungen fehlt in SW6. Damit hat man nicht mehr beide Felder zur Verfügung und kann keine Änderungen mehr vornehmen, da die Datenbank dann scheinbar nach einem nichtvorhandenen Eintrag sucht und die Eingabe nicht abgeschlossen werden kann.

    Gibt es dafür eine Lösung?

    Ebenfalls fehlt in dieser Ebene der Backend Bestellung noch ein Kommentarfeld, z.B. für Kundeninterne Nummern, Export-Angaben, etc… In SW5 gab es dafür die Freitextfelder.

    Das Kommentarfeld steht erst im nächsten Schritt zur Verfügung. Um dahin zu gelangen, muss man die Bestellung speichern, woraufhin jedoch schon die Bestellbestätigung versendet wird. Auf der man eben gern noch ein paar Angaben gemacht hätte, bevor sie zum Kunden gesendet wird.

    Gibt es dafür eine Lösung?

    ---

    There is currently only one field available for SW6 backend orders, with a dropdown menu for searching by article number or article name. Or the empty item line.

    In SW5 there was one column for article number and one for article name, price, tax, etc. for backend orders. You could use the article number, edit the article name, price, tax etc. and create the order with the overwritten data. This meant that everything was organised and could be transferred cleanly to customers, warehouses, etc.

    This additional column in the backend orders is missing in SW6. This means that you no longer have both fields available and can no longer make any changes, as the database then appears to search for a non-existent entry and the entry cannot be finalised.

    Is there a solution for this?

    A comment field is also missing at this level of the backend order, e.g. for internal customer numbers, export details, etc... In SW5 there were free text fields for this purpose.

    The comment field is only available in the next step. To get there, you have to save the order, after which the order confirmation is sent. You would like to have entered a few more details before it is sent to the customer.

    Is there a solution for this?

    Aktuell steht bei SW6 Backend Bestellungen nur ein Feld, mit Dropdown Menü für die Suche nach Artikelnummer oder Artikelname zur Verfügung. Oder die leere Positionszeile.

    In SW5 gab es bei Backendbestellungen je eine Spalte für Artikelnummer und eine für Artikelname, Preis, Steuer, etc. Man konnte die Artikelnummer verwenden, den Artikelnamen, Preis, Steuer etc. bearbeiten und die Bestellung mit den überschriebenen Daten anlegen. Damit war alles geregelt und konnte sauber an Kunden, Lager, etc. übergeben werden.

    Diese weitere Spalte bei den Backend Bestellungen fehlt in SW6. Damit hat man nicht mehr beide Felder zur Verfügung und kann keine Änderungen mehr vornehmen,… more

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
    Declined  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Not enough interest

    
    

    We’re closing this idea because it has not received significant interest or activity over the past 12 months. This helps us keep the idea portal focused on the topics that are most relevant to our community.

    
    

    Thank you for taking the time to submit and support it. We’ll continue to monitor customer needs and may reconsider the topic if interest grows in the future.

13. Retail Media Capabilities

    Challenge/Problem:
    What is Retail Media: https://www.criteo.com/blog/wtf-is-retail-media-guide/

    Selling paid content within a shop. Currently, it would involve a lot of custom & manual effort to create & maintain paid content in SW6.

    Possible Constraints for retail media:
    * Different methods how to defining prices such as KPI based (by CR, by Traffic, by Clicks, etc.) or fixed prices
    * Time limitation of active content (fixed period, max. number of Klicks/CR/Traffic, etc.)
    * Legal requirements (paid content and product position must be clearly indicated as an advertisement)
    * Integration of third-party system
    * Integration of external admin users (e.g. paid influencer who writes a blogpost and pushes it to SW6)

    Possible use cases for retail media:
    * Teaser and Banner (PLP, PDP, Homepage, Navigation, Blogposts, LPs)
    * Paid rankings (Search, search results, PLP sorting, Recos)
    * Paid blog posts
    * Paid brand category pages
    * Paid LPs

    Solution/Approach:
    Some sort of management for marketing to create, maintain and automate paid content within admin.

    Target Group:
    Beyond
    Retail media requires a certain size and reach of an online shop within its industry in order to be attractive for brands so that their paid content would lead to significant higher sales of their products in the corresponding onlineshop.

    Challenge/Problem:
    What is Retail Media: https://www.criteo.com/blog/wtf-is-retail-media-guide/

    Selling paid content within a shop. Currently, it would involve a lot of custom & manual effort to create & maintain paid content in SW6.

    Possible Constraints for retail media:
    * Different methods how to defining prices such as KPI based (by CR, by Traffic, by Clicks, etc.) or fixed prices
    * Time limitation of active content (fixed period, max. number of Klicks/CR/Traffic, etc.)
    * Legal requirements (paid content and product position must be clearly indicated as an advertisement)
    * Integration of third-party system
    * Integration of external admin users (e.g. paid influencer who… more

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Content management  ·  Delete…  ·  Admin →
    Declined  ·  Jonas Fuchs responded

    Thank you for sharing this idea with us and for your patience while it’s been on the portal. After reviewing it again, we’ve decided not to move forward—There is not enough interest. Please keep the feedback coming; your insights continue to shape what we build next!

14. Use Categories en Gender form category tree in filters

    If you organize your categories by gender in Shopware, you have a clear gender-specific funnel with clear and structured navigation. Why aren't these also used in the filters, or why do you have the option to do so?

    Applying all filters via attributes doesn't work well. Especially not on the brands page, where you don't have good SEO-friendly pages based on brand/category. If we enable categories and genders in the filters, we only see the male gender for unisex products when filtering for women, whereas you don't want to see men at all when you are in the women's funnel. And if we enable categories, we see duplicate categories for all genders on the brands page (deduplication is not possible). If you then click on "sneaker," for example, you don't know which gender you are going to.

    For complex websites, let users choose for themselves what they want to link to the attributes (filters). The standard category tree seems best to me in that case.

    Also, make categories, brands, and quicklinks dynamic. So if there are no active products from the brand or category, automatically disable them for the front-end (including the quicklink).

    The brand page could also be much better in the default settings: navigate by brand by gender, meta titles and meta descriptions, search field in navigation.

    If you organize your categories by gender in Shopware, you have a clear gender-specific funnel with clear and structured navigation. Why aren't these also used in the filters, or why do you have the option to do so?

    Applying all filters via attributes doesn't work well. Especially not on the brands page, where you don't have good SEO-friendly pages based on brand/category. If we enable categories and genders in the filters, we only see the male gender for unisex products when filtering for women, whereas you don't want to see men at all when you are in the women's funnel.… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering 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.

15. Standardize shortName for Categories to ensure App and Headless stability

    Shopware provides a shortName for SalesChannels to enable environment-agnostic identification, yet this primitive is missing for Categories. This inconsistency forces App developers and Headless integrators to rely on volatile SEO URLs or environment-specific UUIDs to identify "Page Types" (e.g., Home, Support, Landing Page).

    By extending shortName to the Category entity, Shopware would provide a stable, indexed, and semantic developer contract. This eliminates the need for redundant repository searches or brittle Custom Field lookups, which currently penalize performance and complicate CI/CD pipelines. Standardizing this across core entities ensures that external systems can resolve both "Shop Context" and "Location Context" using the same native logic, drastically simplifying the integration of marketing, tracking, and CMS-driven Apps.

    Shopware provides a shortName for SalesChannels to enable environment-agnostic identification, yet this primitive is missing for Categories. This inconsistency forces App developers and Headless integrators to rely on volatile SEO URLs or environment-specific UUIDs to identify "Page Types" (e.g., Home, Support, Landing Page).

    By extending shortName to the Category entity, Shopware would provide a stable, indexed, and semantic developer contract. This eliminates the need for redundant repository searches or brittle Custom Field lookups, which currently penalize performance and complicate CI/CD pipelines. Standardizing this across core entities ensures that external systems can resolve both "Shop Context" and "Location Context" using… more

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  App System  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering 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.

16. 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… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering 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.

17. Optimization of plugin management and configuration in Shopware 6 Admin

    We are having difficulties finding and managing the apps and plugins installed in Shopware 6 within the admin area. Since many standard features from SW5 have been removed and must now be replaced by apps, there is no central overview for these extensions. The apps are spread out across different sections, without a clear indication of which plugin provides which functionality. This leads to issues with managing and identifying extensions.

    Note from Shopware Support:
    We think it's a very good idea. For many colleagues in support, it is often very difficult to find out which plugin inserts which functions and where these are configured.

    Main Issues:

    Scattered Apps: Apps are spread out across various sections of the admin area (e.g., Marketing, System, Settings), making them difficult to find.

    No Clear Function Assignment: After installation, it is often unclear which plugin is responsible for which function. Only after disabling a plugin does it become apparent what it was doing.

    Challenges with CMS Plugins: With multiple CMS plugins active at the same time, it’s almost impossible to figure out which plugin is being used in which Shopping Experience without manually testing each one.

    Shopify Example:
    We find that Shopify has a clear structure where all apps are centrally located under one "Apps" section, with direct access to configuration, making it super easy to manage.

    Use Cases for Clarification:

    1 - Finding an App:
    If i want to configure a recently installed plugin. However, it is scattered across the admin area (e.g., partly under Marketing, partly under System), and there is no central overview. The user wastes time searching for the app.

    Use Case 2 - Unclear Function Assignment:
    As a shop owner, i noticed a functionality in our shop (e.g., "Products in saved shopping carts" under Marketing) but does not know whether it’s part of the core system or added by a plugin. Suggestion: Clearly indicate which function is provided by which plugin.

    Wanted improvements:

    Introduce a central "Plugin" section where all installed extensions are listed and can be configured.

    Clearly label in the admin area which functions belong to which plugins. Maybe with an Icon and text on hover.

    Improve the identification of CMS plugins within Shopping Experiences.

    We are having difficulties finding and managing the apps and plugins installed in Shopware 6 within the admin area. Since many standard features from SW5 have been removed and must now be replaced by apps, there is no central overview for these extensions. The apps are spread out across different sections, without a clear indication of which plugin provides which functionality. This leads to issues with managing and identifying extensions.

    Note from Shopware Support:
    We think it's a very good idea. For many colleagues in support, it is often very difficult to find out which plugin inserts which functions and… more

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
    Declined  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Not enough interest

    
    

    We’re closing this idea because it has not received significant interest or activity over the past 12 months. This helps us keep the idea portal focused on the topics that are most relevant to our community.

    
    

    Thank you for taking the time to submit and support it. We’ll continue to monitor customer needs and may reconsider the topic if interest grows in the future.

18. 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 first

    • I 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/12547

    Thank 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… more

    •  

    •  

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. "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… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Content management  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering 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.