In short and in plain language
In fall 2026, Shopware changed the order confirmation three times. A new part is a note about the legal guarantee.
The new version only reaches shops that did not edit the template. If you changed the mail, you keep the old version.
This is true for all mail templates. Many other languages do not receive the new version at all, French for example.
So check after every update: What is new? What is missing in your mail? Then send yourself a test mail for each language.
Write down what you changed. Then the next check is faster.
On October 7, 2026, Shopware changed the order confirmation mail for the third time in four weeks with version 6.7.15.1 (Shopware release notes 6.7.15.1). The trigger is the legal guarantee label: first it was added to the mail, then it got fixed dimensions and a PNG instead of an SVG graphic, and finally its own template variable instead of a Twig filter. Shopware rolled out each of these changes through a migration, and each migration had the same condition: it only writes to templates that are still unedited. Anyone who had added a logo, bank details for prepayment or the withdrawal notice to the order confirmation received none of the three versions. This is not limited to the label. Every mail template that has been saved once is cut off from the core's mail migrations from that moment on. This article shows how Shopware detects an edited template, which templates are typically affected, how to compare your version against the shipped one after every update, what a test send per language and mail client reveals, and which mandatory contents belong in the routine as fixed checkpoints.
Key takeaways
- Shopware 6.7.14.0, 6.7.15.0 and 6.7.15.1 changed the order confirmation three times between September 9 and October 7, 2026 (Shopware release notes 6.7.14.0 to 6.7.15.1). Customized templates received none of these versions.
- The mail migrations only write to system templates whose template and translation carry no save date, and only for de-DE, en-GB and the system language (Shopware source code). Copies, extension templates and other languages are left out.
- Typically customized are the order confirmation, shipping and invoice mails, the payment reminder and the confirmation of a withdrawal. An inventory with type, language and save date shows which templates are cut off from the default.
- To compare, diff the shipped fixture files of the old and the new version and carry only the changed lines over into your own version, treating the HTML and plain text parts separately.
- The test send runs per language, sales channel and mail client with a real order on staging. Order receipt (§ 312i BGB), contract confirmation (§ 312f BGB), withdrawal notice and guarantee notice are fixed checkpoints.
- A change log with template, language, sales channel, default version and date shows at the next update which lines are your own customization and which have to be brought in from the default.
Three Versions, One Order Confirmation
It started with Shopware 6.7.14.0 on September 9, 2026 (Shopware release notes 6.7.14.0). The version introduced the EU-harmonized label for commercial guarantees of durability, called GARAN in Shopware, and a link to the harmonized notice on the legal guarantee. Shopware ships this notice translated into all 24 official EU languages (Shopware release notes 6.7.14.0). Both were added to the order confirmation template, but only where that template was still the unmodified system default: in new installations and in shops that had left it unchanged until then. According to the release notes, anyone who had customized the order confirmation was expected to add the two calls to their own template manually.
On October 1, 2026, 6.7.15.0 followed (Shopware release notes 6.7.15.0). In the first version, the label had been rendered without fixed dimensions in a full-width table row of its own, so mail clients scaled the graphic up to the width of the mail and cut it off. Now it carries width and height, sits in the line item's description cell and has a translated alt text. At the same time, Shopware switched from an SVG data URI to an embedded PNG, because according to the release notes Gmail and Outlook do not display the SVG version. This change, too, was applied by a migration only in shops whose template was unedited. Anyone who had already copied the 6.7.14.0 markup into their own template had to replace it a second time.
Six days later, on October 7, 2026, 6.7.15.1 arrived. The order confirmation now reads the label from the new template variable garanLabels, and the Twig filter sw_garan_label_mail from 6.7.15.0 is deprecated (Shopware release notes 6.7.15.1). The upgrade guide for Shopware 6.8 already lists it as removed (Shopware UPGRADE-6.8). A customized template that keeps calling the filter still works in 6.7. After the move to 6.8, Twig raises an error at that point because the filter is no longer registered. Shops on the older 6.6 branch received the embedded PNG with 6.6.10.28 on October 1 and the variable instead of the filter with 6.6.10.29 on October 7, 2026 (Shopware release notes 6.6.10.28, Shopware release notes 6.6.10.29).
| Version | Released | Change to the order confirmation | A customized template must |
|---|---|---|---|
| 6.7.14.0 | September 9, 2026 | GARAN label as SVG data URI, link to the guarantee notice | add both calls |
| 6.7.15.0 | October 1, 2026 | Label with fixed dimensions in the description cell, as embedded PNG | replace the label row, switch the filter |
| 6.7.15.1 | October 7, 2026 | Label from the garanLabels variable, filter deprecated | replace the filter call in HTML and plain text |
| 6.8 | announced | Filter sw_garan_label_mail removed | be switched over before the upgrade |
There is a fixed date behind this pace. Directive (EU) 2024/825 requires member states to apply their implementing provisions from September 27, 2026 (Directive (EU) 2024/825). In Germany, the obligation is set out in Art. 246a § 1 EGBGB: retailers inform consumers about the legal guarantee, including its minimum duration of two years, using the harmonized notice, and about a manufacturer's guarantee of durability of more than two years using the harmonized label (Art. 246a § 1 EGBGB). How the label is maintained on product pages, listings and the cart is covered in the article on the legal guarantee label in the shop. This article deals with the question behind it: why a change that Shopware ships does not arrive in a customized mail template.
How the Migration Detects an Edited Template
Shopware rolls out changes to shipped mail texts through migrations that share a common building block, the UpdateMailTrait. It loads the new version from the core's fixture files and writes it into the mail_template_translation table via SQL. Before that, it selects the rows it may overwrite: templates of the matching type that are flagged as system default and where neither the template itself nor the respective translation carries a save date (Shopware source code). A save date is set as soon as a change is saved through the administration or the API, both on the edited translation and on the template itself: the data abstraction layer sets the updated_at field on every write to an existing record (Shopware source code). The excerpt below is taken from version 6.7.15.1; on the 6.6 branch the query reads the same.
WHERE mail_template_translation.language_id IN (:ids)
AND mail_template_type.technical_name = :type
AND mail_template.system_default = 1
AND mail_template_translation.updated_at IS NULL
AND mail_template.updated_at IS NULLThese conditions lead to four cases that often overlap in a shop that has grown over time. First: saving a template in a single language, even if only a comma was changed, blocks it for all languages, because the save date is also set on the template itself. Second: a change written directly into the table via SQL without setting the save date counts as unedited and is overwritten by the next matching migration. Third: a copy, such as a second order confirmation for a B2B sales channel, is not a system default and receives no new version from these migrations. Fourth: the building block identifies languages by their locale. New English texts go to the system language and to languages with en-GB, new German texts to languages with de-DE (Shopware source code). A language with fr-FR, nl-NL, de-AT or de-CH that is not the system language receives nothing from these migrations, even if its template is unchanged.
The tricky state: one comma blocks every language
Which Templates Are Typically Customized
Shopware ships a whole range of mail templates, from registration through the order confirmation to the status mails for delivery and payment. Which of them is sent in which situation is set in the Flow Builder, and extensions can add further templates (Shopware documentation). What gets customized is usually not the whole list but the handful of mails that every customer sees and that money or rights depend on.
- Order confirmation: logo and colors, bank details for prepayment per payment method, terms and conditions and the withdrawal notice in the text, often also custom notes on delivery times. The documentation itself shows how to display bank details via the payment method ID (Shopware documentation).
- Shipping notification and delivery status mails: tracking number with a link to the carrier, notes on partial deliveries and returns.
- Invoice, credit note and cancellation invoice: cover texts for the documents, often with payment terms and bank details.
- Payment status, above all the reminder: a custom tone, custom deadlines, sometimes a link to pay again.
- Registration and double opt-in: welcome text, notes on the customer account, privacy notice.
- Withdrawal: for withdrawal requests, Shopware has dedicated template types for merchants and customers (Shopware source code); the receipt confirmation to the customer is a mandatory mail.
Two further groups are easy to miss in the inventory. The first are new system templates that an update brings along: 6.7.14.0, for example, added a template and flow for failed payments (Shopware release notes 6.7.14.0). It arrives in the Shopware default design, not in the shop's design, and then sits next to customized mails that look different. The second group are headers and footers. They are assigned per sales channel (Shopware documentation) and in many shops carry the company details and contact channels. If something changes there, it affects all mails of that channel at once.
Comparing Against the Shipped Template
The reference for every comparison lives in the core itself. For most mail templates, including the order confirmation, Shopware keeps the default version as a file, separated by language and format: de-html, de-plain, en-html and en-plain in the Migration/Fixtures/mails folder, for the order confirmation in the order_confirmation_mail subfolder. Some types, such as registration and its double opt-in, have no folder of their own there (Shopware source code); in that case, the template of a fresh installation of the same version serves as the reference. The release notes point to exactly these files when they suggest the new markup to customized shops (Shopware release notes 6.7.15.0). In a Composer installation, they are located under vendor/shopware/core.
The comparison runs in two directions. First, the question of what changed in the default: diffing the fixture file of the old version against the new one shows exactly the lines the update wanted to apply. Then, the question of how your own template deviates from it: diffing your own version against the new fixture file separates your own design from missing default content. Only the lines from the first comparison are carried over. Anyone who simply replaces their own template with the new default version loses bank details, notes and design.
# in a clone of the Shopware repository: what did the update change?
git diff v6.7.14.0 v6.7.15.1 -- \
src/Core/Migration/Fixtures/mails/order_confirmation_mail/
# your own version (exported as a file) against the new default
diff -u mail-export/order_confirmation_mail/de-html.html.twig \
vendor/shopware/core/Migration/Fixtures/mails/order_confirmation_mail/de-html.html.twigA read-only query is enough for the inventory. It lists per template and language whether the template is a system default and when template and translation were last saved. Every row with a date is a template that no core update reaches anymore. The same applies to every row with a locale other than de-DE and en-GB, unless the language is the system language.
SELECT t.technical_name,
m.system_default,
loc.code AS locale,
m.updated_at AS template_saved,
tr.updated_at AS translation_saved
FROM mail_template m
JOIN mail_template_type t ON t.id = m.mail_template_type_id
JOIN mail_template_translation tr ON tr.mail_template_id = m.id
JOIN language l ON l.id = tr.language_id
JOIN locale loc ON loc.id = l.locale_id
ORDER BY t.technical_name, loc.code;Test Send per Language, Channel and Mail Client
The comparison shows what should be in the template. Whether it reaches the customer only becomes clear when the mail is sent. For this, the administration offers a test send to any address and a preview in the editor (Shopware documentation). Since 6.7.11.0, the preview renders with the selected sales channel and its header and footer (Shopware release notes 6.7.11.0), and since 6.7.15.0 the MailService renders every mail with the snippets of its sales channel (Shopware release notes 6.7.15.0). For testing, this means: a test in the wrong channel shows the wrong texts.
Test mail and preview usually work with sample data. According to the release notes, however, Shopware only generates the label for products with a manufacturer and complete label data (Shopware release notes 6.7.14.0). Whether the line in your own template works therefore only shows with a real order on the staging environment, once with a product that carries this data and once without. How a staging environment for such tests is set up is described in the article on staging environments for safe updates.
Every mail consists of an HTML part and a plain text part. Under RFC 2046, these are two versions of the same information, and the mail client displays the one that fits (RFC 2046). The Shopware documentation recommends maintaining both versions because some mail providers do not allow HTML mails (Shopware documentation). A mandatory content item that only appears in the HTML part is therefore missing for some recipients. The instructions for 6.7.15.1 explicitly include the plain text version (Shopware release notes 6.7.15.1).
- every active language with its own test order, not just the main language
- every sales channel with its own header and footer
- HTML part and plain text part read separately
- one order with a label product, one without
- view in the mail clients your customers use, in webmail and on a phone
- images with remote loading blocked: alt text instead of an empty area
- sender name, reply-to address and subject per language
Whether the mail lands in the inbox at all is a separate check with its own tools. It is covered in the article on deliverability of shop mails.
Mandatory Contents as Fixed Checkpoints
The order confirmation is more than a courtesy. In electronic commerce, the retailer must confirm receipt of an order electronically without undue delay (§ 312i BGB). For distance contracts, the retailer must also confirm the contract on a durable medium within a reasonable period, at the latest on delivery, including the information under Art. 246a EGBGB, unless this information was already provided on a durable medium beforehand (§ 312f BGB). In many shops, the order confirmation covers both in one mail. Since 6.7.15.0, sending the order confirmation can be switched off when creating an order in the administration; the switch defaults to sending (Shopware release notes 6.7.15.0). This, too, is one of the points to look at deliberately once after an update.
The importance is clearest with withdrawal. The withdrawal period is 14 days (§ 355 BGB), but it does not begin before the retailer has properly informed the consumer about the right of withdrawal. Without this notice, the right of withdrawal expires at the latest twelve months and 14 days after the regular start of the period (§ 356 BGB). The information duty itself has grown: Art. 246a § 1 (2) EGBGB now also requires, where applicable, information on the existence and placement of the withdrawal function under § 356a BGB (Art. 246a § 1 EGBGB). A withdrawal notice that was copied into the order confirmation as text years ago should therefore be checked against the current version of the legal texts. How the withdrawal function itself is tested is described in the article on the withdrawal button in the shop.
The third mandatory item is new. Directive (EU) 2024/825 requires its implementing provisions to apply from September 27, 2026, and Art. 246a § 1 EGBGB in its current version requires the harmonized notice on the legal guarantee and, for a manufacturer's guarantee of durability of more than two years, the harmonized label (Art. 246a § 1 EGBGB). These are exactly the two elements Shopware added to the order confirmation. Eurostat shows that customers look for such information: 8 percent of online shoppers aged 16 to 74 in the EU reported for 2025 that they found it difficult to find information about the guarantee or other legal rights (Eurostat). Whether and where the notice and label have to appear in the mail is a matter for legal counsel. Maintenance checks after every update whether both are still where they belong.
| Checkpoint | Legal basis | Where it appears | Check after the update |
|---|---|---|---|
| Receipt confirmation of the order | § 312i BGB | Order confirmation | Mail triggered, including for orders created in the administration |
| Contract content and information under Art. 246a EGBGB | § 312f BGB | Order confirmation or attachment | Line items, prices, shipping costs and company details complete |
| Withdrawal notice with reference to the withdrawal function | § 356 BGB, Art. 246a § 1 EGBGB | Text or attachment | Version identical to the legal text page |
| Notice on the legal guarantee | Art. 246a § 1 EGBGB | Link or text | Link reachable, language matching |
| Label for the guarantee of durability | Art. 246a § 1 EGBGB | Line item row | Only for products with a manufacturer guarantee, visible as an image |
| Receipt confirmation of a withdrawal | § 356a BGB | Separate template | Content of the declaration, date and time included |
The Change Log: Who, When, Why
The save date in the database only says that a template was saved. It does not say what was changed, by whom, and which default version the change builds on. Yet that is exactly what you need when deciding at the next update which lines are your own design and which are merely missing default content. Without a log, every comparison starts with detective work.
- Template type, language and sales channel
- Default version the customization builds on, for example 6.7.15.1
- Reason for the change in one sentence, with a reference to the ticket or approval
- Date, editor and reviewer
- Result of the test send per language and mail client
- Storage location of the file version in the repository
The log becomes reliable when the templates are also kept as files in a repository, separated by type, language and format. Every change is then a traceable entry with a date, and the comparison with the fixture file runs with the same tools as any code diff. Anyone who has to show in a dispute which version of the order confirmation a customer received on a particular day finds it there with a date instead of reconstructing it from memory. Which legal texts are maintained in this context is described in the article on maintaining terms, withdrawal and pricing information. The templates themselves live in the shop database; including them in every backup is part of the backup service.
The Routine After Every Shopware Update
Comparison, testing and logging turn into a routine that runs the same way with every update, including patch versions. 6.7.15.1 was a patch version and still changed the order confirmation (Shopware release notes 6.7.15.1).
Read the update
Search the release notes and upgrade guide for mail, template, Twig and the type names of your own templates, and do the same with the changelogs of installed extensions.
Compare
Run the inventory query, diff the fixture files of the old and new version, carry changed lines over into your own versions, HTML and plain text separately.
Test send
On staging, trigger an order per language and sales channel with and without a label product, and read it in several mail clients and as plain text.
Log
Record the default version, the change, the reviewer and the test result, store the file version and flag open points for legal counsel.
Search the release notes and upgrade guide for mail, template, Twig and the type names of your own templates, and do the same with the changelogs of installed extensions.
Run the inventory query, diff the fixture files of the old and new version, carry changed lines over into your own versions, HTML and plain text separately.
On staging, trigger an order per language and sales channel with and without a label product, and read it in several mail clients and as plain text.
Record the default version, the change, the reviewer and the test result, store the file version and flag open points for legal counsel.
The routine belongs before the update is released to the live system, as part of the regression tests after updates. A template that is only noticed after go-live has already confirmed orders by then. Before a move to Shopware 6.8, one more step is added: search all templates for filters and variables that the upgrade guide lists as removed, because there a deprecation no longer applies, an error does. How the mail check fits into the overall update strategy for Shopware is described in the article on that topic.
What Maintenance Takes Over for Mail Templates
Maintaining customized mail templates is detail work that rarely belongs to anyone: the agency designed the template once, the hosting provider installs updates, legal counsel supplies texts. In our Shopware maintenance, changelog analysis and a staging test come before every update; comparing the mail templates can be added there as a checkpoint of its own, including for the security updates, which can also change templates as patch versions.
Inventory
Record all templates with type, language, sales channel and save date, including copies and extension templates.
Release check
Check the release notes and upgrade guide of every update for changes to mails, templates and Twig filters.
Fixture diff
Compare the old and new default version and carry changed lines over into your own version in a targeted way.
Test send
Send per language and sales channel on staging, and read HTML and plain text in several mail clients.
Mandatory items
Tick off receipt confirmation, contract information, withdrawal and guarantee notice after every update.
Log
Record the default version, change and test result and store the file version under version control.
How much effort this means depends on the number of languages, sales channels and customized templates. Which factors drive the overall maintenance effort is shown in the article on shop maintenance cost drivers. An overview of the services is available under services, response times and scope in the SLA maintenance contract. If you would like your template inventory reviewed first, you can reach us via the contact page.
Sources
Related Articles
Shopware Updates: Safe Deployment
Plan and deploy Shopware updates safely: staging environment, regression testing, rollback plans and plugin compatibility for live operations.
WordPress 7.2 in December: Updating in Peak Season
WordPress 7.2 is scheduled for 8 December, right in the Christmas peak. How to check auto-updates, test the beta on staging and plan through to January.
Moving Shop Servers Without Losing Orders: A Runbook
Resolvers may keep serving stale DNS answers for 1 to 3 days. How a shop moves servers without losing orders, cron jobs or payment notifications.