Changelog

Product tables, product options, documents, quotes, access rules and a dozen settings now have controls. Each one governs something your shop already did — the storefront honoured these settings, and there was nowhere to change them.

Product tables you can actually build

Choose which columns a table shows, put them in order and rename their headings. Let shoppers search, sort and page through it. Turn on multi-add so each row gets a tick box and a quantity, with one Add selected to basket button. Filter by tag, product type and sale status, or name the products to include and leave out — until now only category and stock had controls.

Product options that go where you point them

An option group can be aimed at particular products, categories and tags, with exclusions. Every group used to apply to your whole catalogue, because there was nowhere to say otherwise. Fields can now carry a description, a placeholder and limits — a range for numbers, a length for text — and a field can appear only when another one has a particular answer: engraving text, once engraving is ticked.

The rest of the list

• Documents: see the number the next invoice would get without taking it, and replace a document that needs correcting. The original is kept, and the new one records what it replaces — pressing Issue a second time used to return the document you already had and report success.
• Quotes: each quote shows its history — every step, who took it and when.
• Access rules: choose who may see a protected product or category — anyone signed in, a role, or a particular customer. The role keys on your site are listed beside the field, because a role's key is not its name.
• Trade registration: add, edit and remove the questions an applicant is asked, including dates, numbers, phone numbers and file uploads. Removing one keeps the answers already given.
• Live preview: give each variation its own mock-up, so choosing a colour swaps the image underneath.
• Variation matrix: switch it on for every variable product at once, and set whether it shows as an order form or a price list.
• Promotions: filter the report by date. A date that cannot be read is dropped rather than guessed at, and the screen says which range it used.
• Stock alerts: a product shows how many people are waiting for it.
• Configuration import: refuse the whole import unless everything in it exists on this site.
• Quick view, fast search and fast cart: change the button's wording, the number of characters before suggestions appear, and the corner the basket button sits in.

Access passwords do not unlock anything yet

You can create access passwords, and they are stored and revoked exactly as described — but there is no way in this version to say what a password should open, so entering one lets nobody in. The passwords screen and the help centre now say so. Protect things with a role or a login for now.

Two settings that the shop already honoured and no screen ever offered, and a bulk action that has been quietly passing orders over.

Rename, reorder or hide WooCommerce's product tabs

Praetor → Settings → Product tabs now carries the controls for the three tabs WooCommerce gives every product. Call Description something else, push Reviews down the order, hide Additional information — and choose which tab opens first, including one of your own.

Every one of those settings was read by the storefront already. There was simply nowhere to set them: product tabs takes you to the tab list, and the settings screen they belonged on did not exist in this edition until today. Left empty, each one means "however WooCommerce has it", which is exactly what it meant before.

The order desk says what it changed, and what it did not

Tick some orders, change their status, and the desk now tells you how many changed and how many were left alone. An order it cannot act on — one that has been deleted, or a status your shop does not have — has always been passed over rather than forced, and the screen used to say nothing about it: ten orders in, seven changed, and the same silent success as if all ten had.

You can also add a note to the orders you have ticked, which the desk accepted from the start and had no box for.

Fixes & improvements

• A settings form you cannot save is no longer drawn for you. The screen asks the same question the server asks, so a narrower permission means the form is absent rather than refusing you after you have filled it in.
• The Get started blueprints list was missing Restaurant ordering, which ships and appears on the screen.
• Choosing a blueprint no longer promises a list of settings it would change: blueprints switch modules on, and never change a setting.
• The help centre's account of bulk document issuing and bulk order actions now describes what the screen can reach rather than what the endpoint accepts.

Three things the help centre described and the screens did not offer, and three fixes to behaviour that differed depending on where in the shop you were standing.

You can set your document numbering

Praetor → Order documents now opens a form. Invoices and packing slips each get a numbering pattern — INV-{year}, PS-{year} — and {year} is replaced when a document is issued.

The patterns were always read; there was simply nowhere to type one, so every shop used the defaults whether they suited it or not. On the free edition the menu item led to a screen that was not there at all, and said the module was probably switched off — about a module that was switched on.

Each type counts separately, and so does each pattern: change it and the new one starts at 1. A document already issued keeps the number it was given, because an issued document is never altered.

The order desk remembers how you work

Save the filters you set every morning and pick them from a list: a status, a date range, a search term and the columns you want. Choosing a view fills the filters in and runs it. Open one, adjust it, save it again and you update it rather than collecting near-identical copies.

Export CSV takes the orders your filters match — not just the page you are looking at — with the columns you ticked. And with orders selected you can issue invoices or packing slips for all of them at once, up to 2000, with the count in front of you before anything happens.

A quantity the drawer accepts is one the checkout accepts

If you sell in cases of twelve, or set a minimum of five, the fast cart now holds a customer to that in the drawer itself. Ask for three against a minimum of five and the drawer says so, in the same words the cart page uses, and the line stays as it was.

Before this the drawer took the number, and the customer met the refusal later on a page they had not asked for — which reads as the shop changing its mind. The rules were always applied before an order could be placed; what was missing was being told at the moment you typed it. This covers any quantity rule, including ones another plugin sets.

Fixes & improvements

• Order routing records every route it delivers, so a route that sends only to a supplier no longer sends a second copy when an email is retried. Resending an order email from the order screen deliberately still goes out.
• A configuration export omits customer ids. A rule whose conditions name specific customers arrives with that list emptied and marked, and the file reports how many rules that applied to — so the rule comes across visibly incomplete rather than quietly meaning something else. Worth knowing if you move configuration between a staging site and a live one.
• The spreadsheet export offers only the modules you have switched on. One that is off no longer appears in the picker and then hands you an empty file.
• The order desk can filter by date range and search term, not only by status.

Cart recovery recorded abandoned baskets on the classic shortcode checkout and not on the Checkout block. On the block nothing was recorded and no reminder was ever sent — which, since the block is the default checkout in a current WooCommerce, meant the feature quietly did nothing on most shops.

It works on both now.

Your sentence moved above the form

Recovery refuses to run until you have written the sentence customers see. That sentence used to sit just above the Place order button, which is a spot only the classic checkout has — so putting it in front of the form was what made the block possible at all.

Above the form is a placement both checkouts carry honestly. The classic checkout has its own hook for it. On the block the notice goes *before* the block rather than inside it: Praetor never edits what WooCommerce has drawn, which is the same line it holds over conditional checkout fields.

If you had the notice worded for its old position — "by placing this order…" — it is worth rereading now that it sits at the top.

Nothing else about it changed

A basket is still recorded only after a customer types an address, still never for an anonymous visitor, and still only once per basket: the block sends the address again each time it settles, and Praetor recognises the basket it already has rather than starting another.

Fixes & improvements

• Cart recovery records a basket on the Checkout block, not only on the classic shortcode checkout.
• The consent notice appears above the checkout form on both checkouts.

Cart recovery records a basket on the classic shortcode checkout and not on the Checkout block. On the block nothing is recorded and no reminder is sent.

The help centre said "at checkout" without saying which, and that was not good enough for a feature you might switch on and then wait on.

This is not an oversight waiting on a hook. WooCommerce offers one on the block's own path, and recording a basket there would be a few lines. Showing you *your* privacy sentence is the part that cannot follow: the block draws its form in the browser, and putting a line of text inside it would mean Praetor reaching into the block's markup after WooCommerce has drawn it — which this plugin does not do anywhere.

Recording a basket while the customer never saw the sentence you wrote would be worse than not recording it. So recovery stays where the consent is visible, and the help centre now says so plainly.

Fixes & improvements

• The help centre says which checkout cart recovery works on.

Conditional checkout fields shipped earlier today, and the note that came with them said a field behaves the same on the classic checkout and on the Checkout block. That is true of the field. It is not true of the condition, and the difference is worth knowing before you rely on it.

WooCommerce evaluates these conditions on the Checkout block. The older shortcode 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. Everything else about checkout fields — where they appear, what they accept, how the value is stored and shown — is the same on both.

Fixes & improvements

• The help centre now says which checkout evaluates a field's conditions.

A review of every article against the code found three places where the help centre described something the plugin does not do. None of them changes how Praetor behaves; all three change what you were told to expect.

Quotes: shipping is what you agreed

An offer said shipping and tax were both "calculated exactly when the order is created". Tax is. Shipping is not — and should not be. The shipping figure on an offer is one you negotiated, and going back to your shipping zones at conversion would quietly overwrite it. An offer quoting £15 delivery charges £15.

Tax is the half that is worked out again, because tax is not anybody's to agree: it depends on where the order is going and the rates on the day.

Product tabs: no screen for WooCommerce's own tabs yet

Praetor can rename, reorder and hide WooCommerce's Description, Reviews and Additional information tabs, and set which opens first. There is no screen for it, so today those settings can only be set through the API or a configuration import. Reusable and product-specific tabs are unaffected and have their own editor.

Variation matrix: no bulk editor yet

The article described a variation editor with filtering and batching. The endpoint behind one exists; the screen does not. WooCommerce's own variations panel is the place to edit them meanwhile.

Fixes & improvements

• Three help-centre articles corrected to describe what the plugin does.

A percentage discount could come off a basket more than once.

WooCommerce works a cart's totals out several times in an ordinary visit — on the basket page, at the checkout, and after any change to a coupon or a shipping choice. Praetor recalculated its campaign price each of those times, and each time it started from the figure it had just written rather than from the product's own price. A £20 item at ten per cent off showed £18, then £16.20, then £14.58.

It now remembers what each line cost before any campaign touched it, and works every recalculation out from that. The price a customer is quoted is the price it stays.

The promotions report was counting the same way

Because the line had already been discounted by the time an order was placed, the report recorded what a *second* discount would have taken off — £16 on a £100 item at twenty per cent off, rather than £20.

A fixed-price campaign fared worse: the line already sat at the campaign's price, so there was nothing left to take off and the campaign was left out of the report altogether. Both now record what the campaign really did.

Fixes & improvements

• A campaign discount is applied once per basket, however many times the totals are worked out.
• The promotions report records what each campaign took off, and no longer omits fixed-price campaigns.

A shop manager adding items to an order on behalf of a trade customer was getting their own price, not the customer's — so a manual order for a wholesale buyer was written at the retail figure.

Praetor works a price out for a *customer*, and everything it needs was already there: the decision it makes carries whose decision it is, and the role lookup reads that. What it did not do was ever put the buyer in. It asked who was signed in, and on the admin Add item(s) screen that is the member of staff.

It now resolves the buyer from the order being edited, so a trade customer's manual order matches what they would have paid themselves.

Fixes & improvements

• A manual order placed for a trade customer is priced for that customer rather than for the member of staff placing it.

Spreadsheet export and import now cover trade prices and order routing.

Trade prices are the case the feature was built for. A shop running three tiers over four hundred products has twelve hundred of them, and they arrive from the buyer as a spreadsheet in the first place — so keeping them in one was always the sensible thing and was not possible until now.

Everything the other domains do applies here: each row carries its own id, so a file you edit updates those prices instead of making copies of them; only the columns you filled in are applied; and a file with a bad row anywhere is refused whole.

Fixes & improvements

• Three trade-price actions were offered by the discount rule editor, which has no way to apply them — a campaign built with one did nothing at all. They now belong to wholesale pricing, where they are read.
• Wholesale pricing and order routing declared what their rules can DO only on storefront requests, so anything asking in wp-admin saw a module with rule types and no actions.
• Access policies, option groups and document numbering are deliberately not spreadsheet domains, and the help centre now says so rather than leaving you looking for them.

"Ships in 3-5 working days" asks a customer to do the arithmetic, and they get it wrong — they count Saturday.

Write the promise with a placeholder instead:

> Ships by {date}

Fill in Working days underneath, and Praetor works out the date. It appears wherever the lead time already does: the shop listing, the product page, the basket, checkout, the order and the order emails. {days} works the same way, for wording like "Ships in {days} working days".

It counts around the days you are shut

Praetor → Settings → Lead time dates is where you say which weekdays you never dispatch on, and which dates — bank holidays, the Christmas shutdown, a stocktake week.

A promise never lands on one of those, and a promise made *on* one counts from the next day you are open: an order placed on a Sunday afternoon with a one-working-day promise says Tuesday, because Monday is the day it is picked.

Dates are worked out in your shop's own timezone and in calendar days, so neither the clocks changing in October nor a customer ordering from another continent moves the answer.

The date is recorded when they buy

The resolved date goes onto the order line at checkout, exactly as a static message already does. Editing the rule next week does not rewrite what somebody was told last week.

Fixes & improvements

• A lead-time message that asks for a date it cannot work out now prints the wording without it, rather than showing the placeholder to a customer.
• The help centre said messages that depend on the variation or the stock state were Pro. They are not, and never have been — those conditions are in every edition, and the article now says so.
• Two variations of the same product no longer share one lead time. A variable product whose variations carried different promises showed whichever was worked out first, on every row of a variation matrix — and that was the one written onto the order.
• Diagnostics reports any published message containing a placeholder nothing on the site fills in, so a promise that quietly stopped being completed is something you find out about.

A configuration export took the first hundred rules of each kind and stopped.

If you had fewer than a hundred pricing rules, fewer than a hundred quantity rules and fewer than a hundred lead times — which is most shops — your exports have always been complete and nothing about them changes.

If you had more, the file was short, and it did not say so. That is the file you keep as a backup and restore from, so the day it mattered would have been the day you found out. It now contains every rule.

Fixes & improvements

• A configuration export contains every rule, not the first hundred of each kind.

Setting up five hundred lead times one at a time is not a job anybody should be asked to do in a browser. Praetor now speaks CSV.

Take it out

Praetor → Import / export → Spreadsheets. Pick what you want — lead times, quantity rules, discounts, checkout fields — and export it. The columns are shown before you download anything, so you can hand them to whoever keeps the spreadsheet.

The file opens properly in Excel, accents and currency symbols included. And every row carries its own id, so a file you edit comes back as changes to those rules rather than as a second copy of each one.

This half is in every edition, free included. A merchant who cannot get their configuration out is locked in, and that has never been how this plugin works.

Put it back

Pro reads the file back. Paste it and Praetor tells you how many rows are new, how many are changes, and which ones have a problem — before anything is written.

Products are matched by SKU and categories by slug, so a file written against a staging site works on the live one where the id numbers are different. A SKU that does not exist here is reported as a problem on that row, rather than imported as a rule that quietly matches nothing.

And a file with a bad row anywhere is refused whole. Not the rows before it, not the rows after it. Half an import is worse than no import: it leaves a configuration nobody designed and no way to tell by looking which half you have.

There is a command line too:

wp praetor csv export lead_times --file=lead-times.csv

An empty cell means "I did not touch this"

A row whose id 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.

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 — and none of those have columns. Correcting one lead-time message does not wipe your campaign dates.

It tells you what a row could not carry

A rule with more than one condition does not fit a row, so it exports with the first of each — and Praetor says how many of those are in the file rather than letting it look complete.

Those rows cannot be imported back either. Writing one would be the same thing as deleting the conditions the file could not carry, and that is not something to guess at: the import refuses it by name and points at the rule.

Fixes & improvements

• An exported value beginning with =, +, - or @ is written so a spreadsheet shows it rather than running it as a formula.
• A list of choices keeps its stored values through an export and import, not just the wording customers see.
• An export contains every rule, not the first hundred.
• A new row that does not say otherwise is created as a draft.
• A row with more values than there are columns is reported rather than being quietly cut short — that is almost always a comma inside a value that needs quotes around it.

A checkout field used to be all or nothing: once you added a purchase order number, every customer saw it, and if you made it required every customer had to fill it in — including the person buying one item on a card.

A field can now depend on the basket. Under When it applies, choose whether it shows always or only when the basket matches, and whether an answer is required never, always, or only when the basket matches.

What a field can depend on

Four things, each of which can be *is* or *is not*:

• a product in the basket
• a category in the basket — including anything filed beneath it, so a condition on Chemicals also covers Solvents
• the customer's role
• the shipping country

Set more than one and the basket has to match all of them. So "require a purchase order number when a wholesale customer buys from Chemicals" is one field with two conditions, and everyone else checks out without ever seeing it.

It is WooCommerce that decides

Praetor writes the conditions into the field's definition and WooCommerce evaluates them against the basket. That is why the field appears and disappears as a customer changes what they are buying on the Checkout block, and why nobody can be refused for leaving empty a field they were never shown.

Fixes & improvements

• The requirement of a checkout field is now set in one place. The old always-required tick box sat beside the new setting and answered the same question, so a field set to "require only when the basket matches" could still be required for everyone.
• The checkout fields list says When the basket matches for a conditional field, instead of reporting it as not required.
• The help centre no longer says the free edition supports one checkout field. That limit was removed on 3 September and the article had not caught up.

Praetor's modules are meant to be genuinely off when you switch them off: no code running, nothing hooked, nothing queued. The first two were true. The third was not — a module that scheduled recurring background work kept that work scheduled after you disabled it, and deactivating Praetor entirely did not stop it either.

Nothing was harmed by it: the jobs ran against a module that was no longer listening and did nothing. But a WordPress site should not carry schedules for software that is switched off, and if you had turned off abandoned-basket recovery you would reasonably expect it to stop having an hourly job.

Turning a module off now cancels that module's jobs, and deactivating Praetor cancels all of them.