Konfigurierbare Produkte in Magento 2: Varianten-Erzeugung und Performance

1. Wann Konfigurierbare Produkte die richtige Wahl sind

Konfigurierbare Produkte sind der Standardweg in Magento 2, ein Produkt in mehreren Varianten wie Groesse und Farbe anzubieten, wobei jede Variante ein eigenstaendiges Simple-Produkt mit eigener SKU, eigenem Lagerbestand und eigenem Preis bleibt. Der Kunde sieht auf der Produktdetailseite ein einziges Elternprodukt, waehlt ueber Dropdown oder Swatch die gewuenschte Kombination aus konfigurierenden Attributen, und Magento loest diese Auswahl serverseitig auf das passende Kindprodukt auf. Dieser Mechanismus unterscheidet sich fundamental vom Bundle-Produkt, bei dem mehrere unabhaengige Produkte zu einem Set zusammengestellt werden, und vom Grouped-Produkt, das lediglich eine Liste verwandter, aber eigenstaendig kaufbarer Produkte auf einer gemeinsamen Seite darstellt.

Der zentrale Unterschied zu Bundle und Grouped liegt in der Attributebene: Bundle-Optionen sind frei konfigurierbare Auswahlgruppen ohne EAV-Bezug zum Hauptprodukt, waehrend Konfigurierbare Produkte ueber echte Produktattribute wie color oder size gesteuert werden, die im Attribut-Set explizit als konfigurierend markiert sind. Das macht sie ideal fuer Faelle, in denen sich Varianten eindeutig ueber ein bis drei Attribute beschreiben lassen und jede Kombination als eigenstaendiges, lagerhaltiges Produkt existieren soll, etwa ein T-Shirt in fuenf Groessen und sechs Farben.

Nicht jede Variantenanforderung sollte jedoch ueber Konfigurierbare Produkte geloest werden. Sobald mehr als drei bis vier konfigurierende Attribute kombiniert werden oder die meisten Kombinationen selten real bestellt werden, etwa bei individuell zusammenstellbaren Moebeln mit Material, Stoff, Griff und Fussvariante, waechst die Zahl der Kindprodukte exponentiell und die Datenpflege wird unpraktikabel. In solchen Faellen sind Bundle-Produkte mit dynamischer Preisberechnung oder ein eigenes Custom-Options-Konzept oft die bessere Wahl, weil sie keine physische Kindprodukt-Entity pro Kombination erfordern.

2. Datenmodell: catalog_product_super_attribute, catalog_product_super_link

Technisch sind Konfigurierbare Produkte ein eigener Produkttyp mit dem Typ-Code configurable, der in der Tabelle catalog_product_entity als type_id des Elternprodukts hinterlegt ist. Das Elternprodukt selbst traegt keinen Preis und keinen Lagerbestand im eigentlichen Sinn, es fungiert als Container, der ueber zwei zentrale Tabellen mit seinen Kindprodukten verbunden wird. Die Tabelle catalog_product_super_attribute speichert, welche Attribute (per attribute_id) fuer ein bestimmtes Elternprodukt konfigurierend sind, waehrend catalog_product_super_link die eigentliche Eltern-Kind-Beziehung zwischen product_id (Parent) und parent_id (Child-Referenz) abbildet.

Jedes Kindprodukt ist ein vollwertiges Simple-Produkt mit eigenem Eintrag in catalog_product_entity_int, in dem der konkrete Wert des konfigurierenden Attributs (etwa die Options-ID von color=Rot) als EAV-Zeile gespeichert ist. Beim Laden der Produktdetailseite liest Magento ueber den Type-Instance-Mechanismus der Configurable-Klasse alle Kindprodukte aus, baut daraus die JSON-Konfiguration fuer das Frontend und ermittelt, welche Attributwert-Kombinationen ueberhaupt existieren. Diese Indirektion ueber EAV-Tabellen statt einer flachen Spalte ist der Grund, warum Konfigurierbare Produkte bei sehr vielen Kombinationen spuerbar mehr Joins und damit mehr Ladezeit im Admin-Grid erzeugen als reine Simple-Produkte.

Fuer PHP 8.4 Entwickler ist wichtig zu wissen, dass der programmatische Zugriff auf dieses Datenmodell nicht direkt ueber die Tabellen erfolgen sollte, sondern ueber Service Contracts wie ProductRepositoryInterface in Kombination mit den Extension Attributes configurable_product_options und configurable_product_links. Direkte SQL-Schreibzugriffe auf catalog_product_super_attribute umgehen Indexer-Trigger, Event-Observer und Cache-Invalidierung und fuehren zuverlaessig zu inkonsistenten Konfigurierbaren Produkten im Frontend.

3. Attribut-Set-Design: konfigurierende Attribute richtig waehlen

Nur Attribute vom Eingabetyp Dropdown oder Visual Swatch/Text Swatch koennen als konfigurierendes Attribut fuer Konfigurierbare Produkte genutzt werden, da Magento eine feste, endliche Werteliste (eav_attribute_option) braucht, um daraus die Kombinationsmatrix zu bilden. Freitextfelder, Mehrfachauswahlen oder Preistabellen scheiden von vornherein aus. Zusaetzlich muss das Attribut global scoped sein (kein website- oder store-spezifischer Wert), sonst ergeben sich pro Store unterschiedliche Konfigurationen, die Magento in der Verwaltung nicht sauber abbilden kann.

Die zweite Design-Entscheidung betrifft used_in_product_listing: Attribute, die in Kategorie- und Suchergebnisseiten fuer Filter oder Anzeige-Logik gebraucht werden, sollten auf diese Eigenschaft geprueft werden, weil sie sonst bei jedem Kategorie-Seitenaufruf zusaetzliche EAV-Joins in der Produktliste erzwingen, unabhaengig davon, ob das Attribut konfigurierend ist. In der Praxis bewaehrt sich, konfigurierende Attribute strikt von rein informativen Attributen zu trennen und nur die tatsaechlich kaufentscheidenden Merkmale (typischerweise Groesse und Farbe) als konfigurierend zu markieren.

Der praktische Richtwert lautet: nicht mehr als zwei, in Ausnahmefaellen drei konfigurierende Attribute pro Attribut-Set. Bei zwei Attributen mit je acht Werten entstehen maximal 64 Kombinationen, ein Wert, der sich noch gut pflegen und im Admin-Grid uebersichtlich darstellen laesst. Bei drei Attributen mit je acht Werten sind es bereits 512 theoretische Kombinationen, von denen in der Realitaet oft nur ein Bruchteil bestellbar ist. Jedes zusaetzliche konfigurierende Attribut multipliziert die Zahl der potenziellen Kindprodukte und damit den Pflegeaufwand, die Indexer-Last und die Groesse des JSON-Konfigurationsobjekts auf der Produktdetailseite.

4. Programmatische Varianten-Erzeugung im Detail

Fuer Shops mit mehreren hundert oder tausend Produktfamilien ist die manuelle Varianten-Erzeugung ueber den Admin-Wizard "Configurations" nicht praktikabel. Der belastbare Ansatz ist ein PHP-8.4-Service, der aus einer Attribut-Matrix (etwa Groesse x Farbe) sowohl die Simple-Kindprodukte als auch das konfigurierbare Elternprodukt in einem einzigen, transaktional sauberen Durchlauf erzeugt. Magento stellt dafuer die Factory Magento\ConfigurableProduct\Helper\Product\Options\Factory bereit, die aus einem Array von Attribut-Definitionen die passenden Extension-Attribute-Objekte fuer das Elternprodukt baut.

Im folgenden Beispiel wird Constructor Property Promotion konsequent genutzt, um Repository, Factory und Options-Factory als readonly-Properties zu deklarieren. Der Service nimmt bereits angelegte Kind-Produkt-IDs entgegen (diese werden zuvor ueber denselben ProductRepositoryInterface fuer jede Kombination aus der Matrix erzeugt) und verknuepft sie ueber die Extension Attributes configurable_product_options und configurable_product_links mit dem neuen Elternprodukt. Diese Trennung von Kind-Erzeugung und Verknuepfung erlaubt es, Fehler in einzelnen Kombinationen isoliert zu behandeln, ohne den gesamten Import abzubrechen.

<?php

declare(strict_types=1);

namespace Mironsoft\ConfigurableGenerator\Service;

use Magento\Catalog\Api\Data\ProductInterfaceFactory;
use Magento\Catalog\Api\ProductRepositoryInterface;
use Magento\ConfigurableProduct\Helper\Product\Options\Factory as OptionsFactory;
use Magento\ConfigurableProduct\Model\Product\Type\Configurable;
use Magento\Framework\Exception\CouldNotSaveException;
use Magento\Framework\Exception\NoSuchEntityException;

/**
 * Service for programmatic generation of a configurable product
 * including the full variation matrix from simple child products.
 */
final class VariationMatrixGenerator
{
    /**
     * @param ProductRepositoryInterface $productRepository read/write access to products
     * @param ProductInterfaceFactory $productFactory factory for new product entities
     * @param OptionsFactory $optionsFactory factory for configurable attribute options
     * @param Configurable $configurableType product type model for child product linking
     */
    public function __construct(
        private readonly ProductRepositoryInterface $productRepository,
        private readonly ProductInterfaceFactory $productFactory,
        private readonly OptionsFactory $optionsFactory,
        private readonly Configurable $configurableType,
    ) {
    }

    /**
     * Creates a configurable parent product covering all combinations
     * of the given configuring attributes and pre-created child products.
     *
     * @param string $parentSku SKU of the configurable parent to create
     * @param array<int, array{attribute_id:int, values:array<int, array{value_index:int}>}> $configurableAttributes
     * @param int[] $childProductIds already created simple product IDs, one per combination
     * @return void
     * @throws CouldNotSaveException when the parent product cannot be persisted
     * @throws NoSuchEntityException when the parent product cannot be reloaded after saving
     */
    public function generate(string $parentSku, array $configurableAttributes, array $childProductIds): void
    {
        $parent = $this->productFactory->create();
        $parent->setSku($parentSku);
        $parent->setTypeId(Configurable::TYPE_CODE);
        $parent->setAttributeSetId((int) $parent->getDefaultAttributeSetId());

        $configurableOptions = $this->optionsFactory->create($configurableAttributes);

        $extensionAttributes = $parent->getExtensionAttributes();
        $extensionAttributes->setConfigurableProductOptions($configurableOptions);
        $extensionAttributes->setConfigurableProductLinks($childProductIds);
        $parent->setExtensionAttributes($extensionAttributes);

        $this->productRepository->save($parent);
    }
}

5. Performance bei vielen Kombinationen: Indexer und EAV-Joins

Der Indexer catalog_product_attribute ist fuer Konfigurierbare Produkte besonders relevant, weil er bei jeder Aenderung an einem Kindprodukt (Preis, Sichtbarkeit, Attributwert) neu berechnen muss, welche Kombinationen im Frontend verfuegbar sind. In Shops mit 10.000 und mehr SKUs, bei denen viele Elternprodukte 20 bis 50 Kindprodukte besitzen, fuehrt jede Massenaenderung (etwa ein Preis-Import) zu einer erheblichen Zahl an betroffenen Zeilen in der MView-Changelog-Tabelle. Laeuft der Indexer im Modus "Update on Save", blockiert ein grosser Import den speichernden Prozess, bis alle abhaengigen Elternprodukte neu indexiert sind, was bei Cron-Jobs zu Timeouts fuehren kann.

Der Modus "Update by Schedule" entkoppelt diese Arbeit in eine asynchrone Consumer-Queue, die ueber Cron abgearbeitet wird. Bei sehr grossen Katalogen mit vielen Kindprodukten pro Elternprodukt empfiehlt sich zusaetzlich, die MView-Batch-Groesse (mview_grid_batch_size in der Konfiguration) zu erhoehen und die Anzahl paralleler Consumer-Prozesse fuer indexerProductAttribute zu steigern, damit die Queue nicht hinter den eingehenden Aenderungen zurueckfaellt. In der Praxis zeigt sich, dass Elternprodukte mit mehr als 80 bis 100 Kindprodukten den Reindex-Aufwand pro Produkt deutlich sichtbar erhoehen, weil jede EAV-Wert-Aufloesung pro Kind einzeln erfolgt.

Auch das Admin-Produkt-Grid leidet unter zu grossen Konfigurationen: Der Grid-Indexer muss fuer jedes Elternprodukt alle Kindprodukte auswerten, um Gesamtbestand und Preisspanne korrekt anzuzeigen. Bei Elternprodukten mit mehreren hundert Kindprodukten (etwa bei drei konfigurierenden Attributen mit hoher Kardinalitaet) wird das Laden der Produktliste im Backend spuerbar langsamer. Ein regelmaessiger Blick auf bin/magento indexer:status und die MView-Queue-Laenge gehoert bei Konfigurierbaren Produkten mit hoher Variantenzahl zum Standard-Monitoring.

# Status aller relevanten Indexer pruefen
bin/magento indexer:status

# Auf Schedule-Modus umstellen (empfohlen ab ca. 5.000 SKUs)
bin/magento indexer:set-mode schedule catalog_product_attribute
bin/magento indexer:set-mode schedule cataloginventory_stock
bin/magento indexer:set-mode schedule catalogsearch_fulltext

# Consumer fuer die Attribute-Indexer-Queue mit Message-Limit starten
bin/magento queue:consumers:start indexerProductAttribute --max-messages=5000

# Vollen Reindex nach einer grossen Attribut- oder Preisaenderung erzwingen
bin/magento indexer:reindex catalog_product_attribute

# Cron-Status pruefen, da geplante Indexer ueber den Cron laufen
bin/magento cron:run --group=index

6. Frontend-Performance: JSON-Config-Payload und Swatches

Auf der Produktdetailseite baut Magento fuer Konfigurierbare Produkte ein JSON-Konfigurationsobjekt, das fuer jede Attribut-Wert-Kombination die zugehoerige Kind-Produkt-ID, den Preis und die Bild-Referenz enthaelt. Bei zwei konfigurierenden Attributen mit ueberschaubarer Wertezahl bleibt dieses Objekt klein, meist wenige Kilobyte. Bei drei Attributen mit hoher Kardinalitaet oder mehreren hundert Kindprodukten kann das Payload jedoch auf mehrere hundert Kilobyte anwachsen, was direkt die Time-to-Interactive der Seite verschlechtert, weil der Browser das komplette Objekt parsen muss, bevor die erste Swatch-Auswahl reagiert.

Hyvä loest die Darstellung dieses Konfigurationsobjekts ohne jQuery und ohne Knockout.js, indem eine Alpine.js-Komponente das vom Server gerenderte JSON direkt als x-data-Initialwert uebernimmt. Die Aufloesung, welche Swatch-Kombination aktuell verfuegbar ist, geschieht dabei vollstaendig client-seitig ueber einen Index, den Magento im JSON mitliefert, sodass keine zusaetzlichen Requests fuer jede Auswahl noetig sind. Wichtig fuer die Performance ist, ausschliesslich die tatsaechlich benoetigten Felder (price, defaultPrice, images, index) in das Payload aufzunehmen und optionale Metadaten wie ausfuehrliche Attributbeschreibungen ueber Layout-XML aus der Konfiguration herauszunehmen, wenn sie im Frontend nicht dargestellt werden.

Bei sehr grossen Konfigurationen (mehr als 150 bis 200 Kindprodukte) lohnt sich ausserdem, das Rendering der Swatch-Buttons zu virtualisieren oder auf eine kombinierte Dropdown-Darstellung fuer das zweite Attribut umzusteigen, sobald das erste Attribut gewaehlt wurde. Dadurch muss Alpine.js nicht alle theoretischen Kombinationen gleichzeitig in den DOM rendern, sondern nur die nach der ersten Auswahl tatsaechlich relevante Teilmenge, was insbesondere auf mobilen Geraeten spuerbar schneller ist.

<?php
/** @var \Magento\ConfigurableProduct\Block\Product\View\Type\Configurable $block */
/** @var \Magento\Framework\Escaper $escaper */
$configObject = $block->getJsonConfig();
?>
<div x-data="initConfigurableProduct(<?= /* @noEscape */ $configObject ?>)" class="configurable-swatch-wrapper">
    <template x-for="attribute in Object.values(config.attributes)" :key="attribute.id">
        <div class="mb-4">
            <span class="font-semibold text-sm" x-text="attribute.label"></span>
            <div class="flex flex-wrap gap-2 mt-2">
                <template x-for="option in attribute.options" :key="option.id">
                    <button
                        type="button"
                        @click="selectOption(attribute.id, option.id)"
                        :disabled="!isSalable(attribute.id, option.id)"
                        :class="{ 'opacity-30 cursor-not-allowed': !isSalable(attribute.id, option.id), 'ring-2 ring-orange-600': isSelected(attribute.id, option.id) }"
                        class="border rounded px-3 py-1.5 text-sm"
                        x-text="option.label"
                    ></button>
                </template>
            </div>
        </div>
    </template>
</div>
<script>
    function initConfigurableProduct(config) {
        return {
            config: config,
            selected: {},
            selectOption(attributeId, optionId) { this.selected[attributeId] = optionId; },
            isSelected(attributeId, optionId) { return this.selected[attributeId] === optionId; },
            isSalable(attributeId, optionId) {
                return Object.values(this.config.index).some((product) => product[attributeId] === optionId);
            },
        };
    }
</script>
<?php /* @escapeNotVerified */ $hyvaCsp->registerInlineScript(); ?>

7. Caching-Strategien: Full Page Cache pro Elternprodukt

Der Full Page Cache speichert die Produktdetailseite eines konfigurierbaren Elternprodukts als eine einzige Cache-Entry, unabhaengig davon, wie viele Kindprodukte es besitzt. Das bedeutet, dass eine Preis- oder Bestandsaenderung an einem einzelnen Kindprodukt die gecachte Seite des Elternprodukts eigentlich veralten laesst, Magento aber standardmaessig nur die Cache-Tags des direkt geaenderten Produkts invalidiert. Ohne zusaetzliche Massnahme kann das dazu fuehren, dass ein Kunde auf einer gecachten PDP eine Variante als verfuegbar sieht, die gerade ausverkauft wurde.

Die robuste Loesung ist ein Plugin auf getIdentities(), das fuer Konfigurierbare Produkte zusaetzlich die Cache-Tags aller Kindprodukte in die Identities des Elternprodukts aufnimmt. Dadurch registriert Magento die FPC-Seite des Elternprodukts als abhaengig von jedem einzelnen Kind, und eine Aenderung an irgendeinem Kindprodukt loest die Invalidierung der Eltern-PDP korrekt aus. Diese Erweiterung sollte als eigenstaendiges Plugin in di.xml registriert werden, um die Kern-Logik von Magento\Catalog\Model\Product unveraendert zu lassen.

<?php

declare(strict_types=1);

namespace Mironsoft\ConfigurableCache\Plugin;

use Magento\Catalog\Api\Data\ProductInterface;
use Magento\ConfigurableProduct\Model\Product\Type\Configurable;

/**
 * Extends the cache identities of a configurable product with the
 * identities of all its child products, so FPC invalidation on the
 * parent PDP fires correctly when a child price or stock changes.
 */
final class AddChildProductCacheTagsPlugin
{
    /**
     * @param Configurable $configurableType product type model to load linked children
     */
    public function __construct(
        private readonly Configurable $configurableType,
    ) {
    }

    /**
     * Adds the cache tag of every child product to the parent's identities.
     *
     * @param ProductInterface $subject the configurable parent product
     * @param string[] $result cache tags resolved by Magento core
     * @return string[]
     */
    public function afterGetIdentities(ProductInterface $subject, array $result): array
    {
        if ($subject->getTypeId() !== Configurable::TYPE_CODE) {
            return $result;
        }

        $childIds = $this->configurableType->getChildrenIds($subject->getId())[0] ?? [];
        foreach ($childIds as $childId) {
            $result[] = ProductInterface::CACHE_TAG . '_' . $childId;
        }

        return array_unique($result);
    }
}

8. Lagerbestand und Salable Quantity je Variante

Seit Multi Source Inventory besitzt jedes Kindprodukt eines konfigurierbaren Elternprodukts seine eigene Salable Quantity pro Source und Stock, statt eines einzelnen globalen Bestandswerts. Das erlaubt praezise Aussagen wie: Groesse M in Rot ist an Lager A verkaufbar, an Lager B jedoch nicht, ohne dass sich das auf andere Groessen-Farbe-Kombinationen desselben Elternprodukts auswirkt. Fuer Konfigurierbare Produkte bedeutet das, dass die Verfuegbarkeitspruefung auf Ebene des Kindprodukts erfolgen muss, nicht auf Ebene des Elternprodukts, das selbst keinen eigenen Bestand fuehrt.

Im Frontend muessen ausverkaufte Kombinationen aus der Swatch- oder Dropdown-Auswahl entweder ausgeblendet oder deaktiviert werden, damit Kunden keine nicht bestellbare Variante waehlen koennen. Magento liefert dafuer den Index innerhalb des JSON-Konfigurationsobjekts, der pro Kind-Produkt-ID auch dessen Verfuegbarkeit beruecksichtigt. Fuer individuelle ViewModels, etwa um eine kompakte Lagerbestandsuebersicht im Admin oder eine eigene Verfuegbarkeitsanzeige zu bauen, ist die Kombination aus Configurable::getUsedProducts() und dem MSI-Service GetProductSalableQuantityInterface der empfohlene Weg, weil beide ueber Service Contracts stabil und versionssicher sind.

<?php

declare(strict_types=1);

namespace Mironsoft\ConfigurableStock\ViewModel;

use Magento\Catalog\Api\Data\ProductInterface;
use Magento\ConfigurableProduct\Model\Product\Type\Configurable;
use Magento\Framework\View\Element\Block\ArgumentInterface;
use Magento\InventorySalesApi\Api\GetProductSalableQuantityInterface;

/**
 * Determines for every child product of a configurable product whether
 * it is currently salable, so out-of-stock variants can be excluded
 * from the swatch or dropdown selection on the storefront.
 */
final class SalableVariantsViewModel implements ArgumentInterface
{
    /**
     * @param Configurable $configurableType product type model to load all child products
     * @param GetProductSalableQuantityInterface $getSalableQuantity MSI service for salable quantity per SKU and website
     */
    public function __construct(
        private readonly Configurable $configurableType,
        private readonly GetProductSalableQuantityInterface $getSalableQuantity,
    ) {
    }

    /**
     * Returns a map of SKU to salable quantity for all children of the given parent.
     *
     * @param ProductInterface $parent configurable parent product
     * @param int $websiteId website ID used as MSI context
     * @return array<string, float>
     */
    public function getSalableQuantities(ProductInterface $parent, int $websiteId): array
    {
        $result = [];
        foreach ($this->configurableType->getUsedProducts($parent) as $child) {
            $result[$child->getSku()] = $this->getSalableQuantity->execute($child->getSku(), $websiteId);
        }

        return $result;
    }
}

9. Konfigurierbare Produkte im Vergleich: Configurable vs. Bundle vs. Grouped

Alle drei Produkttypen loesen das Grundproblem "mehrere Produktvarianten unter einem Dach anbieten", aber mit fundamental unterschiedlicher Datenhaltung, Preislogik und Indexierungslast. Die folgende Tabelle fasst zusammen, wann Konfigurierbare Produkte gegenueber Bundle und Grouped die technisch passendere Wahl sind.

In der Praxis werden diese Produkttypen selten isoliert eingesetzt. Ein haeufiges Muster ist ein Konfigurierbares Produkt fuer Groesse und Farbe, dessen einzelne Kindprodukte wiederum als Bestandteil eines Bundle-Sets mit Zubehoer kombiniert werden. Entscheidend ist, bei der Datenmodellierung frueh zu klaeren, auf welcher Ebene die Preislogik greifen soll, da nachtraegliche Wechsel des Produkttyps in gewachsenen Katalogen mit Bestellhistorie technisch aufwendig und fehleranfaellig sind.

10. Zusammenfassung

Konfigurierbare Produkte loesen in Magento 2 ein klar umrissenes Problem: Varianten wie Groesse und Farbe als eigenstaendige, lagerhaltige Simple-Produkte unter einem gemeinsamen Elternprodukt zu buendeln. Das Datenmodell aus catalog_product_super_attribute und catalog_product_super_link ist dabei bewusst generisch gehalten, was Flexibilitaet bei der Attributwahl bringt, aber auch bedeutet, dass Performance-Aspekte wie Indexer-Last, JSON-Payload-Groesse und FPC-Invalidierung aktiv mitgedacht werden muessen, sobald die Zahl der Kombinationen waechst.

Der groesste Hebel liegt in der Disziplin beim Attribut-Set-Design: nicht mehr als zwei bis drei konfigurierende Attribute, programmatische Varianten-Erzeugung ueber Service Contracts statt manueller Admin-Pflege, und ein Monitoring von Indexer-Status sowie MView-Queue-Laenge ab mehreren tausend SKUs. Wer zusaetzlich Cache-Tags fuer Kindprodukte korrekt propagiert und Salable Quantity je Variante ueber MSI abfragt, vermeidet die typischen Symptome grosser konfigurierbarer Kataloge: langsame Admin-Grids, veraltete Preise im Full Page Cache und ausverkaufte Varianten, die faelschlich als verfuegbar angezeigt werden.

11. FAQ: Konfigurierbare Produkte in Magento 2