Crevol Measurement Price lets your customers type in their own length, area, volume, or weight — and charges them the exact right amount, automatically, from a formula you write once.

Magento Open Source & Adobe Commerce REST & GraphQL No custom-option hacks
Product page showing a Length (cm) field with the value 10 entered, and a live 'Estimated price: $120.00' line updating beneath it
Type a value, watch the price update — before the customer ever clicks Add to Cart.
The problem

Some products just aren’t sold by the unit.

Fabric, flooring, glass, cable, mulch, water tanks, custom-cut lumber — the price depends on how much the customer needs, and “how much” is a number only the customer knows. Most stores end up faking this with a pile of fixed-size variants, a “please call for a quote” note, or a custom option field that some developer had to hand-wire for one specific product. None of that scales, and none of it lets the customer see the real price before they commit.

Configure the formula once. Every customer after that just types in their own numbers and gets priced correctly — instantly.
How it works

Four steps, from admin config to a priced order.

1

Pick a measurement type and a formula

On the product’s edit page, choose Length, Area, Volume, or Weight. A sensible default formula fills in automatically ({price} * width * height for Area) — edit it if you need bulk discounts, a minimum charge, or a fixed cutting fee on top.

2

The right fields appear on the product page — nothing hardcoded

The storefront renders exactly the fields that measurement type needs, labeled with the unit you configured, so “10” always reads as “10 cm.”

3

The customer sees the price before they commit

As they type, an AJAX call runs the same formula server-side and shows a live estimate — a convenience preview only; it’s never the number that actually gets charged.

4

Price is locked in server-side at Add to Cart

The formula runs again, from scratch, on the server the moment the item is added — and the entered measurements travel with the item through the cart, the order, and the invoice.

Product page for a water tank with three empty fields: Length (cm), Width (cm), Height (cm)
A Volume product asks for three dimensions — generated automatically, no template edits.
Same water tank page with 10, 10, 10 entered into Length, Width and Height, showing Estimated price $2,020.00
10 × 10 × 10 cm at $2/cm³ → $2,020.00, computed live.
Measurement types

One field for a rope. Three for a tank.

Each type shows only the fields it needs.

TypeFields shownTypical useDefault formula
LengthLengthRope, cable, molding, trim{price}*length
AreaWidth, HeightTile, fabric, glass, flooring{price}*width*height
VolumeLength, Width, HeightTanks, soil, concrete, crates{price}*length*width*height
WeightWeightProduce, bulk goods, metal stock{price}*weight
Formula language

Not just multiplication — a real, safe expression language.

Every formula is parsed by a small, purpose-built evaluator — never PHP’s eval(). It understands arithmetic, comparisons, a ternary conditional, and a fixed whitelist of functions on the measurement variables you give it. Nothing else. That’s enough to express real merchandising rules directly in the formula field:

// $20 off any order of 50 sq ft or more
{price}*width*height – (width*height >= 50 ? 20 : 0)
// 10% off orders of 100kg or heavier
{price}*weight – (weight >= 100 ? weight*0.1*{price} : 0)
// clamp the final price between $50 and $500, whatever the length
max(min({price}*length, 500), 50)
{price} * width * height  – ( width * height  >=  50  ?  20  :  0 )
Catalog priceThe product’s normal price, before measurement.
Measurement variableslength, width, height, weight — only the ones the type needs.
Comparison & ternary> < >= <= == != and condition ? a : b
LiteralsPlain numbers, written directly in the formula.

Two pricing modes

The formula can set the final price outright, or add its result to a separately configured fixed base price — a $15 cutting fee plus {price}*length.

Min / max limits

Reject orders under 10cm or over 500cm — enforced as HTML5 limits on the input and again on the server, so disabling JavaScript can’t bypass it.

No eval(), ever

A hand-written tokenizer and parser can only ever produce arithmetic on known variables and a fixed function list — nothing an admin-entered formula could turn into arbitrary code.

min · max · round · abs · floor · ceil · sqrt

A small, fixed function library — enough to clamp a range, round to a display-friendly value, or price by a curved surface.

Real example

Made-to-measure blinds, priced by the square foot.

Blinds are the case that actually needs the ternary logic above, not just bare multiplication — a small custom cut costs a manufacturer disproportionately more per square foot than a large one, because the cutting overhead is fixed. A one-line formula captures that directly on an Area-type product:

// under 3 sq ft: 40% premium (small custom cuts cost more per sqft) · 20 sq ft and up: 15% bulk discount · otherwise: standard rate
{price}*width*height*(width*height < 3 ? 1.4 : (width*height >= 20 ? 0.85 : 1))
Custom Cut Window Blinds product page with Width (ft2) and Height (ft2) both set to 5, showing Estimated price $318.75
A 5 × 5 ft blind at the $15/sq ft base rate: 25 sq ft crosses the 20 sq ft bulk-discount line, so the estimate comes back at $318.75 — 15% under the $375 a flat per-sqft price would have charged.
Shopping cart showing Zing Jump Rope, Length: 10 cm, priced at $120.00
The measurements the customer entered travel with the item — into the cart, and later the order and invoice.
Reliability

The price you show is the price you charge. Everywhere.

A live preview is only useful if it’s never the thing you actually trust. Every path a product can reach the cart through — the storefront’s own Add to Cart button, the REST cart API, or a GraphQL addProductsToCart mutation from a headless front end — runs through the same server-side calculation before the item is ever added.

Recalculated server-side on every add-to-cart pathNot just the storefront form — REST, GraphQL, and admin order creation all price through the identical formula engine.
Missing or invalid measurements are refused, not guessed atA product configured for measurement pricing can’t quietly end up in a cart at its bare catalog price.
One calculation engine, used everywhereThe add-to-cart flow, the live preview, and the GraphQL price-estimate query all call the exact same PriceCalculator — they cannot drift out of sync with each other.
Clean against Adobe’s own coding standardShips at zero warnings under phpcs –standard=Magento2, with unit test coverage on the formula parser and price calculator.
For developers

A real service contract, not just admin-form magic.

Every measurement rule is reachable over REST, and a headless storefront can both discover a product’s fields and preview its price over GraphQL — no hardcoded field lists on the front-end side.

REST CRUD

Read, create/update, or remove a product’s measurement rule, guarded by its own ACL resource under Catalog → Products.

GET  /V1/crevol-measurement-price/:productId
PUT  /V1/crevol-measurement-price/:productId

GraphQL headless

Discover a product’s fields and preview its price without hardcoding anything client-side.

crevol_measurement_rule
crevolMeasurementPriceEstimate(…)

Stop hand-wiring custom options.

Configure a formula once, and every product that needs to be priced by how big it is just works — on the storefront, over REST, and over GraphQL.

Install Crevol Measurement Price Read the docs