Eigene Produkttypen in Magento 2: wann sich das lohnt

Block 8 hat zwei fertige Magento-Konzepte - Zahlungs- und Versandarten - über eine eigene Implementierung erweitert. Block 9 geht einen Schritt weiter: Ein komplett neuer Produkttyp entsteht, den es in Magento vorher nicht gab. Business-Anlass: ein kaufbares "Punkte-Paket" - Kunden erwerben zusätzliche Treuepunkte direkt, statt sie nur über reguläre Einkäufe zu verdienen (Kapitel 30). Bevor Kapitel 72 mit der eigentlichen Registrierung beginnt, klärt dieses Kapitel zuerst die wichtigste Frage: Braucht es dafür wirklich einen neuen Produkttyp - oder tut es auch ein virtuelles Produkt mit einem Custom-Attribut?

Was ist ein Produkttyp technisch?

Jedes Magento-Produkt trägt in catalog_product_entity.type_id einen String - simple, virtual, downloadable, bundle, configurable, grouped im Kern. Dieser String ist der Schlüssel in etc/product_types.xml (Kapitel 72) und verweist dort auf eine PHP-Klasse (modelInstance), die \Magento\Catalog\Model\Product\Type\AbstractType erweitert und u. a. bestimmt: was beim Klick auf "In den Warenkorb" passiert (_prepareProduct()), welche Zusatzinformationen im Warenkorb und in der Bestellung erscheinen (getOrderOptions()) und über eine zweite Klasse (priceModel), wie der Preis berechnet wird. Kapitel 73 baut genau dieses Klassenpaar.

Die naheliegende Alternative: virtuelles Produkt mit Attribut

Der schnellere Weg läge auf der Hand: Punkte-Pakete einfach als ganz normale virtual-Produkte anlegen und ein neues Produkt-Attribut loyalty_points_package_amount ergänzen - technisch nur ein weiterer Aufruf von EavSetup::addAttribute(), exakt nach dem Muster aus Kapitel 19. Kein neuer Typ, kein Type-Model, kein Price-Model. Warum trotzdem nicht?

Achtung: Der entscheidende technische Grund heißt apply_to (Kapitel 74 baut darauf auf): Dieses EAV-Attributfeld lässt sich nur auf Ebene des Produkttyps sauber eingrenzen, nicht auf Ebene eines Custom-Attributs. Ein Pflichtfeld loyalty_points_package_amount mit apply_to => 'virtual' würde bei jedem virtuellen Produkt im Shop auftauchen und Pflichtfeld werden - Support-Tickets, E-Books, Gebühren-Positionen, alles, was heute schon als virtual läuft. Ein eigener Typ-Code wie loyalty_points_package lässt sich dagegen exakt und ausschließlich auf sich selbst beziehen.

Weitere Gründe für einen eigenen Typ

Robuste Prüfungen statt fragiler Attributwerte: Der Observer aus Kapitel 76 prüft $item->getProductType() === PointsPackage::TYPE_CODE - ein Vergleich, der nicht versehentlich falsch gesetzt oder vergessen werden kann, anders als ein Boolean-Attribut, das bei jedem neuen Produkt manuell richtig gepflegt werden müsste.
Automatische Layout-Auswahl: Magento hängt beim Rendern der Produktdetailseite automatisch den Layout-Handle catalog_product_view_type_<type_id> an - ein eigener Typ bekommt dadurch ohne Zusatzaufwand eine eigene Layout-Erweiterung (Kapitel 75), ein Attribut auf einem virtual-Produkt müsste das Template stattdessen bedingt per PHP verzweigen.
Eigene Beschriftung im Admin: "Punkte-Paket" erscheint als eigener Eintrag im "Neues Produkt"-Dropdown, statt dass Redakteure sich merken müssen, welches Häkchen ein virtuelles Produkt zum Punkte-Paket macht.
Saubere Segmentierung: Reports, Suchindex-Filter und spätere GraphQL-/REST-Abfragen (Block 10) können direkt nach type_id filtern, ohne den Umweg über ein Zusatzattribut.

Achtung: Reindex-Performance: Ein neuer Produkttyp ist für die Preis- und Attribut-Indexer (catalog_product_price, catalog_product_attribute) eine neue Dimension, die vorher schlicht nicht existierte. Der erste Lauf nach der Einführung sollte deshalb bewusst als vollständiger Reindex geplant werden (bin/magento indexer:reindex, nicht nur das nächste geplante Schedule-Update) - bei einem großen Katalog ein spürbarer Zeitfaktor, den man besser außerhalb der Stoßzeiten einplant statt live im Betrieb zu erleben.

Der Preis eines eigenen Typs

Zwei zusätzliche PHP-Klassen (Type-Model, Price-Model) plus deren Registrierung in product_types.xml - mehr bewegliche Teile als ein einzelnes Attribut.
Drittanbieter-Erweiterungen, die Produkttypen fest auf simple/virtual prüfen statt generisch mit Attributen oder Capability-Checks zu arbeiten, ignorieren einen neuen Typ klaglos - Kapitel 77 zeigt ein konkretes Beispiel.
Wer AbstractType erweitert, muss dessen Lebenszyklus (Warenkorb-Vorbereitung, Bestellpositions-Erzeugung, Preisberechnung) tatsächlich verstehen - kein reines Copy-paste-Attribut mehr.

Tipp: Faustregel für dieses Projekt und darüber hinaus: Reicht ein zusätzliches Attribut auf einem bestehenden Typ, um das Business-Konzept korrekt UND ohne Kollateralschäden an anderen Produkten desselben Typs abzubilden - Attribut nehmen (wie loyalty_points_multiplier in Kapitel 19). Lässt sich das Konzept dagegen nicht sauber eingrenzen, ohne alle Geschwister-Produkte desselben Typs mitzubetreffen - wie hier bei apply_to und "virtual" - ist ein eigener Typ die technisch ehrlichere Lösung, trotz des Mehraufwands.

Mit dieser Abwägung getroffen, registriert Kapitel 72 den neuen Typ-Code loyalty_points_package zum ersten Mal.