Produkttypen in Shopware 6.7: physical und digital
Das Feld product.type gibt es erst ab 6.7, es kennt genau zwei Werte — und es lässt sich nach dem Anlegen nicht mehr ändern.
Digitale Produkte gab es in Shopware auch vor 6.7. Neu ist, dass der Shop sie als solche kennt, statt sie aus den hinterlegten Downloads zu erschließen.
Das klingt nach einer Kleinigkeit und hat zwei Eigenschaften, die es nicht ist.
Was gemessen ist
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
Spalte product.type | existiert nicht | vorhanden |
| erlaubte Werte | — | physical, digital |
| Flags in 6.7 | — | ApiAware, Immutable, Choice |
| Flags unter dem 6.8-Schalter | — | zusätzlich Required |
altes Feld states | in Gebrauch | als deprecated markiert (v6.7.6.0 bis v6.8.0.0) |
Die erste Eigenschaft: unveränderlich
Das Feld trägt Immutable. Ein Produkt, das einmal als physical angelegt
wurde, bleibt physical — auch über die API, auch im Backend.
Das ist ungewöhnlich und in der Sache nachvollziehbar: Ein Produkttyp entscheidet über Versand, Lieferung und Downloadberechtigung. Ein nachträglicher Wechsel würde bestehende Bestellungen in einen Zustand versetzen, der beim Kauf nicht galt.
Für die Praxis heißt es: Ein falsch angelegtes Produkt lässt sich nicht korrigieren, nur ersetzen. Bei einem Produkt ist das lästig, bei einem fehlerhaften Import von tausend Produkten ist es ein Projekt.
Die zweite Eigenschaft: ab 6.8 Pflicht
In 6.7 ist das Feld optional und wird mit physical vorbelegt. Unter dem
Funktionsschalter für 6.8 trägt es zusätzlich Required.
Eine Schnittstelle, die heute Produkte anlegt, ohne den Typ mitzuschicken, funktioniert in 6.7 und scheitert in 6.8. Das ist eine der Änderungen, die man vor dem Sprung kennen will — und sie kostet heute fünf Minuten.
Wo der Typ tatsächlich wirkt
Im Kern von 6.7 entscheidet er an mehreren Stellen im Warenkorb, ob eine Position als Download behandelt wird — beim Umwandeln in eine Bestellposition, beim Laden der Downloads und in der Regelbedingung für Produkttypen im Rule Builder.
Damit ist auch klar, was er nicht tut: Er schaltet keine Funktion frei. Ein digitales Produkt braucht weiterhin hinterlegte Dateien; der Typ sagt nur, dass es eines ist.
Was wir in Projekten prüfen
- Legt eine Schnittstelle Produkte an? Dann gehört
typeab sofort in die Nutzlast — vor dem Sprung auf 6.8, nicht danach. - Gibt es digitale Produkte im Bestand? Nach dem Update auf 6.7 stehen sie
auf
physical, solange niemand sie neu anlegt. Der Typ wird nicht aus den vorhandenen Downloads erschlossen. - Hängt etwas am alten
states-Feld? Es ist deprecated und verschwindet. - Gibt es Regeln, die auf Produkttypen prüfen? Die Bedingung existiert und wird mit dem Feld erst sinnvoll.
Punkt 2 ist der, der überrascht. Das Update legt die Spalte an und füllt sie mit der Vorgabe — es sortiert den Bestand nicht.
Grenzen dieser Messung
Gelesen wurden die Felddefinition und die Stellen im Kern, an denen der Typ abgefragt wird. Nicht gemessen wurde, wie sich ein Bestandsshop nach einem echten Update verhält — insbesondere, ob eine Migration digitale Produkte erkennt und umstellt. Das ist eine eigene Prüfung mit echten Daten.
Ebenso wenig ist geprüft, wie sich eine laufende 6.8 verhält. Der Funktionsschalter ist im Quelltext von 6.7 sichtbar; mehr sagt diese Messung nicht.
Was ein Versionssprung sonst am Datenmodell tut, steht in Was ein Versionssprung an der Datenbank wirklich tut. Wenn eine Schnittstelle daran angepasst werden muss, gehört das zu Shopware-Agentur.
Häufige Fragen
- Welche Werte kennt product.type?
- Genau zwei: physical und digital. Die Auswahl ist im Datenmodell als Choice hinterlegt, andere Werte werden abgewiesen.
- Kann ich den Typ nachträglich ändern?
- Nein. Das Feld trägt das Flag Immutable. Ein Produkt, das als physical angelegt wurde, bleibt physical — der Weg zurück ist ein neues Produkt.
- Was ersetzt das Feld?
- Das Listenfeld states, das in 6.7 als deprecated markiert ist und mit 6.8 verschwindet. Vorher ergab sich der digitale Charakter eines Produkts aus den hinterlegten Downloads.
- Muss ich beim Anlegen etwas ändern?
- In 6.7 noch nicht — das Feld ist optional und wird mit physical vorbelegt. Unter dem 6.8-Schalter wird es Pflicht. Wer heute schon mitschickt, hat später nichts zu tun.