# Product configurators and personalisation

> Engraving a name, choosing a dimension to the millimetre, composing an object from options that depend on each other: these look like product variants and aren’t. Knowing where the line runs avoids paying for unnecessary development — or skipping necessary work.

- Source canonique : [https://allaux.fr/en/modules/configurateur-de-produit](https://allaux.fr/en/modules/configurateur-de-produit)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The line: how many combinations actually exist

A store’s variant system creates a reference for each combination of options. Three sizes and four colours give twelve references, each with its own stock and price. That is perfect as long as combinations are countable.

As soon as the customer enters a free value — text to engrave, a length in centimetres, a file to print — the number of combinations becomes infinite, and the variant system stops being suitable. Creating variants to cover every possible length produces an unmanageable catalogue, slow to display and impossible to maintain.

PrestaShop provides a customisable-fields mechanism on the product page, with text entry or file upload, which covers simple cases. WooCommerce accepts additional fields on the product added to the cart. Many engraving or personal-message needs stop there, and that is the right answer.

## How I approach this kind of work

Development starts when options depend on one another, when the price is calculated from the input, or when a preview must be shown. Each of those three carries its own cost, and it helps to know which one really applies to you.

Dependencies between options need a rule set described once and applied everywhere: on display, when adding to the cart, and again when the order is validated. A check made only in the browser protects nothing, because an order can be built without going through the page.

A calculated price demands the same rigour, with one extra constraint: it must be recalculated server-side at order time, otherwise a change in the browser would be enough to alter the amount paid.

The visual preview is the most visible part and often the most expensive, because you must produce both an on-screen rendering and a file usable in production, at the right dimensions and resolution. Those are two different needs served by one interface.

## Related pages

- **Product personalisation studio** — A delivered project on this kind of need, presented anonymously. ([/realisations/studio-personnalisation-produit](/realisations/studio-personnalisation-produit))
- **Badly handled product variants** — When the need turns out to belong to the variant system and its settings. ([/prestashop/problemes/declinaisons-produits-bugs](/prestashop/problemes/declinaisons-produits-bugs))
- **Adding a product or order field** — For personalisation that fits into a simple input. ([/modules/ajouter-un-champ-produit-ou-commande](/modules/ajouter-un-champ-produit-ou-commande))

## FAQ

### How is stock handled for a personalisable product?

Stock usually applies to the raw material or the blank, not to the final combination. That rule must be defined explicitly, because the store’s automatic decrement reasons per reference and can’t work it out alone.

### Does the personalisation appear on the order and invoice?

It must, and it is worth checking early: an engraving missing from the picking slip causes a workshop error, and an invoice that doesn’t mention it creates a problem in a dispute.

### Can we retrieve files uploaded by customers?

Yes, and you must decide where they are stored, how long they are kept and who can access them. An uploaded customer file is data to be treated as such, not just one more image.

### Does a configurator slow the product page down?

It can, especially if it recalculates a price or a preview on every option change. How those exchanges are designed matters more than the number of options, and it is a point to address at design time.