Seite 12 - Magento

Der ObjectManager ist das Service Locator Pattern in Magento 2 — und gleichzeitig das bekannteste Anti-Pattern der Plattform. Dieser Artikel erklärt, warum sein direkter Einsatz in Produktionscode verboten ist, welche Ausnahmen legitim sind und wie korrektes Dependency Injection aussieht.

Magento 2 Domain Mapping pro Store bedeutet, jedem Store view eine eigene, eindeutige Domain statt eines gemeinsamen Store-Codes im Pfad zuzuweisen, und das betrifft weit mehr als nur die Base-URL-Konfiguration im Backend. Vhost-Regeln, SSL-Zertifikate, Cookie-Domains und die Varnish-Cache-Strategie müssen konsistent auf dasselbe Domain-Modell abgestimmt sein, sonst entstehen schwer zu findende Fehler zwischen Store views.

Die url_rewrite-Tabelle in Magento 2 verbindet jede SEO-freundliche URL mit ihrem internen Ziel und wächst mit jeder Kategorieänderung, jedem Produktumzug und jeder Attributpflege weiter. Wer URL-Rewrites nur über die Admin-Oberfläche pflegt, verliert bei mehreren tausend Einträgen schnell den Überblick und riskiert Redirect-Ketten sowie 404-Fehler. Dieser Beitrag zeigt, wie man URL-Rewrites programmatisch über Service Contracts erzeugt, per CSV-Import in großen Mengen pflegt und dauerhaft überwacht.

Das Builder Pattern erzeugt komplexe Objekte Schritt für Schritt. In Magento 2 ist es besonders wichtig bei SearchCriteria, Filtern, Sortierungen und stabilen Konfigurationsobjekten für Services.

Sobald ein eigener Indexer auf den Ergebnissen eines anderen aufbaut, entscheidet sauberes Indexer Dependency Management darueber, ob die Daten am Ende konsistent sind oder ob ein nachgelagerter Indexer regelmaessig mit veralteten Zwischenergebnissen rechnet, ohne dass jemand den Fehler sofort bemerkt.

Wie Magento's AbstractCollection PHP-Iteratoren implementiert, warum Lazy Loading entscheidend ist, und wie du große Katalogdaten memory-effizient traversierst.

Wenn neue Objekte teuer zu initialisieren sind, kopiert das Prototype Pattern einen vorhandenen Prototyp. Wie Magento clone() und Factory::create() nutzt – und wann du es selbst anwenden solltest.

Ohne systematische Betrugserkennung verlässt sich ein Magento-Shop im Checkout auf Zufall: Adressabweichungen, ungewöhnliche Bestellfrequenzen und Kartenländer-Mismatches bleiben unbemerkt, bis die Rückbuchung kommt. Dieser Artikel zeigt, wie ein eigener Risk-Scoring-Service als Service Contract konkrete Fraud-Signale bewertet, verdächtige Bestellungen per Order Hold statt hartem Blockieren zur manuellen Prüfung stellt und wie sich externe Fraud-Prevention-Dienste wie Signifyd, Riskified oder ClearSale sauber per Webhook anbinden lassen, ohne legitime Kunden durch Fehlalarme zu verlieren.

Magento 2 bringt mit EAV ein sehr flexibles Modell für Produkt- und Kundendaten mit. Gleichzeitig sind klassische Flat Tables in vielen eigenen Modulen die bessere Entscheidung. Die Kunst liegt darin, beides nicht zu verwechseln.

Eine falsch gesetzte Magento 2 Store View Konfiguration bleibt oft wochenlang unentdeckt, bis ein Kunde auf der falschen Domain die falsche Preisanzeige sieht. Die Scope-Hierarchie aus Default, Website und Store View entscheidet, welcher Wert wirklich greift, und wer diese Reihenfolge nicht verinnerlicht, produziert Konfigurationsfehler, die sich erst im Live-Betrieb zeigen.