Zuerst die bestehende Integration erfassen

Theme, Module und Tag-Manager können denselben Dienst an verschiedenen Stellen laden. Prüfen Sie Produktseiten, Warenkorb, Checkout und Formulare für angemeldete Besucher und Gäste.

Legen Sie vor dem Abschalten der alten Integration fest, was erhalten bleiben muss: Conversion-Ereignisse, Einwilligungspräferenzen oder Formularprüfungen. Arbeiten Sie in einer Testumgebung und prüfen Sie Magento-Version und Theme-Architektur.

Schriften im Theme-Quellcode ergänzen

Für ein Theme auf Basis der Magento-UI-Bibliothek empfiehlt Adobe Schriftdateien unter web/fonts und ihre Deklaration in web/css/source/_typography.less im eigenen Theme. Bearbeiten Sie weder das Standard-Theme noch generierte styles-m.css-Dateien: Änderungen müssen die Neugenerierung der Ressourcen überstehen.

Das folgende Beispiel zeigt die Deklaration einer lokalen Schrift. Ersetzen Sie Name und Pfad durch die lizenzierten Dateien Ihres Projekts. Bei einem Theme ohne UI-Bibliothek verwenden Sie dessen CSS-Mechanismus und Build-Prozess.

.lib-font-face(
  @family-name: 'Project Sans',
  @font-path: '@{baseDir}fonts/project-sans-regular',
  @font-weight: 400,
  @font-style: normal,
  @font-display: swap
);

Messung migrieren, nicht nur das Skript

Ein Seitenaufruf ist keine Bestellung. Definieren Sie relevante Ereignisse ausdrücklich: Produktansicht, Hinzufügen zum Warenkorb, Checkout-Beginn und bestätigte Bestellung. Prüfen Sie Währung, Wert und mögliche Duplikate.

Wenn Sie Matomo oder eine andere Plattform wählen, prüfen Sie die Integration für Version und Frontend Ihres Shops. Ein Modul für ein klassisches Theme kann Anpassungen für ein individuelles Frontend benötigen. Konfigurieren Sie die übermittelten Daten und vermeiden Sie Kunden-E-Mails oder andere Kundendaten in Ereignissen ohne klare Begründung.

Den Formular-Endpunkt schützen

Ein Spamschutz-Widget im Template reicht nicht aus. Das Token muss vor der geschützten Aktion an das Backend übermittelt und dort geprüft werden. Der geheime Schlüssel bleibt auf dem Server.

Prüfen Sie bei Turnstile auch die erwartete Aktion und den Hostnamen. Behandeln Sie abgelaufene, wiederverwendete oder ungültige Token als fehlgeschlagene Prüfung. Eine klare Meldung sollte einen erneuten Versuch ohne erneutes Ausfüllen ermöglichen.

Was wir vor dem Start prüfen

Wir durchlaufen betroffene Seiten und Abläufe auf Mobilgeräten und Desktop. Wir prüfen Schriften, Sonderzeichen, Browserfehler und mögliche Blockierungen durch die Content Security Policy.

Bei der Messung vergleichen wir erwartete mit empfangenen Ereignissen. Bei Formularen testen wir gültige Eingaben sowie fehlende oder ungültige Token. Im Checkout prüfen wir, dass die Änderung die Bestellung nicht beeinträchtigt.

Wir veröffentlichen erst nach erfolgreicher Prüfung in der Testumgebung und dokumentieren die Rückschritte. Die tatsächlichen Migrationskosten umfassen diese Prüfung und die spätere Wartung, nicht nur die Installation einer Erweiterung.

Quellen und Dokumentation

Überarbeitete Fassung des ursprünglich 2025 auf Verosea veröffentlichten Artikels.

Wie lässt sich das auf Ihr Projekt anwenden?

Sprechen wir darüber ↗