1. Was das Attribut im Shop leisten soll

Ein Custom Product Attribute Magento 2 ist in vielen Projekten der richtige Einstieg, wenn Produktdaten nicht mehr nur Name, Preis und Beschreibung sind. Typische Beispiele sind Pflegehinweise, Versandbesonderheiten, technische Kennwerte, Nachhaltigkeitsmerkmale, Produktsiegel oder interaktive Datenbausteine, die im Frontend nicht nur als Textzeile, sondern als eigenes Widget erscheinen sollen.

Genau hier trennt sich eine schnelle Datenablage von einer guten Shop-Implementierung. Wenn das Attribut nur im Backend existiert, aber im Frontend unstrukturiert in einem langen Datenblock endet, wird sein Nutzen begrenzt. Ein gutes Custom Product Attribute Magento 2 verbindet EAV-Pflege mit einer klaren Ausgabeform. Das Attribut muss im Admin verständlich gepflegt werden können und im Frontend so erscheinen, dass Nutzer einen echten Mehrwert daraus ziehen.

Für dieses Tutorial nehmen wir ein Attribut delivery_badge. Es soll pro Produkt einen kleinen Hinweis wie „Kühlversand“, „24h Versand“ oder „Vorbestellung“ steuern und im Frontend als visuelles Widget oberhalb der Produktdetails erscheinen. Das Beispiel ist bewusst greifbar: Es zeigt, wie aus einem EAV-Feld eine echte Frontend-Komponente wird.

2. Produktattribut sauber anlegen

Ein Custom Product Attribute Magento 2 wird typischerweise über einen Data Patch angelegt. Das ist heute der saubere Weg, weil das Modul damit reproduzierbar und upgradefähig bleibt. Wichtig ist, die Attributdefinition nicht nur minimal anzulegen, sondern bewusst zu entscheiden: Datentyp, Eingabetyp, Scope, Sichtbarkeit, Verwendbarkeit in Grids, Suchbarkeit, Filterbarkeit und Frontend-Relevanz.

Für ein Badge-Attribut ist ein Select-Attribut oft sinnvoller als freier Text. Damit kann der Admin nur definierte Werte wählen, und das Frontend-Widget erhält stabilere Zustände. Freitext klingt zunächst flexibler, macht aber CSS-Zustände, Übersetzungen und UI-Konsistenz schwieriger. Genau an solchen Stellen zeigt sich, dass ein gutes Custom Product Attribute Magento 2 mehr ist als nur ein zusätzliches Feld.

<?php
declare(strict_types=1);

namespace Mironsoft\ProductBadge\Setup\Patch\Data;

use Magento\Catalog\Model\Product;
use Magento\Eav\Model\Entity\Attribute\ScopedAttributeInterface;
use Magento\Eav\Setup\EavSetupFactory;
use Magento\Framework\Setup\ModuleDataSetupInterface;
use Magento\Framework\Setup\Patch\DataPatchInterface;

/**
 * Adds the delivery badge product attribute.
 */
final class AddDeliveryBadgeAttribute implements DataPatchInterface
{
    public function __construct(
        private readonly ModuleDataSetupInterface $moduleDataSetup,
        private readonly EavSetupFactory $eavSetupFactory
    ) {}

    public function apply(): self
    {
        $eavSetup = $this->eavSetupFactory->create(['setup' => $this->moduleDataSetup]);

        $eavSetup->addAttribute(
            Product::ENTITY,
            'delivery_badge',
            [
                'type' => 'int',
                'label' => 'Delivery Badge',
                'input' => 'select',
                'source' => \Mironsoft\ProductBadge\Model\Config\Source\DeliveryBadge::class,
                'required' => false,
                'visible' => true,
                'user_defined' => true,
                'global' => ScopedAttributeInterface::SCOPE_STORE,
                'group' => 'General',
                'used_in_product_listing' => true,
                'visible_on_front' => false
            ]
        );

        return $this;
    }

    public static function getDependencies(): array
    {
        return [];
    }

    public function getAliases(): array
    {
        return [];
    }
}

Die Option used_in_product_listing ist wichtig, wenn das Attribut später in Produktlisten oder Teasern gebraucht wird. Ohne solche Entscheidungen früh mitzudenken, landet man bei einem Attribut, das nur auf PDPs funktioniert, aber nicht in Kategorieseiten oder in Headless-Listings verfügbar ist. Ein gutes Custom Product Attribute Magento 2 wird deshalb nicht nur für den ersten Screen, sondern für seinen ganzen Datenweg geplant.

3. Admin-Pflege und EAV-Einordnung

Damit das Attribut im Alltag wirklich nutzbar ist, muss die Admin-Pflege klar sein. Wer ein Custom Product Attribute Magento 2 anlegt, sollte nicht nur an die technische Existenz denken, sondern an den Redaktionsfluss. Ist der Feldname eindeutig? Passt die Attributgruppe? Ist klar, welche Auswahl welchen Frontend-Effekt auslöst? Sind Store-Views relevant? Diese Fragen entscheiden, ob das Feld später sauber gepflegt wird oder zur Fehlerquelle wird.

Gerade bei Select-Attributen lohnt sich eine saubere Source-Model-Klasse. So bleiben verfügbare Zustände kontrolliert, wiederverwendbar und gut lesbar. Wenn später neue Zustände hinzukommen, lässt sich die Logik im Frontend gezielt erweitern. Das ist deutlich robuster, als beliebige Freitextwerte als CSS-Klassen oder UI-Varianten zu missbrauchen.

<?php
declare(strict_types=1);

namespace Mironsoft\ProductBadge\Model\Config\Source;

use Magento\Eav\Model\Entity\Attribute\Source\AbstractSource;

/**
 * Provides delivery badge options for the product attribute.
 */
final class DeliveryBadge extends AbstractSource
{
    public function getAllOptions(): array
    {
        return [
            ['label' => __('-- Please Select --'), 'value' => ''],
            ['label' => __('24h Shipping'), 'value' => 1],
            ['label' => __('Preorder'), 'value' => 2],
            ['label' => __('Cold Shipping'), 'value' => 3]
        ];
    }
}

Aus EAV-Sicht ist dieses Attribut weiterhin nur eine Produktinformation. Der Unterschied entsteht erst dadurch, was das Frontend später damit macht. Genau deshalb ist das Thema Custom Product Attribute Magento 2 spannend: Das Attributmodell bleibt standardnah, während die Ausgabe projektspezifisch wird.

4. Frontend-Ausgabe mit Layout XML und ViewModel

Die Ausgabe sollte im Hyvä-Kontext nicht über unstrukturierte Direktzugriffe im Template erfolgen, sondern über Layout XML und ein ViewModel. Das ist der saubere Weg, um ein Custom Product Attribute Magento 2 stabil in die Produktseite einzubinden. Das ViewModel kann den aktuellen Produktkontext lesen, den Attributwert interpretieren und dem Template eine klarere Datenstruktur liefern.

Der große Vorteil ist, dass das Template nicht mit Magento-EAV-Details belastet wird. Statt direkt Werte und Labels zusammenzubasteln, bekommt die Ansicht genau das, was sie rendern soll: Badge-Text, Badge-Key, Aktiv-Zustand und vielleicht einen Hilfetext. So bleibt die Template-Schicht sauber und die spätere Erweiterung einfacher.

<?xml version="1.0"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <referenceContainer name="product.info.main">
            <block class="Magento\Framework\View\Element\Template"
                   name="mironsoft.product.delivery.badge"
                   template="Mironsoft_ProductBadge::product/delivery-badge.phtml"
                   before="-">
                <arguments>
                    <argument name="view_model" xsi:type="object">Mironsoft\ProductBadge\ViewModel\DeliveryBadge</argument>
                </arguments>
            </block>
        </referenceContainer>
    </body>
</page>

<?php
declare(strict_types=1);

namespace Mironsoft\ProductBadge\ViewModel;

use Magento\Framework\Registry;
use Magento\Framework\View\Element\Block\ArgumentInterface;

/**
 * Provides delivery badge data for the product page widget.
 */
final class DeliveryBadge implements ArgumentInterface
{
    public function __construct(
        private readonly Registry $registry
    ) {}

    /**
     * Returns normalized badge data for the current product.
     *
     * @return array<string, string>|null
     */
    public function getBadgeData(): ?array
    {
        $product = $this->registry->registry('current_product');

        if (!$product) {
            return null;
        }

        $value = (int) $product->getData('delivery_badge');

        return match ($value) {
            1 => ['key' => 'fast', 'label' => '24h Shipping'],
            2 => ['key' => 'preorder', 'label' => 'Preorder'],
            3 => ['key' => 'cold', 'label' => 'Cold Shipping'],
            default => null,
        };
    }
}

Damit wird das Attribut nicht einfach nur angezeigt, sondern in eine bewusst interpretierte UI-Datenstruktur überführt. Genau das ist häufig der Unterschied zwischen einem Feld und einem echten Widget. Ein gutes Custom Product Attribute Magento 2 trennt Datenhaltung und Darstellung klar.

5. Eigenes Frontend-Widget im Hyvä-Kontext

Jetzt kommt der eigentliche Mehrwert: die Widget-Ausgabe. Das Template sollte nicht wie ein generischer Datensalat wirken, sondern eine kleine, eigenständige Komponente rendern. Im Hyvä-Kontext bedeutet das: schlanke Templates, Tailwind-Klassen direkt im Markup und bei Bedarf Alpine.js für zusätzliche Interaktivität. Für unser Badge genügt eine visuelle Ausgabe ohne zusätzliches JavaScript.

Wichtig ist, dass das Widget fachlich zum Attribut passt. Ein Lieferhinweis-Attribut ist nicht einfach ein zusätzlicher Bulletpoint. Es ist eine hervorstechende Information, die den Kaufentscheid beeinflussen kann. Deshalb gehört es an eine sichtbare Stelle auf der Produktseite. Genau das rechtfertigt, dass aus einem Custom Product Attribute Magento 2 ein echtes Frontend-Widget wird.

<?php
declare(strict_types=1);

use Magento\Framework\Escaper;
use Magento\Framework\View\Element\Template;
use Mironsoft\ProductBadge\ViewModel\DeliveryBadge;

/**
 * @var Template $block
 * @var Escaper $escaper
 * @var DeliveryBadge $viewModel
 */
$viewModel = $block->getData('view_model');
$badge = $viewModel ? $viewModel->getBadgeData() : null;
?>

<?php if ($badge): ?>
    <div class="mb-4">
        <div class="inline-flex items-center gap-2 rounded-md border border-lime-200 bg-lime-50 px-3 py-2 text-sm font-semibold text-lime-900">
            <span class="inline-block h-2.5 w-2.5 rounded-full bg-lime-500"></span>
            <span><?= $escaper->escapeHtml($badge['label']) ?></span>
        </div>
    </div>
<?php endif; ?>

Dieses Beispiel ist bewusst leicht gehalten, aber die Struktur trägt auch komplexere Widgets. Du könntest Farben, Icons, Tooltip-Texte oder zusätzliche Zustandslogik hinzufügen. Du könntest das Badge in Listings wiederverwenden, sofern das Attribut im Listing geladen wird. Entscheidend ist, dass das Widget nicht nur ein Design-Element ist, sondern aus einem klar gepflegten Datenpunkt hervorgeht.

Gerade im Hyvä-Umfeld lohnt sich diese Sauberkeit doppelt. Ein Custom Product Attribute Magento 2 mit ViewModel und klarer Template-Struktur lässt sich leichter erweitern, testen und in andere PDP-Bereiche verschieben als eine spontane Inline-Ausgabe mitten in einer bestehenden PHTML-Datei.

6. Typische Fehler

Der häufigste Fehler ist, das Attribut korrekt anzulegen, aber die Frontend-Ausgabe unstrukturiert zu bauen. Dann hängt der Wert irgendwo zwischen anderen Produktinfos oder wird direkt per getData() an mehreren Stellen aus Templates gelesen. Das ist wartbar nur so lange, bis das Attribut mehr als eine einzige Darstellungsform braucht.

Ein weiterer Fehler ist die falsche Attributart. Viele Teams greifen reflexhaft zu Textfeldern, obwohl Select-Optionen die bessere Wahl wären. Dadurch verlieren sie Konsistenz in Datenpflege und Frontend-Varianten. Auch falsches Scope-Verhalten ist problematisch: Wenn ein Badge je Store variieren soll, muss das Attribut store-spezifisch geplant sein. Wenn es global sein soll, erzeugt ein unnötiger Store-Scope nur redaktionelle Verwirrung.

Ebenso oft wird vergessen, dass ein Custom Product Attribute Magento 2 im Listing oder in APIs andere Ladepfade hat als auf der Produktseite. Nur weil das Attribut im PDP verfügbar ist, heißt das nicht automatisch, dass es auch in Produktlisten, REST oder GraphQL sauber mitkommt. Wer diese Pfade früh mitdenkt, spart sich spätere Flickarbeit.

7. Attributtext vs. echtes Widget

Nicht jedes Attribut braucht ein Widget. Manche Produktinformationen sind als schlichte Zeile oder Tab-Inhalt völlig ausreichend. Die Entscheidung hängt davon ab, ob das Attribut kaufentscheidend, visuell hervorgehoben oder interaktiv sein soll. Genau deshalb ist ein direkter Vergleich sinnvoll.

Der richtige Weg ist also nicht automatisch „mehr Widget“. Der richtige Weg ist eine Ausgabeform, die dem Attribut gerecht wird. Wenn das Attribut eine echte Kauf- oder Nutzungsrelevanz hat, ist ein Widget oft sinnvoll. Wenn es nur ergänzende Metadaten sind, reicht häufig eine einfache Darstellung.

9. Zusammenfassung

Ein Custom Product Attribute Magento 2 entfaltet seinen Wert erst dann vollständig, wenn EAV-Setup, Admin-Pflege und Frontend-Ausgabe zusammen gedacht werden. Das Attribut selbst ist nur die Datenbasis. Der eigentliche Mehrwert entsteht über eine bewusst gestaltete Darstellung im Shop.

Mit Data Patch, Select-Optionen, ViewModel und einem eigenen Widget bekommst du eine Lösung, die redaktionell pflegbar und technisch sauber bleibt. Genau diese Kombination macht aus einem zusätzlichen Feld eine echte Shopfunktion und nicht nur ein weiteres Attribut im Backend.

10. FAQ: Custom Product Attribute mit Frontend-Widget in Magento 2