Personalised products, printed textiles and marking: what has to be built
On a promotional products, printed textile or online print store, the catalogue holds no prices: it holds the elements used to work them out. That shift is what makes the field demanding, and it explains why personalisation and configurators are among the development requests merchants raise most often.
The price is not read, it is computed
The amount depends on quantity, with tiered discounts; on the marking technique chosen — screen printing, embroidery, engraving, digital printing; on the number of colours; on how many positions are marked; and on fixed setup or screen charges spread across the quantity ordered. One reference can therefore produce hundreds of different prices, which rules out storing them one by one.
That calculation belongs on the server. A price built only in the browser can be tampered with: altering the values sent is enough to obtain an amount that never existed in the rate card. Client-side script should only display an estimate; the amount added to the basket, the one sent to payment and the one printed on the invoice must all be recomputed from the same rules, in the same place.
What a CMS does not provide
- Artwork upload from the product page, with checks on format (vector or raster), resolution, colour mode and bleed.
- Attaching the file to the order line rather than the customer account, and keeping it through the move from basket to order — that transition is where files are lost most often.
- The proof: production only starts after approval. That needs a status waiting on agreement, a notification, an automatic reminder and a timestamped record of the approval.
- Exclusion from the right of withdrawal for goods made to the consumer’s specifications or clearly personalised, under article L221-28 of the French consumer code, with the notice shown at the moment the customer confirms.
- The stated lead time: it depends on technique and quantity, not on the product. It is derived from the workshop’s workload and working days, and displayed as a date.
- The production file: an on-screen preview is not enough, the server has to generate the file actually used in production, at the right dimensions and with the right marks, attached to the job sheet.
Where the server gives way first
Customer files are large: vector artwork with outlined fonts, a high-resolution image meant for wide-format printing, sometimes several per order. PHP limits are reached very quickly, and the symptom on the customer side is always the same: an upload that appears to complete, then a blank page, or an order recorded without its file.
So the limits need raising, but their existence also has to be accepted: check the size before sending, split the upload when the file is heavy, and refuse explicitly rather than failing silently. A message stating what is wrong with the file saves an exchange of emails and an order stuck for two days.
upload_max_filesize = 64M
post_max_size = 72M
max_file_uploads = 20
max_execution_time = 300
memory_limit = 256MSame ground
-
Product personalisation studio
A concrete example of a configurator wired to price calculation and production file generation.
-
Dedicated order statuses
Proof approval calls for a waiting-on-agreement state that default statuses cannot represent.
-
Custom PrestaShop module
When pricing and file logic has to survive updates, it is built as a module rather than a theme edit.
-
Custom development
The wider framework when no off-the-shelf extension covers the workshop’s rules.
Frequently asked questions
Can an off-the-shelf configurator be enough?
Where should the customer file be stored?
How is proof approval handled without external software?
Can a personalised item be returned?
Why do uploads fail on large files?
Is the preview shown to the customer enough to produce from?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.