Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Formular-Modifier (Data/Meta Modifiers) für dynamisches Verhalten

Formular-Modifier (Data/Meta Modifiers) für dynamisches Verhalten

~9 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026

Bisher wurde jedes Feld und jeder Wert direkt in form.xml oder im DataProvider deklariert. Sobald Formularverhalten von Bedingungen abhängt - berechnete Standardwerte, dynamisch ein-/ausgeblendete Felder, abgeleitete Labels -, reicht deklaratives XML nicht mehr aus. Genau dafür gibt es Modifier.

ModifierInterface und seine zwei Methoden

Ein Modifier implementiert \Magento\Ui\DataProvider\Modifier\ModifierInterface mit genau zwei Methoden: modifyData() verändert die geladenen Werte, modifyMeta() verändert die Struktur/Konfiguration (Sichtbarkeit, Labels, Pflichtfeld-Status) der Formularfelder.

app/code/Mironsoft/Announcement/Ui/DataProvider/Form/Modifier/DefaultTitle.php
<?php

declare(strict_types=1);

namespace Mironsoft\Announcement\Ui\DataProvider\Form\Modifier;

use Magento\Ui\DataProvider\Modifier\ModifierInterface;

/**
 * Fills in a placeholder title for newly created announcements.
 */
class DefaultTitle implements ModifierInterface
{
    /**
     * Sets a default title when no record has been loaded yet.
     *
     * @param array<string, mixed> $data Loaded form data, keyed by entity ID.
     * @return array<string, mixed>
     */
    public function modifyData(array $data): array
    {
        if (empty($data)) {
            $data['new'] = ['title' => __('New Announcement')->render()];
        }

        return $data;
    }

    /**
     * Leaves the field structure unchanged.
     *
     * @param array<string, mixed> $meta Current UI Component meta configuration.
     * @return array<string, mixed>
     */
    public function modifyMeta(array $meta): array
    {
        return $meta;
    }
}

Modifier per di.xml registrieren

Ein Modifier wird nicht direkt in form.xml referenziert, sondern über einen virtualType in die Modifier\Pool-Kette eingehängt, die der DataProvider im Hintergrund nutzt:

app/code/Mironsoft/Announcement/etc/adminhtml/di.xml
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <virtualType name="Mironsoft\Announcement\Ui\DataProvider\Form\AnnouncementDataProvider"
                 type="Magento\Ui\DataProvider\ModifierPoolDataProvider">
        <arguments>
            <argument name="pool" xsi:type="object">AnnouncementFormModifierPool</argument>
        </arguments>
    </virtualType>

    <virtualType name="AnnouncementFormModifierPool" type="Magento\Ui\DataProvider\Modifier\Pool">
        <arguments>
            <argument name="modifiers" xsi:type="array">
                <item name="default_title" xsi:type="array">
                    <item name="class" xsi:type="string">Mironsoft\Announcement\Ui\DataProvider\Form\Modifier\DefaultTitle</item>
                    <item name="sortOrder" xsi:type="number">10</item>
                </item>
            </argument>
        </arguments>
    </virtualType>
</config>

Wichtig: Hier wird nicht die konkrete DataProvider-Klasse aus Kapitel 9 direkt erweitert, sondern über einen gleichnamigen virtualType "überschrieben" - dieser nutzt intern ModifierPoolDataProvider, die die eigene DataProvider-Klasse durch eine Pool-fähige Variante ersetzt.

Meta-Modifikation: Feld dynamisch verstecken

modifyMeta() arbeitet mit einer verschachtelten Array-Struktur, die exakt der XML-Baumstruktur aus form.xml entspricht - fieldset/general/children/title/arguments/data/config zum Beispiel entspricht dem <field name="title">-Element im general-Fieldset:

public function modifyMeta(array $meta): array
{
    $meta['general']['children']['title']['arguments']['data']['config']['visible'] = false;

    return $meta;
}

Achtung: Diese direkte Array-Manipulation ist fehleranfällig - ein falsch geschriebener Schlüssel wirft keinen Fehler, sondern wird einfach ignoriert, und das Feld bleibt sichtbar. Kapitel 21 zeigt einen saubereren, deklarativen Ansatz über imports/exports für die häufigsten Fälle von abhängigen Feldern.

Warum Modifier - und nicht eine ViewModel-Klasse

Modifier sind ein weiteres Beispiel für Kapitel 1s ehrlichen Hinweis: Das UI-Components-Framework ruft Modifier\Pool zu einem festen Zeitpunkt im DataProvider-Lebenszyklus auf und erwartet exakt ModifierInterface als Vertrag - ein ArgumentInterface-ViewModel lässt sich hier nicht einhängen. Die injizierbare Zusatzlogik (zum Beispiel eine Regel, wann ein Feld sichtbar sein soll) bleibt trotzdem sinnvoll in ein eigenes Service-Objekt ausgelagert, das der Modifier im Konstruktor injiziert - der Modifier selbst bleibt so ein dünner Adapter.