# Adding a field to a product or an order

> «I just need one more field.» It is the request that looks simplest and holds the most surprises, because a field never exists alone: it must be entered somewhere, stored, displayed, found again, exported, printed, and sometimes translated.

- Source canonique : [https://allaux.fr/en/modules/ajouter-un-champ-produit-ou-commande](https://allaux.fr/en/modules/ajouter-un-champ-produit-ou-commande)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The typical need

The requests recur in similar shapes: a free comment per order line, an internal reference on the product page, a case number entered by the customer at checkout, supplier information visible internally only, or regulatory data that must appear on the invoice.

All raise the same underlying question: who enters it, who reads it, and where must the information reappear. A field visible only in admin is quick work. A field entered by the customer at checkout touches the purchase path, validation, the confirmation email and printed documents, which is an entirely different job.

## How I approach this kind of work

I start by checking whether the platform already does it. PrestaShop has product features and custom product fields, plus an order comment field; WooCommerce accepts additional data attached to a product or an order without needing a structure to be created. Many requests stop there, and that is a good thing.

When the data must be filterable, validated or reused elsewhere, I create proper storage rather than lodging it in an existing field repurposed for the job. That is where a year of peace is won or lost: data placed in a field designed for something else always ends up clashing with the original function, typically at export or during a migration.

Then I explicitly handle the whole chain: entry, validity checking, admin display, customer display if needed, presence in emails, exports and PDF documents. That list is what separates a genuinely usable field from a field nobody ever looks at.

## A field on the order isn’t a field on the customer

> Information attached to the customer changes with them; information attached to the order must stay frozen as it was at the time of purchase. Confusing the two produces invoices that change retroactively, which is an accounting problem, not just a display one.

## Related pages

- **Adding a business screen to the back office** — When extra fields become numerous enough to deserve their own screen. ([/modules/ecran-metier-dans-le-back-office](/modules/ecran-metier-dans-le-back-office))
- **Generating PDF documents** — To make the field appear on an invoice or a delivery note. ([/modules/generation-de-documents-pdf](/modules/generation-de-documents-pdf))
- **Saving a product page fails** — A common symptom when fields have been added carelessly. ([/prestashop/problemes/fiche-produit-enregistrement-echoue](/prestashop/problemes/fiche-produit-enregistrement-echoue))
- **Exporting the catalogue and orders** — To bring the new field through into a usable export. ([/prestashop/problemes/export-catalogue-commandes-csv](/prestashop/problemes/export-catalogue-commandes-csv))

## FAQ

### Can the field be made mandatory at checkout?

Yes, but it touches checkout validation: you must decide what happens when it is empty, how the error message shows, and check that the block doesn’t break one-click payments, which sometimes bypass that step.

### Will the field appear in existing exports?

Not automatically. Native exports list columns known in advance. Adding a column to an export is separate work from creating the field, and it is better planned from the start.

### What happens to the field during a platform migration?

Data held in a proper structure is found and transferred. Data lodged in a repurposed field is often lost or misread, because the migration tool treats it as the original data.

### How many fields can be added without degrading the store?

The count matters less than how they are stored. A few well-placed fields cost nothing; dozens of values stored row by row in a generic table noticeably slow down product and order lists.