27 Kapitel, ein durchgehendes Projekt - von der ersten leeren Tabelle bis zu Custom-Renderern, Inline-Edit und granularer ACL. Dieses letzte Kapitel fasst alle Kern-Patterns als Nachschlagewerk zusammen.

Die fünf Kernprinzipien

1. UI Components bleiben im Admin Standard - unabhängig davon, dass Hyvä im Frontend KnockoutJS ersetzt (Kapitel 1).
2. listing.xml/form.xml sind ein Vertrag zwischen PHP und JavaScript - jede component-Angabe referenziert ein konkretes RequireJS-Modul (Kapitel 1, 4, 9).
3. DataProvider-, Column-, Modifier- und Button-Klassen erzwingen eigene Basisklassen - hier hat die ViewModel-Präferenz ihre Grenze, injizierbare Zusatzlogik gehört trotzdem in separate Service-Objekte (Kapitel 1, 5, 13, 19, 22).
4. addFieldToFilter() immer als ['eq' => $value] - PHPStan-Level-5-Pflicht in diesem Projekt (Kapitel 5, 18, 24).
5. Serverseitige Validierung ist Pflicht, clientseitige ist Komfort - beide gehören dazu, keine ersetzt die andere (Kapitel 11, 12).

Spickzettel: listing.xml-Skelett

<dataSource name="{name}_data_source">
    <argument name="dataProvider" xsi:type="configurableObject">
        <argument name="class" xsi:type="string">Vendor\Module\Ui\DataProvider\...</argument>
        <argument name="name" xsi:type="string">{name}_data_source</argument>
        <argument name="primaryFieldName" xsi:type="string">entity_id</argument>
        <argument name="requestFieldName" xsi:type="string">id</argument>
    </argument>
</dataSource>

Spickzettel: form.xml-Skelett

<settings>
    <buttons>
        <button name="save" class="Vendor\Module\Block\Adminhtml\...\SaveButton"/>
    </buttons>
</settings>
<dataSource name="...">
    <argument name="data" xsi:type="array">
        <item name="config" xsi:type="array">
            <item name="submit_url" xsi:type="url" path="vendor_module/entity/save"/>
        </item>
    </argument>
</dataSource>

Spickzettel: ACL und Controller

class Save extends Action implements HttpPostActionInterface
{
    public const ADMIN_RESOURCE = 'Vendor_Module::save';
    // ...
}

Spickzettel: DataProvider und Modifier

class MyDataProvider extends AbstractDataProvider
{
    // primaryFieldName + requestFieldName im Konstruktor durchreichen,
    // $this->collection = $collectionFactory->create();
}

class MyModifier implements ModifierInterface
{
    public function modifyData(array $data): array { /* Werte */ return $data; }
    public function modifyMeta(array $meta): array { /* Struktur */ return $meta; }
}

Das Testimonial-Projekt als Vorlage

Die zwölf Kapitel des durchgehenden Projekts (14-25) - db_schema.xml mit Relationstabelle, Grid, Formular mit Bild-Upload, Delete mit Bestätigung, Store-View-Sichtbarkeit, Custom-Renderer, Inline-Edit, dynamische Felder, eigene Buttons, Export, Performance, granulare ACL - lassen sich direkt als Vorlage für jedes weitere eigene Admin-Modul in diesem Projekt verwenden. Die Reihenfolge bleibt dabei stabil: Datenmodell zuerst, dann Grid, dann Formular, dann Löschen/Sichtbarkeit, erst danach fortgeschrittene Techniken.

Zehn goldene Regeln für die tägliche Arbeit

1. Nach jeder db_schema.xml-Änderung: setup:upgrade, sonst bleibt die Änderung wirkungslos.
2. addFieldToFilter() immer als ['eq' => $value], nie als nackten Skalar.
3. Serverseitige Validierung im Save-Controller ist Pflicht, unabhängig von der clientseitigen.
4. HttpPostActionInterface auf jedem speichernden/löschenden Controller nicht vergessen.
5. Destruktive Massenaktionen immer mit <confirm> absichern.
6. Column-Renderer, Modifier und Buttons dürfen eigene Basisklassen nicht umgehen - Zusatzlogik in separate Services auslagern.
7. Keine Datenbankabfragen pro Zeile in Column-Renderern - einmalig vorladen.
8. ACL granular pro Aktion vergeben (Ansicht/Speichern/Löschen getrennt), nicht als ein grober Knoten.
9. Bei unerwartetem Verhalten zuerst Browser-Konsole und Netzwerk-Tab prüfen, erst danach im PHP-Code suchen.
10. assert() und @-Error-Silencing sind tabu - explizite Prüfungen mit LocalizedException oder PHPStan-Annotationen verwenden.

Damit ist diese Serie abgeschlossen. Mit diesen Grundlagen lässt sich jeder weitere Magento-2-Admin-Bereich - ob eigenes Modul wie die Kundenstimmen-Verwaltung oder Anpassung eines Core-Grids - strukturiert und mit Vertrauen in die zugrunde liegenden Muster umsetzen.