EXTEND

DI

Deep Dive · Magento 2 Erweiterbarkeit

Preferences vs. Plugins:
Wann welche Erweiterungsstrategie?

Wie Interceptoren intern funktionieren, warum Preferences meist die falsche Wahl sind, und die genauen Regeln für Before, After und Around Plugins.

15 min Lesezeit

Magento 2.4.8 · PHP 8.4

Magento Extension Points

Inhalt

1. 1. Zwei Wege, Magento zu erweitern
2. 2. Preferences: Klasse ersetzen via di.xml
3. 3. Warum Preferences problematisch sind
4. 4. Plugins (Interceptoren): Das Interceptor Pattern
5. 5. Before-Plugin: Argumente modifizieren
6. 6. After-Plugin: Rückgabewert modifizieren
7. 7. Around-Plugin: Vollständige Kontrolle (und Risiken)
8. 8. Plugin-Sortierung und Konflikte
9. 9. Plugin-Grenzen: Was Plugins nicht können
10. 10. Entscheidungsmatrix: Preference vs. Plugin vs. Observer

Eine der häufigsten Fragen in Magento-Code-Reviews: "Soll ich eine Preference oder ein Plugin verwenden?" Die Antwort ist fast immer Plugin — aber warum, und mit welchem Typ? Dieser

Magento Admin Workflows wie Produktanlage, Bestellabwicklung und Preisregeln entscheiden über Umsatz und Datenintegrität, auch ohne dass Kunden sie je sehen. End to end Tests mit Cypress oder Playwright decken genau die Lücke ab, die PHPUnit Integrationstests offen lassen: Session Handling, Grid Interaktionen und Massenaktionen im echten Browser, mit klarer Priorisierung nach Wartungskosten und Geschäftsrisiko.

Magento-Datenbanken wachsen selten durch Produktdaten, sondern durch Logs, verwaiste Warenkörbe und URL-Rewrites, die niemand aktiv löscht. Wer die üblichen Verdächtigen kennt, Tabellengrößen regelmäßig misst und eine wiederholbare Bereinigungsroutine etabliert, verhindert, dass Backups, Deployments und Reindex-Läufe unter dem Datenbank-Wachstum leiden.

Magento 2 · Debugging

Xdebug + PHPStorm
der optimale Debug-Workflow

Ein gutes Debug-Setup spart in Magento 2 keine Minuten, sondern oft ganze Tage. Wer Xdebug und PHPStorm sauber für Browser, CLI und Docker aufsetzt, versteht Fehlerpfade schneller und verliert deutlich weniger Zeit an falsche Annahmen.

20 Min. Lesezeit Xdebug Magento 2.4.8

Inhaltsverzeichnis

1. 1. Warum Xdebug PHPStorm Magento 2 mehr als nur ein Setup-Thema ist
2. 2. Xdebug in Docker und Mark-Shust-Umgebungen sauber aktivieren
3. 3. PHPStorm richtig konfigurieren
4. 4. Browser-Requests, Cookies und Breakpoints zuverlässig treffen
5. 5. CLI-Debugging für Setup, Cron und Indexer
6. 6. Ein effizienter Debug-Workflow für Magento 2
7. 7. Typische Fehlerquellen
8. 8. var_dump vs. Xdebug vs. Logs
9. 9. Magento 2 Unterstützung
10. 10. Zusammenfassung und FAQ

1. Warum Xdebug PHPStorm Magento 2 mehr als nur ein Setup-Thema ist

Xdebug PHPStorm Magento 2 wirkt auf den ersten Blick wie ein rein technisches Einrichtungsdetail.

Sobald der Kunde am ursprünglichen Add-to-Cart-Button vorbeigescrollt ist, übernimmt eine schlanke Sticky Add to Cart Bar am unteren Bildschirmrand. Mit x-intersect statt eines eigenen Scroll-Listeners lässt sich dieses Muster performant und ohne Layout-Thrashing umsetzen, synchron mit Variantenauswahl und Menge im Hauptformular.

Kundengruppen sind in Magento 2 der zentrale Mechanismus, um Preise und Sichtbarkeit gezielt nach Kundensegment zu steuern: von Großhandelspreisen über verborgene B2B-Kataloge bis zu individuellen Staffelpreisen pro Gruppe. Wer Catalog Price Rules, Tier Pricing, Sichtbarkeits-Plugins und Shared Catalog richtig kombiniert, kann komplexe B2B- und B2C-Preislogik ohne Custom-Checkout-Hacks abbilden, muss dabei aber Reindex-Zyklen, Scoping-Fehler und die Sonderrolle der Gruppe NOT LOGGED IN im Griff behalten.

Adobe Commerce bringt mit dem Product-Recommendations-Modul ein fertiges, Adobe-Sensei-basiertes Empfehlungssystem mit, das ohne eigene Machine-Learning-Implementierung auskommt. Dieser Artikel erklärt, wie das Feature technisch funktioniert, wie sich die einzelnen Recommendation-Typen konfigurieren lassen, wo die Grenze zu selbstgebauten KI-Empfehlungen verläuft und welche Datenschutz-Implikationen die Nutzung mit sich bringt.

Composable Commerce löst den monolithischen Shop durch austauschbare, über APIs verbundene Services ab. Magento kann in diesem Modell als reine Commerce-Engine agieren, während Suche, Content und Frontend als eigenständige Bausteine daneben leben. Wer das Prinzip versteht, vermeidet die typischen Fallstricke bei Latenz, Konsistenz und Betriebskomplexität.

Bei Katalogen mit mehreren hunderttausend SKUs wird der catalogsearch_fulltext-Indexer schnell zum Flaschenhals im Betrieb: volle Reindex-Laeufe dauern Stunden, der Cron-Job blockiert andere Jobs, und PHP-Worker geraten an ihre Speichergrenze. Dieser Artikel zeigt, wie Batch Size, Partial-Reindex-Strategien und die Elasticsearch Bulk API zusammenspielen, um die Indexer-Performance bei grossen Katalogen spuerbar zu verbessern.

Die eingebauten Page Builder Content Types decken Text, Bild und Banner ab, reichen für individuelle Anforderungen aber selten aus. Wer einen eigenen Page Builder Content Type mit Master Format, Formular-Konfiguration und Renderer sauber aufsetzt, gibt Redakteuren ein wiederverwendbares Werkzeug an die Hand, statt für jede Anfrage eine neue Sonderlösung zu bauen.