- or
No existing idea results
- ~ No ideas found ~
1528 results found
-
Add user friendliness to new language handling
Since Shopware 6.7.3.0 the language pack displays a warning, that it's recommended not to use it and that it will not work with 6.8.x anymore. Unfortunately the deinstallation of the language pack removes all translations included there (test with 6.7.4.0, with selection "Remove all data it even throws an exception).
The dev docs recommend this way https://developer.shopware.com/docs/resources/references/upgrades/core/translation/language-pack-migration.html. But not every customer is feeling comfortable being forced to use the command line. It is intended to activate / deactivate a language via the language itself. So why don't you add an install / uninstall routine in settings > language to process bin/console translation:install --locales it-IT linked to the switch's setting? Perhaps in addition whether the snippets should be installed / uninstalled?Since Shopware 6.7.3.0 the language pack displays a warning, that it's recommended not to use it and that it will not work with 6.8.x anymore. Unfortunately the deinstallation of the language pack removes all translations included there (test with 6.7.4.0, with selection "Remove all data it even throws an exception).
The dev docs recommend this way https://developer.shopware.com/docs/resources/references/upgrades/core/translation/language-pack-migration.html. But not every customer is feeling comfortable being forced to use the command line. It is intended to activate / deactivate a language via the language itself. So why don't you add an install / uninstall routine in settings > language to…1 vote -
Optimizing the Guest Session: Seamless Transition to Registration During Checkout
If a guest visitor is in a guest session and goes through the checkout process up to the order confirmation page (/checkout/confirm), but then decides to create an account, they currently have to return to the shop (i.e., leave the checkout). However, there is no direct option to register there, as the guest session is still active and would need to be ended first.
An inexperienced user might not immediately realize this and, in the worst case, abandon the purchase.
Additionally, if a visitor in a guest session manually accesses the login page (/account/login), the registration form is displayed and can be submitted, but it is simply cleared because the guest session is still active.
It would be beneficial if visitors/customers were more prominently offered a way to reach the login page within the guest session, possibly combined with a notice that the guest session must be ended or by automatically terminating the guest session.
If a guest visitor is in a guest session and goes through the checkout process up to the order confirmation page (/checkout/confirm), but then decides to create an account, they currently have to return to the shop (i.e., leave the checkout). However, there is no direct option to register there, as the guest session is still active and would need to be ended first.
An inexperienced user might not immediately realize this and, in the worst case, abandon the purchase.
Additionally, if a visitor in a guest session manually accesses the login page (/account/login), the registration form is displayed and…
8 votes -
Settings > Log-in & sign-up: Add company name field required
Use Case: We have two sales channels (B2B and B2C) and could set this up in the B2B sales channel.
2 votes -
Native support of IndexNow
Whats this?
"IndexNow is an easy way for websites owners to instantly inform search engines and web crawlers used for information retrieval (“search engines”) about latest content changes on their website. In its simplest form, IndexNow is a simple ping so that search engines know that a URL and its content has been added, updated, or deleted, allowing search engines to quickly reflect this change in their search results."
Currently supports: Microsoft Bing, Naver, Seznam.cz, Yandex, YepWebsite: https://www.indexnow.org/index
4 votes -
Improve Safety and Flexibility for Promotion Code Configuration
Context
In the current version of Shopware 6, when creating a new promotion, the field “Promotion code type” is automatically set to “No promotion code required”.
This UX choice was made intentionally to simplify creation of general cart-level discounts, which are the most common use case.However, this default selection can lead to unintended activation of promotions when a user forgets to change the option to “Fixed” or “Individual promotion code.”
In such cases, discounts may be applied to all customers instead of a limited target group, which can cause serious financial and operational issues.Problem
Users may overlook that a promotion is configured without a code, because “No code required” is preselected
This can unintentionally trigger discounts for all customers
Currently, there is no system-level control or "safeguard" to prevent this
Proposed Solutions
We suggest adding configurability or safety mechanisms for the “Promotion code type” field to reduce user errors and increase administrative control.
There are three possible options that could be implemented independently or in combination:
Require explicit selection (no default preselection)
Remove the preselected value “No promotion code required.”System-wide default configuration
Add a configuration setting in system or admin preferences allowing administrators to define the default for new promotionsOptional warning before activation
Display a confirmation or warning when activating a promotion that has no promotion code set.
Example message:
“This promotion will be applied to all customers because no promotion code is required. Are you sure you want to activate it?”
Expected Benefits
Prevents accidental large-scale discount activations
Improves administrative control and safety
Reduces support incidents and potential financial losses
Aligns the promotion workflow with enterprise-level requirements
Context
In the current version of Shopware 6, when creating a new promotion, the field “Promotion code type” is automatically set to “No promotion code required”.
This UX choice was made intentionally to simplify creation of general cart-level discounts, which are the most common use case.However, this default selection can lead to unintended activation of promotions when a user forgets to change the option to “Fixed” or “Individual promotion code.”
In such cases, discounts may be applied to all customers instead of a limited target group, which can cause serious financial and operational issues.Problem
Users may overlook that…
1 vote -
Returns-Management: Dealing with multiple returns / partial cancellation per order
I can currently only create one return per order via the returns management. However, this means that if I have two partial returns per order (for which I create two separate partial cancellations), both returns are visible on the second partial cancellation. However, only the specified returned item should be visible for each partial cancellation.
3 votes -
Revision of list prices
The implementation of strikethrough prices has been poorly and even incompletely implemented. In the ITA shop, we don't have a proper way to display a sale category, as the default function here also goes to the first tab.
And independently, the in-house solution/rule for discounted items in the dynamic product groups is incredibly slow.
The host once sent me the Slow Query. If printed out, I could wallpaper at least half the room (high ceilings in an old Berlin building).
So please take a look at the topic. Anyone who has multiple sales channels and different prices within them will wish they were back in Shopware 5. It was all easy peasy and performant.
The implementation of strikethrough prices has been poorly and even incompletely implemented. In the ITA shop, we don't have a proper way to display a sale category, as the default function here also goes to the first tab.
And independently, the in-house solution/rule for discounted items in the dynamic product groups is incredibly slow.
The host once sent me the Slow Query. If printed out, I could wallpaper at least half the room (high ceilings in an old Berlin building).
So please take a look at the topic. Anyone who has multiple sales channels and different prices within them will…
2 votes -
Color recognition - Image Keyword Assistant
The Image Keyword Assistant should be able to recognize colors. This is particularly important for variant articles, where the same images are often used in a different color.
3 votes -
Add informal (Du) text snippets for German language
It would be useful to have an offical "Du"-Version of the de-DE snippets, either natively or through the language pack.
6 votes -
Add newsletter subscription checkbox on account registration
Add the ability to activate newsletter subscribe checkbox on the account registration (/account/login and /checkout/register). So a switch in the admin settings (probably Log-in & sign-up or Newsletter), when it's turned on, a checkbox in the registration pages appear to subscribe for the newsletter, just above the CTA.
7 votes -
Backend: Product Filtering and Customization - Filter Value
The product filters section needs more customization and can be optimized.
Here is an example of the main shortcomings:
1 - Allow the addition of custom fields and properties.
2 - Allow the use of operators such as: "Like," "=", "And," "Or," "Starts with," etc.
3 - Allow filtering by entering multiple values in a search field.8 votes -
Dynamic pricing or promotions based on affiliate code
Currently, Shopware does not allow evaluating the affiliate code via the rule builder prior to ordering or registering a new customer account, making it impossible to have affiliate-specific pricing or discounts based on those affiliate codes. This functionality should be added to the rule builder.
3 votes -
Data source/medium
To serve as a good replacement for GA4, it would be nice if there could be a report for oa source and medium. This would make it easier to see where the traffic is coming from.
If you can then combine all the reports, you can do nice analyses without using GA4.
2 votes -
Quotes: Shipping and payment
For offers, the shipping method and payment method used cannot be changed or edited. A shipping method and a payment method are still specified. It should be possible to change this data when editing.
Bei Angeboten kann die verwendete Versandart und die Zahlungsart nicht geändert oder bearbeitet werden. Deonnoch wid eine Versandart und eine Zahlungsmethode angegeben. Bei der Bearbeitung sollte die Möglichkeit bestehen diese Daten zu ändern.
4 votes -
Delivery time as Rule Builder condition
The Rule Builder is missing the option to use the delivery time of a product as a condition. This would be a useful improvement, for example to use this as an availability rule for shipping methods.
7 votes -
Logging of running flows
For monitoring the system and testing flows, it is extremely important that there is logging in the admin area.
The following information is important for logging:
- When did the flow run?
- Which trigger was activated?
- Which data was fed into the flow?
- Which data was decisive for the conditions?Zapier provides excellent logging for such systems.
2 votes -
"not specified" salutation handling
This is handled rather inconsistently in Shopware. In some but not all places, if you leave out the salutation, Shopware searches the database for the "not_specified" entry that comes with the installation and inserts it if found. If also sometimes inserts it just for display in the Administration if the real salutation reference is null, so you wouldn't even know the real value without looking directly into the database, but again, not always.
Crucially, that "not_specified" entry can be changed and deleted at will, so there's no guaranteed meaning behind it.
Also, sometimes like in the contact form the salutation is randomly required. You can delete it for addresses and the database has a default value of null, but then there is a non-configurable validator that won't let you through the checkout process if no salutation is given. And again, "given" can just mean that you set the "not_specified" salutation, which can have any meaning you assign to it.
This is an intransparent mess and should be changed. The very legality of requiring a salutation is now even in question. Just allow null values for all salutations in the application, it's already allowed in the DB structure, stop enforcing it in random places without a way to turn it off, and make the display name of a "null" salutation translatable via config.
This is handled rather inconsistently in Shopware. In some but not all places, if you leave out the salutation, Shopware searches the database for the "not_specified" entry that comes with the installation and inserts it if found. If also sometimes inserts it just for display in the Administration if the real salutation reference is null, so you wouldn't even know the real value without looking directly into the database, but again, not always.
Crucially, that "not_specified" entry can be changed and deleted at will, so there's no guaranteed meaning behind it.
Also, sometimes like in the contact form the salutation…
1 vote -
Hide empty entities in search results
Add an option that allows to hide empty entities in search results.
One example here would be manufacturers that are not being assigned to any products in the given sales channel.
2 votes -
Display order details clearly on one page instead of using tabs (similar to Shopware 6.4)
The details of an order should be clearly displayed on one page. Unfortunately, the details are currently spread across several tabs.
Clicking around, loading the various tabs and changing details takes longer than if everything could be done on one page.
Shopware 6.4 is clearer than Shopware 6.7.
Please change this.
1 vote -
Image keyword assistant multi-language support
It should be possible to generate the alt texts for multi-language shops in the respective language.
5 votes
- Don't see your idea?