PrestaShop 9.2 Extra Properties: Das richtige Datenmodell wählen

Ein zusätzliches Feld ist leicht angefordert und überraschend schwer sauber definiert. Ein Händler bittet um eine „Lieferantenreferenz“, doch die Agentur muss noch wissen, ob diese zu einem Produkt, einer Kombination, einer Bestellung oder einer Lieferantenbeziehung gehört. Die falsche Antwort erzeugt Mehrdeutigkeit überall, wo der Wert wiederverwendet wird.

PrestaShop 9.2 führt Extra Properties als nativen Erweiterungsmechanismus ein. Die offizielle Erläuterung beschreibt Felddefinitionen mit Namensräumen, Typen, Standardwerten, Validierung und Sichtbarkeitseinstellungen. Sie nennt unter anderem die Entitäten Product, Combination, Customer und Order. Einführung in Extra Properties.

Behandeln Sie für die am 26. September 2026 verfügbare RC1 die Einführung als Entwurfsübung auf Staging. Die folgenden Beispiele erklären, wie entschieden wird, was in eine Eigenschaft gehört; sie behaupten nicht, dass ein Beispielshop bereits migriert wurde.

Sobald Feldzuständigkeit und Geltungsbereich klar sind, verwenden Sie den Ablauf zur Extra-Properties-Modulintegration, um den Wert durch Registrierung, Formulare, Speicherung und API-Zugriff zu verfolgen.

Mit dem Sachverhalt beginnen, nicht mit dem Formularfeld

Eine hilfreiche Eigenschaft hält einen Sachverhalt zu einer identifizierbaren Entität fest. Schreiben Sie vor der Widget-Auswahl einen Satz, der ihn beschreibt: „Dieses Produkt hat diese interne Handhabungsklasse“ oder „Diese Bestellung hat diese externe Abstimmungsreferenz“.

Fragen Sie dann, wann sich der Sachverhalt ändert. Eine Katalog-Handhabungsklasse kann sich mit der Produktverpackung ändern. Eine Bestellreferenz kann einmal von einem externen System zugewiesen werden und danach fest bleiben. Eine Kundenpräferenz kann sich häufig ändern. Unterschiedliche Lebenszyklen bedeuten unterschiedliche Zuständigkeiten und Validierungsregeln.

Vermeiden Sie vage Namen wie extra_info. Sie laden dazu ein, mehrere unzusammenhängende Bedeutungen in einem Wert unterzubringen. Eine Eigenschaft namens packing_instruction gibt Betreuern einen klareren Vertrag, obwohl genaues Format und erlaubte Inhalte weiterhin definiert werden müssen.

Namensräume sind auch betrieblich wichtig. Zwei Module können beide eine „Referenz“ meinen, aber unterschiedliche Kennungen bezeichnen. Halten Sie fachliche und technische Verantwortliche sichtbar. Wird ein Modul ersetzt, sollte das Team wissen, welche Werte übertragen werden müssen und welche überholt sind.

Der native Erweiterungsmechanismus kann wiederholte Infrastrukturarbeit reduzieren. Er kann nicht entscheiden, was die Daten eines Händlers bedeuten.

Die Entität wählen, die dauerhaft zutrifft

Betrachten Sie einen Shop, der ein Produkt in mehreren Größen verkauft. Eine für alle Größen gemeinsame Handhabungsanweisung kann zum Produkt gehören. Ein Code für eine bestimmte Lieferantengröße kann zur Kombination oder einem separaten Beziehungsmodell gehören. Beides am Produkt abzulegen kann Exporte korrekt erscheinen lassen, bis die zweite Größe hinzukommt.

Bestellungen werfen eine zeitliche Frage auf. Beschreibt ein Wert, was zum Kaufzeitpunkt verkauft wurde, kann das Lesen der aktuellen Produkteigenschaft Monate später eine falsche historische Antwort liefern. Entscheiden Sie, ob die Bestellung einen Schnappschuss, einen Verweis auf einen dauerhaften externen Datensatz oder gar keine Kopie benötigt.

Eine Eigenschaft auf Kundenebene sollte nicht allein deshalb verwendet werden, weil ein Wert vom Kunden erfasst wurde. Eine Lieferanweisung für einen Kauf kann stattdessen zu einer Adresse oder Bestellung gehören. Sonst kann der nächste Kauf einen Wert erben, den der Kunde nie wiederverwenden wollte.

Verwenden Sie dieses kurze Modellierungsinterview:

Das Interview sollte vor der Entwicklung stattfinden. Ein schnell ergänztes Feld kann später trotzdem teuer zu interpretieren sein.

Shop- und Sprachbereich beantworten unterschiedliche Fragen

Eine übersetzte Beschriftung ist nicht dasselbe wie ein übersetzter Wert. Die Feldbeschriftung muss möglicherweise in mehreren Mitarbeitersprachen erscheinen, während der gespeicherte Wert ein einzelner interner Code ist. Eine kundenbezogene Anweisung kann dagegen für jede Shopsprache einen eigenen Wert benötigen.

Der Shopbereich beschreibt, wo Werte geschäftlich oder betrieblich abweichen. Zwei Shops können ein Produkt teilen, aber unterschiedliche Abwicklungsanweisungen verwenden. Das ist kein Übersetzungsproblem. Den Shops nur zur Unterscheidung ihrer Werte verschiedene Sprachen zu geben, würde das eigentliche Datenmodell verbergen.

Trennen Sie auch Feldverfügbarkeit von Wertvariation. Eine Eigenschaft kann nur für ausgewählte Shops relevant sein. Innerhalb dieser Shops kann ihr Wert entsprechend der unterstützten Definition dennoch gemeinsam oder shopspezifisch sein. Die 9.2-Arbeit umfasst die Beschränkung von Eigenschaftsdefinitionen auf eine Shopliste; das ist getrennt von der Entscheidung, wie ein Wert variiert. Shopbeschränkte Definitionen.

Nehmen Sie nicht an, dass jede Bereichskombination bei jeder Entität und Integrationsoberfläche identisch unterstützt wird. Prüfen Sie die aktuelle Implementierung der zu erweiternden Entität. Eine allgemeine Funktionsbeschreibung ersetzt keinen kleinen Nachweis des genauen Modells.

Verwenden Sie bei der Bereichsbewertung bewusst unterschiedliche Testwerte. Steht in beiden Shops „Standard“, kann ein versehentlich geteilter Wert unsichtbar bleiben. Unterschiedliche Werte zeigen, ob Speichern, Lesen oder Exportieren den beabsichtigten Kontext verwendet hat.

Sichtbarkeit ist eine Datenentscheidung, keine Gestaltungsentscheidung

Ein Händler kann ein Feld im Verwaltungsformular wünschen, ohne es im Shop zeigen zu wollen. Eine Integration kann einen Wert benötigen, der niemals in einem Produkt-Template erscheinen sollte. Entscheiden Sie diese Fragen getrennt.

Die offizielle Einführung erklärt, dass API-Extra-Properties unter dem Namensraum ihres Moduls gruppiert werden und die Berechtigungen der übergeordneten Entität erben. Eine API-Funktion darf daher nicht als unabhängige Vertraulichkeitsgrenze auf Feldebene betrachtet werden. API-Verhalten in der Funktionserläuterung.

Prüfen Sie bei einer internen Anweisung alle vorgesehenen und unbeabsichtigten Verbraucher: Formular, Grid, API-Antwort, Shopdaten und Exportmodule. Eine ausgeblendete Grid-Spalte belegt nicht, dass der Wert anderswo nicht lesbar ist.

Seien Sie besonders vorsichtig bei Werten mit geschäftlich sensiblen Notizen oder personenbezogenen Daten. Die richtige Lösung kann ein spezialisierterer Speicher- und Berechtigungsentwurf sein. Eine allgemeine Funktion für eigene Felder sollte nicht automatisch zum Speicher für Informationen werden, die strengeren Zugriff als ihre übergeordnete Entität benötigen.

Entscheiden Sie bei öffentlichen Werten, ob es Klartext, eine eingeschränkte Auswahl, eine URL oder formatierter Inhalt ist. Die Ausgabe sollte diesem Typ entsprechen. Ein im Backoffice bearbeitbarer Wert kann bei der Darstellung im Shop weiterhin Escaping benötigen.

Standardwerte, leere Werte und Eindeutigkeit brauchen klare Bedeutungen

Oft gibt es mindestens drei Zustände: unbekannt, bewusst leer und einen aussagekräftigen Wert. Ein Standardwert kann sie versehentlich zusammenführen. Erhält jedes importierte Produkt „Standard“, weil der Lieferant das Feld ausgelassen hat, können Mitarbeiter fehlende Informationen für eine geprüfte Einstufung halten.

Notieren Sie das beabsichtigte Verhalten für alte Datensätze, neue Datensätze und geleerte Werte. Ein Pflichtfeld braucht auch einen Plan für bestehende Entitäten, die älter als die Anforderung sind. Ohne ihn kann normale Bearbeitung durch eine neue Einschränkung blockiert werden.

Eindeutigkeit muss zum fachlichen Bereich passen. Eine externe Kennung kann innerhalb eines Lieferanten oder Shops eindeutig sein, statt über die ganze Installation hinweg. Globale Eindeutigkeit als Annahme kann legitime Datensätze ablehnen oder Mitarbeiter dazu bringen, Kennungen nur zum Speichern eines Formulars zu ändern.

Standardwerte und Einschränkungen sollten den Datenvertrag unterstützen, statt einen unklaren Vertrag auszugleichen. Testen Sie sie über alle unterstützten Schreibpfade, einschließlich der API, sofern bereitgestellt. Ein Formular-Widget ist nicht der einzige Weg, auf dem ein Wert ins System gelangt.

Manche Daten gehören in ein separates Modell

Extra Properties eignet sich gut für wenige klar definierte Attribute bestehender Datensätze. Weniger geeignet ist es als vollständiges Modell einer Ereignisfolge, einer Viele-zu-viele-Beziehung oder eines Ablaufs mit eigenen Berechtigungen und Transaktionen.

Die Lagerkategorie eines Produkts ist ein plausibles Attribut. Ein Protokoll jeder Lagerbewegung ist eine Ereignishistorie. Die externe Referenz einer Bestellung ist ein plausibles Attribut. Ein vollständiger Abstimmungsprozess mit Versuchen, Fehlern und Genehmigungen ist ein Workflow.

Vermeiden Sie große undurchsichtige JSON-Dokumente in einer Eigenschaft, nur um den Beziehungsentwurf zu umgehen. Ein strukturierter Wert kann für einen begrenzten Zweck geeignet sein, doch ein unbegrenztes Dokument erschwert Suche, Validierung und Migration. Fragen Sie, wie ein Betreiber ein falsches Element untersuchen und reparieren würde.

Unterscheiden Sie ebenso tatsächliche Quelldaten von abgeleiteten Werten. Lässt sich ein Wert zuverlässig aus bestehenden Datensätzen berechnen, erzeugt eine zusätzliche gespeicherte Kopie eine Synchronisierungspflicht. Das kann gerechtfertigt sein, sollte aber bewusst geschehen.

Verlangen Sie für einen Feldvorschlag ein konkretes Beispiel und ein Gegenbeispiel. „Die Abstimmungsreferenz einer Bestellung“ ist das Beispiel; „die vollständige Historie der Abstimmungsversuche“ das Gegenbeispiel. Diese kleine Unterscheidung hilft späteren Betreuern, die ursprüngliche Grenze bei neuen Anforderungen zu bewahren.

Zuständigkeiten vor dem ersten echten gespeicherten Wert vereinbaren

Erstellen Sie eine kurze Feldspezifikation mit Entität, Namensraum, Typ, Bereich, Standardwert, schreibender Stelle, Lesern und Löschrichtlinie. Ergänzen Sie einen Satz dazu, wofür das Feld niemals verwendet werden darf.

Eine interne Handhabungsklasse könnte beispielsweise dem Katalogteam gehören, von einem kontrollierten Import geschrieben und von der Auftragsabwicklung gelesen werden. Manuelle Änderungen wären möglicherweise nur erlaubt, wenn der nächste Import sie erhält. Ist diese Ausnahme nicht definiert, überschreiben Integration und Mitarbeiter einander.

Planen Sie auch Austausch und Deinstallation. Ein Modul deaktivieren, seine Definition entfernen und seine gespeicherten Daten löschen sind unterschiedliche Vorgänge. Das offizielle Beispielmodul zeigt destruktive Löschoptionen, die nicht blind in eine geschäftliche Datenaufbewahrungsrichtlinie übernommen werden sollten. Offizielles Beispielmodul.

Ein guter Extra-Properties-Entwurf beginnt mit einem kleinen, präzisen Sachverhalt und verfolgt ihn über seine Lebensdauer. Sind Zuständigkeit, Bereich und Sichtbarkeit klar, kann der Entwickler das Feld implementieren, ohne diese Geschäftsentscheidungen implizit im Code zu treffen.

Für den zugrunde liegenden Plattformkontext lesen Sie unseren Leitfaden zur PrestaShop-9-Modulentwicklung und wenden Sie die obigen versionsspezifischen Prüfungen auf die Installation an, die Sie bewerten.