Checkout fields Free

Praetor can add fields to your checkout — a purchase reference, a delivery note, a required confirmation. Both editions support the same number.

The rule this module follows

Fields are registered through WooCommerce’s own additional-checkout-fields API and nothing else. Praetor does not modify the checkout markup, override a template or inject a hidden input.

That constraint is why a field added here appears on classic checkout and on the Checkout block alike, why the value is stored the same way on both, and why a WooCommerce update does not break your checkout. It also means Praetor can only offer what that API offers.

Supported field types

Text, select and checkbox — the three types WooCommerce’s Checkout block supports.

If you ask for something else, Praetor refuses when you configure it and explains why, rather than accepting the configuration and failing in front of a customer. Richer inputs belong on the product or basket page, where they can be validated properly.

Locations

A field can sit in the contact, address or order information section of checkout.

Adding one

Praetor → Checkout fields → Add field. Give it a key, a label, a type and a location, and say when it applies.

Showing or requiring a field only sometimes

Under When it applies, a field can be shown always or only when the basket matches, and an answer can be required never, always, or only when the basket matches. A basket matches when all of the conditions you set are true, and a condition tests one of four things:

• a product in the basket, by id
• a category in the basket, by slug — including anything in a sub-category of it
• the customer’s role
• the shipping country

Each can be is or is not. So "require a purchase order number when a wholesale customer buys from Chemicals" is two conditions on one field.

WooCommerce decides this, not Praetor. The conditions are written into the field’s definition and WooCommerce evaluates them — which is why the field appears and disappears as the basket changes, and why a customer can never be refused for leaving empty a field they were not shown.

Conditions need the Checkout block

This is the one place the two checkouts differ, and it is worth knowing before you rely on it.

WooCommerce evaluates these conditions on the Checkout block. The older shortcode checkout — [woocommerce_checkout] — is handed the field without them, so there a conditional field is always shown and is never conditionally required. Nothing breaks and nobody is refused; the condition simply does not narrow anything.

Praetor could watch the basket and hide the field itself on that checkout, and deliberately does not. That would be a second opinion about a decision WooCommerce already makes on the block, and the first place the two disagreed would be a field a customer never saw and was then refused for leaving empty.

If your shop runs the shortcode checkout and you need a field to appear only sometimes, the Checkout block is the answer.

The key is permanent. Once a field has been used on a real order, its type can no longer change — the value stored on that order means what the old definition said, and reinterpreting it would quietly change a customer’s record. Archive the field and add a new one instead.

Where the value appears

On the order in wp-admin, in the order emails you have enabled it for, and in WordPress’s privacy export and erase tools. It is stored on the order through WooCommerce’s own data layer, so it works the same under high-performance order storage.