Product options and price formulas Pro

Build a group of fields under StoreMaster → Product options, target it at products, categories or tags, and it appears on those product pages.

Field types

Text, long text, number, email, URL, date, checkboxes, radio buttons, a dropdown, colour swatches, and headings for structure.

Each field can be required, carry a description and placeholder, and set limits: a minimum and maximum for numbers, a character limit for text.

How a choice changes the price

Every field picks one pricing mode:

Mode	What it does
None	Collects information; changes nothing
Flat	Adds a fixed amount
Per unit	Adds an amount for each item on the line
Per character	Adds an amount for each character typed — engraving, printing
Percentage	Adds a percentage of the product’s price
Customer-defined	The customer names the amount, within bounds you set
Formula	Works the amount out from a formula

Individual choices can carry their own amounts, so one dropdown can price five finishes differently.

Formulas

A formula is a small arithmetic expression:

round(base + (width * height * rate) + if(rush > 0, 15, 0), 2)

It can use + - * / % ^, comparisons, brackets, and these functions: min, max, round, ceil, floor, abs, clamp and if. Variables come from your number fields, plus base (the product’s price) and quantity.

if only works out the branch it picks, so if(qty > 0, total / qty, 0) is safe when the quantity is zero.

What a formula cannot do is as important: no text, no dates, no reading other data, no calling anything. It computes a number from numbers, and nothing else. StoreMaster never uses PHP’s eval and never evaluates a price in the browser.

Formulas are checked when you save, so a mistake is something you see while editing rather than something a customer meets at the basket.

Conditional fields

A field can appear only when another field has particular values — "engraving text" once "add engraving" is ticked.

This is enforced on the server as well as in the browser. A hidden field’s value is discarded, so a submitted form claiming an option it was never shown cannot be priced.

Prices are worked out on the server

The browser shows an estimate. The server recomputes every amount from your definitions at add-to-cart, again when the basket calculates, and again at checkout.

Nothing a customer’s browser sends is trusted: not a price, not a label, not an option that was not offered. A tampered form can at worst be rejected — it can never buy something cheaply.

What the order remembers

When a customer buys, the order line freezes the labels, values, amounts and the revision of the option group they bought under.

Rename a label afterwards, retire a field, change a price — the order still says exactly what it said. Removing a field archives it rather than deleting it, for the same reason: baskets and orders still refer to it.

Letting a customer upload an image

Add a field of type An image the customer uploads. It appears on the product page as an ordinary file box, and the image arrives with the order.

JPEG, PNG and WebP, up to 12 MB. Anything else is refused with a message the customer can read.

What happens to the file

It is re-encoded rather than stored as sent. The bytes are decoded, checked and written out again as a fresh image, so a file that merely calls itself a picture does not survive the trip.

It is kept outside your public uploads folder, where no web address reaches it. Opening one needs a signed link that expires, which is why the order screen shows the customer’s own file name rather than a URL you could paste anywhere.

An upload that never reaches an order is deleted after seven days. Once it is on an order it stays for as long as the order does.

What the order keeps

The order records which file was uploaded and the name it had, not a copy of the image inside the order. Prices and files are resolved when they are shown, so an order years old still points at the right picture rather than at a snapshot of it.