FieldtypeDimensions – product dimensions and weight field

[maximus]

Hi everyone,

I made a small fieldtype module for storing product dimensions:

• https://github.com/mxmsmnv/FieldtypeDimensions

FieldtypeDimensions lets you store length, width, height and optionally weight in a single field. It’s mainly useful for product/catalog/e-commerce pages where dimensions are needed for display, shipping or filtering.

Supports different units (mm, cm, m, in, etc. for length and g, kg, lb, etc. for weight) and stores values internally in mm/grams.

The module also supports multilingual setups — admin field labels are available in 20+ languages and can be configured globally.

Basic usage example:

$dim = $page->dimensions;
echo $dim; // 120 × 80 × 50 mm, 1.5 kg
echo $dim->lengthIn('cm');
echo $dim->weightIn('kg');

Selectors:

$pages->find("template=product, dimensions.length>100");
$pages->find("template=product, dimensions.weight>500");

More details in the README.

Feedback and suggestions are very welcome.

[adrian]

Hi @maximus - thanks as always! 

Would you mind giving us a basic list of differences compared to: https://processwire.com/modules/fieldtype-object-dimensions/ so we can make an informed decision about which might be better for our needs?

Is it basically just the additional weight subfield?

Thanks.

[maximus]

Hi @adrian, great question — happy to clarify.

Both modules store L×W×H, but the focus is different:

FieldtypeObjectDimensions (juergen) — geometry-oriented: auto-calculates and stores area and volume, useful when you need spatial calculations.

FieldtypeDimensions (mine) — shipping/e-commerce-oriented. The reason it exists: I've been building a package forwarding platform (think Qwintry-style — customers ship packages to a US warehouse, we consolidate and forward internationally). That platform, AltaPost, never launched at scale, but the logistics logic stuck with me. When I needed a dimensions field for product catalogs in ProcessWire, the obvious missing piece was weight — you can't quote a shipping rate without it. A lot of our shipments went to Europe, so we constantly needed to show the same package in both metric and imperial at once — 120 × 80 × 50 mm / 4.7 × 3.1 × 1.9 in, 1.5 kg / 3.3 lb. That's why the conversion API exists: no manual math in templates.

Main differences:

• Weight field — fourth subfield alongside L×W×H, optional per-field
• Unit conversion API — $dim->lengthIn('in'), $dim->weightIn('lb') for passing values directly to shipping APIs (GoShippo, EasyPost, FedEx rates) or displaying both metric and imperial simultaneously
• Normalized storage — always saves in mm/grams internally; changing display unit never requires data migration
• 28 admin languages — useful when ProcessWire itself is configured with multiple languages and you want field labels to appear natively for each editor

If you need area/volume stored and searchable — @Juergen module is the better fit. If you need weight + unit conversion for shipping integrations — this one covers that case.

[adrian]

Awesome - thank you!

[maximus]

Thanks Adrian! Since you're in Canada — if you ever deal with cross-border shipments to the US or Europe, the unit conversion comes in handy. Canadians get the best of both worlds — metric by default but imperial just across the border. 😄

[adrian]

There is nothing good about imperial 😜