PrestaShop 9.2 Extra Properties: Choosing the Right Data Model

An extra field is easy to request and surprisingly difficult to define well. A merchant asks for a “supplier reference,” but the agency still needs to know whether that reference belongs to a product, a combination, an order or a supplier relationship. The wrong answer creates ambiguity wherever the value is reused.

PrestaShop 9.2 introduces Extra Properties as a native extension mechanism. The official explanation describes namespaced field definitions with types, defaults, validation and visibility settings. It identifies entities including Product, Combination, Customer and Order. Extra Properties introduction.

For the RC1 available on September 26, 2026, treat adoption as a staging design exercise. The following examples explain how to decide what belongs in a property; they do not claim that a sample store has already been migrated.

Once field ownership and scope are explicit, use the Extra Properties module integration workflow to follow the value through registration, forms, persistence and API access.

Start with the fact, not the form field

A useful property records one fact about one identifiable entity. Before choosing a widget, write a sentence describing that fact: “This product has this internal handling class,” or “This order has this external reconciliation reference.”

Then ask when the fact changes. A catalog handling class may change when the product’s packaging changes. An order reference may be assigned once by an external system and then remain fixed. A customer preference may change frequently. Different lifecycles imply different owners and validation rules.

Avoid vague names such as extra_info. They invite several unrelated meanings into the same value. A property called packing_instruction gives maintainers a clearer contract, although its exact format and permitted contents still need definition.

Namespacing also matters operationally. Two modules may both discuss a “reference” but mean different identifiers. Keep the business owner and technical owner visible. If a module is replaced, the team should know which values need transferring and which are obsolete.

The native extension mechanism can reduce repeated infrastructure work. It cannot decide what a merchant’s data means.

Choose the entity that remains true over time

Consider a store selling a product in several sizes. A handling instruction shared by every size may belong to the product. A code identifying one supplier’s specific size may belong to the combination or a separate relationship model. Putting both on the product can make exports appear correct until the second size is introduced.

Orders introduce a temporal question. If a value describes what was sold at the time of purchase, reading the product’s current property months later may produce the wrong historical answer. Decide whether the order needs a snapshot, a reference to a durable external record or no copy at all.

A customer-level property should not be used merely because a value was collected from a customer. A delivery instruction for one purchase might belong to an address or order instead. Otherwise, the next purchase can inherit a value the customer never intended to reuse.

Use this short modeling interview:

The interview should happen before development. A field that is quick to add can still be expensive to interpret later.

Shop scope and language scope answer different questions

A translated label is not the same thing as a translated value. The field’s label might need to appear in several employee languages while the stored value is a single internal code. Conversely, a customer-facing instruction may require a separate value for each storefront language.

Shop scope describes where values differ commercially or operationally. Two shops might share a product but use different fulfillment instructions. That is not a translation problem. Giving the shops different languages merely to distinguish their values would hide the actual data model.

Also separate field availability from value variation. A property might be relevant only to selected shops. Within those shops, its value might still be common or shop-specific according to the supported definition. The 9.2 work includes the ability to restrict property definitions to a shop list; that is a separate concern from deciding how a value varies. Shop-restricted definitions.

Do not assume every combination of scope is supported identically on every entity and integration surface. Check the current implementation for the entity you plan to extend. A general feature description is not a substitute for a small proof of the exact model.

Use deliberately different fixture values when evaluating scope. If both shops contain “Standard,” an accidental shared value can remain invisible. Distinct values reveal whether a save, read or export used the intended context.

Visibility is a data decision, not a styling decision

A merchant may want a field in an administrative form without wanting it in the storefront. An integration may need a value that should never appear in a product template. Decide these separately.

The official introduction explains that API Extra Properties are grouped under their module namespace and inherit the parent entity’s permissions. This means an API capability should not be treated as an independent field-level confidentiality boundary. API behavior in the feature explanation.

For an internal instruction, inspect every intended and unintended consumer: form, grid, API response, storefront data and any export module. Hiding a grid column does not establish that the value cannot be read elsewhere.

Be especially careful with values containing business-sensitive notes or personal data. The correct answer may be a more specialized storage and authorization design. A general custom-field facility should not automatically become a repository for information requiring stricter access than its parent entity.

For public values, decide whether they are plain text, a constrained choice, a URL or rich content. Output handling should match that type. A value editable in the Back Office can still need escaping when rendered on the storefront.

Defaults, empty values and uniqueness need explicit meanings

There are often at least three states: unknown, intentionally empty and a meaningful value. A default can collapse them accidentally. If every imported product receives “Standard” because a supplier omitted the field, staff may mistake absence of information for a verified classification.

Write down the intended behavior for old records, new records and cleared values. A required field also needs a plan for existing entities that predate the requirement. Without one, ordinary editing can become blocked by a newly introduced constraint.

Uniqueness must match the business domain. An external identifier might be unique within one supplier or one shop, rather than across the entire installation. A global uniqueness assumption can reject legitimate records or encourage staff to alter identifiers merely to make a form save.

Defaults and constraints should support the data contract rather than compensate for an unclear one. Test them through all supported write paths, including the API if it is exposed. A form widget is not the only place a value can enter the system.

Some data belongs in a separate model

Extra Properties is a strong candidate for a small number of well-defined attributes attached to existing records. It is less suitable as the entire model for a sequence of events, a many-to-many relationship or a workflow requiring its own permissions and transactions.

A product’s storage category is a plausible attribute. A record of every warehouse movement is an event history. An order’s external reference is a plausible attribute. A full reconciliation process with attempts, errors and approvals is a workflow.

Avoid placing large opaque JSON documents into a property simply to avoid designing the relationships. A structured value can be appropriate for a bounded purpose, but an unbounded document makes searching, validation and migration harder. Ask how an operator would inspect and repair one incorrect element.

Likewise, distinguish factual source data from derived values. If a value can be calculated reliably from existing records, storing another copy creates a synchronization obligation. That may be justified, but it should be deliberate.

For a field proposal, require one concrete example and one counterexample. “An order’s reconciliation reference” is the example; “the full history of reconciliation attempts” is the counterexample. This small distinction helps future maintainers preserve the original boundary when new requests arrive.

Agree on ownership before the first real value is saved

Create a small field specification with entity, namespace, type, scope, default, writer, readers and removal policy. Include a sentence describing what the field must never be used for.

For example, an internal handling class could be owned by the catalog team, written by a controlled import and read by fulfillment. Manual edits might be allowed only if the next import preserves them. If that exception is not defined, the integration and staff will overwrite one another.

Plan replacement and uninstall behavior as well. Disabling a module, removing its definition and deleting its stored data are different operations. The official example module demonstrates destructive removal options, which should not be copied blindly into a commercial data-retention policy. Official example module.

A good Extra Properties design begins with a small, precise fact and follows it through its lifetime. Once ownership, scope and visibility are clear, the developer can implement the field without making those business decisions implicitly in code.

For the underlying platform context, see our PrestaShop 9 module development guide and apply the version-specific checks above to the installation you are evaluating.