Skip to content

Product options and price formulas Pro

Pro: let customers configure a product and see the price change — with every amount worked out on the server, never in the browser.

Updated August 26, 2026

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 or image 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.

Still stuck? Email [email protected].