For Craft Commerce 5
Shipping rates that go up with the parcel
Commerce prices a shipping rule per line item. A carrier prices a parcel. Weight closes that gap with an ordered list of rules whose charges accumulate — a handling fee, a weight band, a free-shipping threshold — and shows you every number that went into the total.
Try it on a cart you invent
This is the simulator, running the plugin's own evaluation in your browser. Drag the weight and watch each rule match or miss, and the arithmetic behind every charge redraw.
Not a screenshot and not a recording — the rules are the ones in the plugin's docs/example-config.json, and the price is computed the same way checkout computes it. Push the subtotal past 75 and the free-shipping rule short-circuits everything below it.
Four rules, one price
Rules do not compete — every one that matches contributes. That is the whole model, and it is the model store owners coming from WooCommerce already know.
Handling flat 3.50
First 2kg ≤ 2kg flat 4.50
Above 2kg > 2kg flat 4.50 + 1.20 per 0.5kg
after a 2kg free allowance
Free over 75 subtotal ≥ 75 → free
{# A 6kg cart: 3.50 + 4.50 + 9.60 = 17.60 — and the simulator
will print you exactly that breakdown, rule by rule. #}
{% set quote = craft.weight.quote('standard') %}
{{ quote.total }} {# 17.60 #}The whole table, not one price
A column of numbers makes a flat spot or a cliff obvious; checking weights one at a time does not. Turn a rule off and watch the entire ladder move.
| Weight | Price |
|---|
Turn off Handling and every row drops by 3.50 — that is what “every matching rule contributes” means. Turn off First 2kg and the bottom of the table stops being offered at all, because nothing matches a light parcel any more.
Turn off Handling and every row drops by exactly 3.50. That is what “every matching rule contributes” means, and it is the thing most rate plugins get wrong by making rules compete instead.
Features
The WooCommerce rule model, taken from that plugin's source rather than its marketing — plus the packing engine it never had.
Rules that add up
An ordered list, evaluated top to bottom. A flat handling fee, a cost per unit of weight, a cost per item and a percentage of the subtotal, each clamped by the rule's own minimum and maximum.
- Whole-step or continuous per-weight charging, after a free allowance
- A rule can make shipping free, withdraw the method, or stop evaluation
Bands that don't overlap
Each end of a weight range carries its own inclusivity, so exactly 2kg lands in one band and not in both — the bug every hand-rolled rate table ships with.
Conditions worth having
Weight, subtotal and quantity ranges. Destination by country or administrative area. Postal codes as exact values, wildcards or numeric ranges. Shipping categories, three ways.
- Subtotal optionally after discounts and optionally including tax
- Craft's own condition builder too, plus largest item dimension
Packing that charges for parcels
Split the cart by a maximum package weight, or pack first-fit-decreasing into your own box library — inner dimensions, weight limits, tare weight and a packaging surcharge. Then rate each parcel and add the results up.
Dimensional weight
Give a method a divisor and every package is billed on the heavier of its real weight and length × width × height ÷ divisor — the way a carrier bills a large light parcel.
A simulator that shows its working
Quote a real cart or a weight you invent, and read back the packing, every rule in order, the condition each missed rule failed, and every component of every charge including the clamps.
- Routes through the same rater as checkout — a preview cannot disagree
- Turn on Log quotes and the same detail lands in the log for every order
Carrier presets, and a backstop for Postie
Importable rate structures shaped like Royal Mail, UPS, FedEx, USPS, DHL and Australia Post — where the bands fall, whether the carrier bills in steps or continuously, what its dimensional divisor is. Every amount in them is a placeholder, because a stale rate table undercharges at checkout.
- With Postie installed, Weight's box library drives its packing — one library, not two
- A rule can wait to see what the carriers said, so a table rate is a backstop, not a rival
Watch the parcels fill up
First-fit-decreasing into a real box library, with tare weights, packaging costs and dimensional weight. Change a quantity and a second parcel appears.
Switch dimensional weight to divisor 5000: the cushions weigh almost nothing but fill a large carton, so both parcels start being billed on their volume instead — the way a carrier bills them. Add a Poster tube and it fits no box at all, so the method either ignores it or withdraws itself.
Add a poster tube and it fits no box — so the method either ignores it or withdraws itself, and withdrawing is the honest setting.
Frequently Asked Questions
The questions worth answering before you install it.
$59, once, with a $49/year renewal for updates. One edition, no free tier, no trial, and nothing withheld for a higher tier — box packing, dimensional weight, per-category charges, condition-builder rules, the carrier presets and the Postie integration are all in it. The renewal buys updates rather than the right to keep running it: if you let it lapse, the version you have keeps working.
Commerce prices a shipping rule per line item. Weight prices a package, which is what a carrier actually charges for, and lets several rules contribute to one price rather than picking a winner. Expressing a handling fee, a weight band and a free-shipping threshold in per-line-item rules means duplicating the handling fee across every product in the cart. The two coexist — Weight's methods appear alongside Commerce's own.
Neither, quite. Every rule that matches contributes to the price — they accumulate. A rule opts out of that by being a free, disable or stop rule, or by carrying the stop flag. This is the single most important thing to know about the plugin, and it is what WooCommerce's plugin does too — it is just not what its documentation implies.
The rule model is the same one, so the concepts map one to one: ordered rules, accumulating charges, weight and subtotal conditions, free / disable / stop. There is no importer — you retype the table — but you will not have to rethink it, and the simulator will tell you immediately if a band came across wrong.
The billable weight: the packed weight, including each box's own tare weight, and after any dimensional-weight uplift. Line items that are not shippable, or that already carry free shipping, are excluded before packing starts. Weight conditions are judged against that same billable weight, so a rule that says "over 30kg" means over 30kg of parcel, not 30kg of product.
No, structurally. Rater::quote() is the only place in the plugin a price is computed, and the Commerce shipping method, the simulator, the Twig variable, the JSON endpoint and the console all read the Quote it returns. The simulator's made-up packages go through the same rating and clamping code as a real cart.
Honest rather than optimal. Three-dimensional bin packing is NP-hard and nobody solves it exactly inside a checkout request. Weight uses first-fit-decreasing with a volume-and-dimension fit test, and does not model the geometry of what is already in a box — so it errs towards more boxes rather than fewer, which is the direction that overcharges no carrier. Every decision it makes is visible in the simulator.
No — they are in the database, which is the same call Commerce makes for its own shipping methods. A store owner changing a rate should not need a deploy. Moving rates between environments is an explicit weight/methods/export and weight/methods/import, matching on handle.
Yes, and it improves on running either alone. Where both are installed, Weight's box library drives Postie's packing, so the simulator and the carrier request cannot disagree about how many parcels there are — and a rule can ask what the carriers said, which lets a table rate be a backstop for an API outage rather than a permanent competitor to a live rate. Neither needs switching on. Weight never edits Postie's prices: exactly one plugin computes any given total.
No, deliberately. They encode each service's structure — where the bands fall, whether it bills continuously or in whole steps, what the dimensional divisor is — with placeholder amounts, and every preset method is created disabled. Republishing a carrier's rate card would be someone else's copyright and would be stale within a quarter, and a stale table undercharges at checkout on every order. The structure is the tedious part; the numbers are the part you already have on a contract.
Craft CMS 5.3+, Craft Commerce 5.0+, PHP 8.2+.
One price, every feature
$59, with a $49/year renewal for updates. There is no free tier and no higher tier — box packing, dimensional weight, per-category charges, condition-builder rules, the carrier presets and the Postie integration are all in it.