Laudenz
28. Oktober 2026 um 13:39
1
Hallo zusammen, wenn man einen Produkt Export erstellt mit der Spalte „media“ ist diese leer. Normalerweise sollten da die Produktbilder URLs drin stehen mit „|“ als Trennzeichen. Aufgefallen ist uns das in Version 6.7.10.2.
Weiß jemand wie man das Problem beheben kann, damit die Produktbilder URLs wieder exportiert werden können?
Laut Doku sollte media für dieses Vorhaben verwendet werden. In Git haben wir ein Issue zu dem Thema gefunden, aber leider keine Lösung.
VG
Ich kann nur sagen, dass bei mir unter Shopware 6.7.14.0 im default_product-Export die Felder cover_media_id und cover_media_url korrekt gefüllt sind. Vielleicht einfach mal ein Update versuchen, falls möglich?
Laudenz
29. Oktober 2026 um 07:00
3
Hi @nextshops , danke für die Rückmeldung. Die Cover Spalten funktionieren in unserer Version auch. Könntest du vielleicht mal testen ob du einen Export der Spalte media bekommst? Darin sollten die URLs der Produktbilder sein (Cover ausgenommen).
VG
R4M
29. Oktober 2026 um 07:06
4
Habe es eben in SW 6.7.15.1 mit einem eigenen Export-Profil mal ausprobiert. Bei Spalte „media“ kommt gar nichts. Vielleicht muss man da noch mehr einstellen?
Laudenz
29. Oktober 2026 um 07:34
5
Ja genau, bei uns ist die Ausgabe auch leer.
So hat das in älteren Versionen auch funktioniert.
MrAle
29. Oktober 2026 um 09:16
6
Ich habe es auch getestet(6.7.15.0), so wie es aussieht wird die Media Association nicht geladen.
@Laudenz kannst du den Issue bitte mal linken den ihr gefunden hattet?
MrAle
29. Oktober 2026 um 09:27
7
Die Export-Funktion wird meinem Wissen nach komplett überarbeitet. Daher wird das vermutlich nicht weiter verfolgt.
Wie du hier siehst hat das auch anscheinend was mit Sicherheit, Zugriffsrechten, etc. zu tun und ist nicht nur ein Ein-Zeilen-Fix:
offen 09:04AM - 10 Feb 26 UTC
component/import-export
domain/crm-after-sales
### Problem we must solve
#### Context
The Import/Export feature continues to … exhibit architectural weaknesses that make certain bugs hard to fix sustainably. Although maintenance effort has decreased compared to last year due to resolving smaller issues, fundamental design limitations remain.
Additionally big parts of the implementation are considered part of our public API, making it difficult for us to do bigger changes to the implementation without waiting for major versions.
On a side note: The performance (especially import) is quite bad but can't be easily improved without introducing breaking changes.
Relates to https://shopware.atlassian.net/browse/FL-175
#### Technical issues that should be addressed
* Release cycle dependency: The one or two-year major release cadence prevents rapid iteration, as breaking changes can only be introduced in the next major version and much of the current implementation is considered public API, also preventing us from delivering improvements (e.g. related to performance).
* Performance limitations: Significant performance issues impact large data sets. Especially Imports take a very long time (e.g. 22 min. for 10k product CSV import measured in 2024 while export being a lot quicker than that)
* Data model and serialization issues:
* Many-to-many relations are handled inconsistently and are done on a per case basis
* Most of it comes down to the issue of compressing a tree of relational data into a flat structure (CSV) and uncompressing that again into a tree
* An alternative would be JSON, where it is much easier as it can fully represent the tree of objects. Right now we have no JSON import / export support other than talking to the admin API directly, which supports JSON.
* Another alternative would be treating import / export as multiple CSV files (e.g. one per DB table), that way there is no need to compress relational data into a flat structure but that introduces a big limitation to the use cases of import / export
* Several fields aren’t serialized at all, preventing correct export.
* Unsupported fields without proper serializers/deserializers can still be selected in profile settings, causing exports to fail.
* JSON fields (e.g., price fields) and their extensions cannot be partially updated — a limitation inherited from the DAL. Support in the DAL would be needed to fix this, tracking issue [shopware#5167](https://github.com/shopware/shopware/issues/5167)
* Translation handling differences between `DEFAULT` and `de-DE` if the latter is the default language [shopware#15341](https://github.com/shopware/shopware/issues/15341)
* Validation gaps: Profile mapping validation occurs only in the Admin UI; API-based imports/exports lack equivalent validation.
* Nitpick: The feature accumulated a lot of technical dept over the years and from the start (was build by external contractors and handed over): The codebase isn't up to our engineering quality standards with multiple huge files, complicated data flow, many hardcoded edge cases and in general hard to understand and reason about.
### WHY we need to solve it
- To raise the quality of this code base as well as the feature itself, making it more maintainable with fewer bugs / performance issues. => we spend less time on maintenance
- To add highly requested features, like filtering on export or different file formats, without increasing technical dept further
- To support more use cases our customers expect, instead of implementing hard coded solutions to the few use cases we are aware of
### Solution to the problem
TBD, we are still researching requirements
### WHO benefits
All merchants / developers that want to import / export data into / from shopware in the administration and potentially CLI.
### WHERE will we do it
core shopware repository
### Out of scope
TBD
### Acceptance criteria
TBD
### Definition of Done
- [ ] Fulfills all acceptance criteria defined during discovery.
- [ ] Integration/E2E testing in staging is done.
- [ ] All integration/E2E/unit tests passing; all critical or high-priority bugs are resolved.
- [ ] Fulfills compliance, performance, security, and cloud-readiness needs.
- [ ] Observability—includes monitoring, alerting, and logging; incident response handbooks updated.
- [ ] Documentation—developer docs are written or updated, including information on how the feature or change is adopted and tested. If new functionality, end user documentation is written or updated.
- [ ] (conditional) All new API endpoints have a defined API schema.
- [ ] (conditional) If the change affects the Storefront, it has been tested in the latest three versions of Firefox, Chrome, Edge, IE11, and Safari, as well as the different viewports and devices (Desktop / Tablet / Mobile).
- [ ] (conditional) If the change affects the Administration, it has been tested in current versions of Firefox, Chrome, and Edge.
- [ ] (conditional) Functionality that includes new API routes are callable via the Store-API (/store-api/[version]/).
- [ ] (conditional) If a new Admin module is created, the access control layer is provided, and permissions can be managed via the Users & Permissions module.
- [ ] (conditional) If a new UI input field or interactive element is introduced, the ACL wrapper is added.
- [ ] (conditional) Performance testing done if the change has a high performance impact, such as affecting scalability, load balancing, or query optimization.
Ich habe nur die Spalten:
id
MrAle
29. Oktober 2026 um 10:07
10
Ja, die Arbeit mit Import/Export muss man einstellen
zumindest bis das Epic fertig ist