Skip to content

Spreadsheet import Pro

Pro: read a CSV back into your configuration, matched by SKU and slug, in one transaction that either finishes or changes nothing.

Updated September 14, 2026

Praetor → Import / export → Spreadsheets → Read a spreadsheet back in. Paste the file, see what every row would do, then import it.

Preview first, always

Pasting a file changes nothing. Praetor reads it, reports how many rows are new, how many are changes to rules you already have, and how many have a problem — and only then offers to write it.

A bad row anywhere stops the whole file

If any row cannot be imported, nothing is written. Not the rows before it, not the rows after it.

This is deliberate. Half an import is worse than no import: it leaves you with a configuration nobody designed and no way to tell by looking which half you have. Fix the line the preview names and paste it again.

An empty cell means "I did not touch this"

A row whose uuid matches a rule you already have is a change to that rule, not a replacement of it. Only the columns you filled in are applied; a column you left blank, or left out of the file entirely, is left exactly as it was.

That matters because a rule holds more than a row can: a start and end date, how it combines with other rules, a second condition. None of those have columns. If an import rebuilt the rule from the row, correcting one lead-time message would wipe every campaign date on your site — so it does not.

The same is true of checkout fields, which keep their position, default and placeholder through an import that never mentions them.

If you want to clear something, change it in the control centre. There is no spelling of "make this empty" in a spreadsheet that could not also be a cell somebody forgot to fill in.

A rule a row cannot describe is refused, not flattened

A rule with more than one condition or action exports as a single row holding the first of each. Importing that row back is refused, by name, and tells you to edit it in the control centre instead.

The alternative would be to write it — which is the same thing as deleting the conditions the file could not carry. A two-condition discount would come back matching only its first, applying to the products it was written to exclude, and nothing would have said so.

To create a new rule from such a row, clear its uuid cell. That is you asking for a new one-condition rule, which is unambiguous.

Products by SKU, categories by slug

A match_value that is not a number is looked up here. Write ABC-123 and Praetor finds the product with that SKU on this store; write chemicals in a category condition and it finds that category.

That is what makes a file written against your staging site work on your live one, where the internal id numbers are different. A SKU that does not exist here is reported as a problem on that row — not imported as a rule that quietly matches nothing.

The columns

Every domain declares its own, and the export shows them. For a rule they are:

Column What it means
uuid The rule’s id. Blank means create a new rule.
name What you call it. Required.
status published, draft or archived.
priority Lower runs first. Defaults to 100.
match_field What to test, e.g. product.id, product.category, customer.role.
match_operator in, not_in, is, and the rest of the operators that field allows.
match_value The SKU, slug or value. Several, separated by pipes.
action What the rule does, e.g. lead_time, percentage_off, quantity.

A new row — one with no uuid — that does not say status is created as a draft. Publishing is a decision, not a default.

After those come the action’s own columns — message for a lead time, amount for a discount, min/max/step for a quantity rule. Fill in the ones your action uses and leave the rest empty.

A checkout field row is a different shape: key, label, type, location, options, description, show, require and conditions, where a condition reads customer_role is wholesale and several are separated by pipes.

options holds the choices of a list, separated by pipes. Where the stored value differs from the wording a customer sees, it is written value:label — gf:Ground floor|ff:First floor. A plain word is both.

From the command line

wp praetor csv domains
wp praetor csv export lead_times --file=lead-times.csv
wp praetor csv import lead_times --file=lead-times.csv
wp praetor csv import lead_times --file=lead-times.csv --apply

Without --apply it previews and changes nothing, the same as the screen.

Still stuck? Email [email protected].