Gemeinsame Shop-Komponenten für PrestaShop-Module

Unser empfohlenes Vorgehen

Wir würden ein funktionierendes Bedienelement des Themes beibehalten, wenn es die Anforderung erfüllt, und eine gemeinsame Komponente nutzen, wenn deren Schnittstellen passen. Die Wahl hängt von Ihrem vorhandenen Theme und Child-Theme, Modulen und Paketversionen, Integrationen, angezeigten oder gespeicherten Daten, Kundensprachen und den Wartungskapazitäten des Teams ab.

Entwickeln Sie die Änderung auf einer Staging-Kopie mit diesen Abhängigkeiten. Leiten Sie ausgehende E-Mails an ein Testpostfach um, verwenden Sie Sandbox-Zugangsdaten für Integrationen und deaktivieren Sie produktive Jobs und Webhooks vor dem Testen. Erproben Sie den betroffenen Ablauf und vereinbaren Sie dann die Live-Umstellung. Halten Sie die bisherigen Moduldateien, veröffentlichten Ressourcen und die Konfiguration zur gemeinsamen Wiederherstellung bereit. Prüfen Sie den Ablauf nach der Umstellung erneut.

Wenn Sie die Oberfläche und ihre Geschäftsregeln entwickeln lassen möchten, kann der PrestaShop Custom Module Development Service diese Arbeit abgrenzen und umsetzen.

Controller, Renderer und Ressourcen trennen

myprestarocks/prestashop-front liefert einen gemeinsamen Modul-Frontcontroller, PHP-Komponentenrenderer, Stile und JavaScript-Helfer. Jeder Teil hat eigene Aufgaben. Durch das Erweitern des Controllers werden weder alle Komponentenressourcen registriert noch wird Ihre Geschäftslogik bereitgestellt.

MyPrestaRocks\Front\MPRModuleFrontController stellt die Verarbeitung kanonischer URLs und Routen bereit. Er überschreibt die native kanonische Weiterleitung und stellt über die Template-Variablen der Seite eine kanonische URL bereit. Implementieren Sie die Identität und das Routenverhalten Ihrer Seite, bevor Sie sich auf die standardmäßige kanonische URL verlassen.

Verwenden Sie getCanonicalURL() bei Bedarf für seitenspezifische Canonical-Regeln. Prüfen Sie endgültige Seitenvariablen und HTML-Kopf. Canonical-Link und HTTP-Weiterleitung haben unterschiedliche Zwecke; prüfen Sie beide für benutzerfreundliche und abfragebasierte Adressen.

Die kleinste passende Integration wählen

Benötigte Seitenressourcen registrieren

Veröffentlichen Sie Browserressourcen des Pakets im Modulverzeichnis views/vendor/prestashop-front/. Registrieren Sie Komponentenfamilien während der Medienphase des Shops, damit Pfade, Abhängigkeiten und Reihenfolge vor Serialisierung der Ausgabe verfügbar sind.

use MyPrestaRocks\Front\Asset\ComponentAssets;

ComponentAssets::register(
    $this->context->controller,
    $this,
    ['modal'],
    ['form']
);

Dieses Beispiel wird in einem Medien-Hook eines Moduls ausgeführt. Die Skriptliste wählt das Paketverhalten aus; die Stilliste wählt die auf der Seite gerenderten Markup-Familien. Wählen Sie die tatsächlich auf Ihrer Seite verwendeten Familien. Die ältere API FrontAssetRegistrar bleibt ein separater Integrationsweg.

Nutzen Sie bei Bedarf geladene Stile nur für später geöffnete Oberflächen, deren Öffnung auf das Stylesheet wartet. Halten Sie Stile des sichtbaren Auslösers in der Anfangsseite. Eine beim Laden offene Komponente braucht ihre normalen Stile sofort.

Registrieren Sie auch moduleigene Controller, wenn sie Ihren normalen Medien-Hook nicht erhalten. Leeren Sie nach Bereitstellung relevante Ressourcen- und Seiten-Caches. Prüfen Sie fehlende Dateien und gemischte Paketversionen, wenn mehrere Module dieselben Klassen teilen.

Theme-Tokens nutzen, ohne eine Isolation vorauszusetzen

Komponentenselektoren nutzen das Präfix mpr- und gemeinsame benutzerdefinierte Eigenschaften mit --mpr-. Das reduziert Namenskollisionen. Ein Selektorpräfix verhindert keine Änderungen durch vererbte Theme-Stile, allgemein gefasste Theme-Regeln oder andere Stylesheets.

Die Integration von Theme Detector kann Theme-Klassen oder -Tokens bereitstellen, sofern der Helfer sie nutzt. Prüfen Sie die Abhängigkeiten und den aufgerufenen Renderer. Gehen Sie nicht davon aus, dass jede Komponente automatisch Layout, Typografie und Farben jedes Themes übernimmt.

Asset\ThemeAssets kann mitgelieferte Theme-Adapter und aktiviertes Händler-CSS oder -JavaScript registrieren. Rufen Sie es innerhalb normaler Seiten- und Funktionsprüfungen des zuständigen Moduls auf. Testen Sie automatische Auswahl mit aktivem Child- und Eltern-Theme.

Das responsive Verhalten hängt vom tatsächlichen CSS und Layout der jeweiligen Komponente ab. Prüfen Sie schmale Bildschirme, Zoom, lange Übersetzungen, Text von rechts nach links und Inhaltsumbrüche. Eine Komponente kann responsiv sein und dennoch eine Anpassung an das Theme benötigen.

Renderer-Eingaben als Vertrag behandeln

Prüfen Sie je Parameter, ob er Klartext, URL, ID, strukturierte Daten oder vertrauenswürdiges HTML akzeptiert. Beispielsweise maskiert Component\MPRModal::render() Titel und mehrere Attribute, akzeptiert aber HTML für Inhalt und Fußbereich vom Aufrufer.

Erstellen Sie vertrauenswürdiges Inhalts-Markup über Templates mit maskierten Werten. Ein Renderer, der einen Titel maskiert, kann beliebiges HTML in einem anderen Feld nicht bereinigen. Geben Sie jeder Instanz eine eindeutige ID und erhalten Sie beim Einfügen von Fragmenten die Verknüpfungen zwischen Beschriftung, Beschreibung und Bedienelement.

Trennen Sie Komponentendarstellung vom Abruf der Anbieterdaten. Der gemeinsame Bewertungsrenderer akzeptiert etwa Bewertungsarrays, ruft aber keine Bewertungen ab. Übernehmen Sie die tatsächlichen aggregierten Werte des Anbieters und berechnen Sie keine behauptete Gesamtbewertung aus einer ausgewählten Stichprobe der angezeigten Bewertungen.

Formularverhalten auf dem Server implementieren

Eine Formularkomponente liefert Darstellung und Interaktion. Ihr Modul verantwortet weiterhin Authentifizierung, Autorisierung, CSRF-Prüfung, Eingabevalidierung und Speicherung. Validieren Sie serverseitig, auch wenn JavaScript dieselben Prüfungen zur Bedienbarkeit durchführt.

• Verknüpfen Sie jedes Feld mit Beschriftung und sinnvollem Namen.
• Nutzen Sie passende Eingabetypen und Autocomplete-Werte.
• Zeigen Sie Feldfehler neben dem betroffenen Feld und erhalten Sie gültige Eingaben.
• Verhindern Sie wiederholtes Absenden, ohne fehlgeschlagene Formulare dauerhaft zu deaktivieren.
• Nutzen Sie native Formularübermittlung oder einen brauchbaren Rückfallweg, soweit die Aktion es erlaubt.

Ein Modal kann Bedienelemente im Inhalts- und Fußbereich enthalten. Ordnen Sie diese dem vorgesehenen Formular zu. Bei aktiviertem Komponentenmodus und aktivierter Formularbereichsoption ordnet der Renderer die Bedienelemente im Inhalts- und Fußbereich dem künftigen Formular zu, sofern sie nicht bereits ein Formular angeben. Ihr Modul muss den Bereich in ein Formular umwandeln, nachdem das Modal-Wurzelelement unter den Dokument-Body verschoben wurde, die generierte Formular-ID beibehalten und die Übermittlung anbinden. Prüfen Sie das resultierende HTML, statt Formulare zu verschachteln.

Ein Formular für Bestandsbenachrichtigungen durchspielen

Angenommen, ein Button auf der Produktseite öffnet ein Modal für eine Bestandsbenachrichtigung per E-Mail. Bewerten Sie die gespeicherte Benachrichtigung und die Bestätigung für den Kunden als Ergebnis, statt sich mit einem Screenshot des geöffneten Dialogs zufriedenzugeben.

1. Öffnen Sie es, senden Sie eine ungültige E-Mail-Adresse ab und korrigieren Sie den Fehler. Bestätigen Sie, dass das ausgewählte Produkt oder die Variante der Anfrage zugeordnet bleibt.
2. Senden Sie gültige Testdaten ab und simulieren Sie den Verlust der Antwort, nachdem der Server die Benachrichtigung gespeichert hat. Wiederholen Sie dieselbe Anfrage und prüfen Sie die gespeicherten Datensätze, um sicherzustellen, dass nur eine Benachrichtigung existiert. Ein deaktivierter Button allein schützt den Server nicht.
3. Ändern Sie die Produktvariante, sodass die Seite das betreffende Fragment ersetzt, und öffnen Sie das Formular anschließend erneut und senden Sie es ab. Bestätigen Sie, dass sich die gespeicherte Benachrichtigung auf die aktuelle Variante bezieht und nicht auf die vor dem Ersetzen ausgewählte.

Gesamte Interaktion prüfen

1. Öffnen und schließen Sie Dialoge per Tastatur. Prüfen Sie Anfangsfokus, Fokusbegrenzung, Escape-Behandlung und Rückkehr zum Auslöser.
2. Prüfen Sie, ob der Dialog einen barrierefrei zugänglichen Namen hat und die Bedienelemente beim Scrollen des Inhalts erreichbar bleiben.
3. Testen Sie Fehler und Erfolgsmeldungen mit assistiver Technik. Kündigen Sie nötige Statusänderungen an, ohne Kunden wiederholt zu unterbrechen.
4. Verbergen Sie dekorative Symbole vor assistiver Technik und geben Sie Bedienelementen, die nur aus einem Symbol bestehen, einen barrierefrei zugänglichen Namen.
5. Testen Sie die Einstellung für reduzierte Bewegung, Zoom und sichtbaren Fokus im aktiven Theme.
6. Wiederholen Sie nach AJAX-Ersetzung. Prüfen Sie doppelte Listener, doppelte IDs und defekte Beschriftungsreferenzen.
7. Blockieren Sie vorübergehend ein Skript oder Stylesheet. Prüfen Sie, ob wichtige Navigationswege und Formulare weiterhin nutzbare Ergebnisse liefern.

Testen Sie Warenkorb und Bestellprozess um Ihre Komponente ebenso wie die Komponente selbst. Gemeinsames Markup reduziert Wiederholungsarbeit, doch nutzendes Modul und Theme bestimmen das gesamte Kundenerlebnis.

Wenn ein Dialog nach dem Neuladen funktioniert, nach einer Produktaktualisierung aber nicht mehr, prüfen Sie, ob sein Auslöser oder Container ersetzt wurde. Wird eine Aktion wiederholt ausgeführt, prüfen Sie die Listener-Registrierung und die Netzwerkanfragen des Browsers, bevor Sie die serverseitige Verarbeitung ändern.

Fragen an Ihren Entwickler oder Ihre Agentur

• Welche Module nutzen dieses Paket und wer prüft sie, wenn sich die gemeinsame Version ändert?
• Welches Template liefert vertrauenswürdiges HTML und welches Modul validiert und speichert die übermittelten Daten?
• Können Sie die Staging-Ergebnisse mit unserem Child-Theme, unseren Sprachen und Produktdaten zeigen?
• Wer führt die Live-Umstellung durch, überwacht fehlgeschlagene Anfragen und stellt bei Bedarf die bisherigen Dateien und Ressourcen wieder her?

Fragen von Shop-Betreibern

Sehen damit alle Module gleich aus?

Nur Module, die das gemeinsame Markup und die Ressourcen übernehmen, profitieren davon. Vereinbaren Sie vor der Beauftragung einer umfassenderen Neugestaltung, welche Oberflächen dazugehören.

Brauchen wir ein neues Theme?

Ein Theme-Wechsel ist zunächst nicht erforderlich. Lassen Sie zuerst die fehlerhafte Interaktion reproduzieren und die betreffende Stil- oder Ressourcenabhängigkeit ermitteln.

Können wir zurückwechseln, nachdem Kunden das Formular genutzt haben?

Planen Sie, wie der bisherige Code mit Datensätzen umgeht, die das neue Formular gespeichert hat. Die Wiederherstellung einer alten Datenbank kann spätere Bestellungen oder Formulareingaben verwerfen; klären Sie Datenkompatibilität und Wiederherstellung vor dem Start.