Changelog

Two corrections, both about the product describing itself accurately.

WooCommerce 9.8

StoreMaster's plugin header has always declared WooCommerce 9.8, and 9.8 is the oldest version the test suite runs against. The compatibility check inside the plugin was admitting 9.0.

That combination put stores between the two numbers in a state nobody would choose: WordPress read the header and listed StoreMaster as incompatible, and StoreMaster loaded anyway, on a version nothing tests. A plugin that sets prices should not be running there quietly. On WooCommerce 9.0 to 9.7 it now stays inert and says which version it needs, and the footer, the closing band on the home page and the help centre all name the same number.

If your store is on WooCommerce 9.0 to 9.7 and StoreMaster is working today, updating WooCommerce to 9.8 or newer is all that is needed.

Thirty-six modules, not thirty-five

The module count was stated in eleven places on this site and every one of them said thirty-five. A module — calculated lead-time dates — shipped on 14 September and no count moved with it. The home page, the capabilities section, the features page's domain matrix, the pricing comparison table and the "off means off" panel now all say thirty-six, and the per-domain figures on the features page were one short in two rows.

Nothing about your install changes. The number describing it does.

A quick view that cannot load still offers the product page

The help centre has always said that when quick view cannot load a product, the dialog "says so and offers the full product page". It said so and stopped there. The dialog now carries a link to the product, which is the thing the article describes and the thing a shopper actually wants.

Fixes & improvements

• If your licence lapses, the notice in StoreMaster said the whole plugin became read-only. Only the paid modules' settings do: everything the free edition includes stays editable, and you can always switch a module off. The pricing page said the same thing and has been corrected too.
• The "off means off" panel's description for screen readers listed three modules where the panel draws four, so it described a different picture from the one on screen. The illustration on the features page was described to screen readers as a screenshot of the control centre, which it is not.
• The changelog and the site footer showed the marketing site's version number as the product's. They now show the StoreMaster version an entry shipped in.
• The Explain tools for price and quantity are in the free edition; the pricing page listed them as a Pro feature. What Pro adds is the standalone Explain screen, including access decisions.
• "Unlimited discount campaigns" implied the free edition caps them. It does not, and has not since September; that line now names the discount shapes Pro adds instead.
• Several smaller corrections where the site described the product more broadly than the code supports: what a configuration export carries, what blueprints turn on in each edition, what happens after a trade application is submitted, and what the price trace in the home page hero shows in a free install.

The scope you pick for a quantity rule decides what it counts — each product, each category, the whole store, and on Pro also each variation, each customer role and the whole basket. The list you picked from did not match the list being applied, in both directions at once.

What was offered and ignored

On the free edition the list included Each variation and The whole basket. Neither is applied there, deliberately: a rule using a scope the edition does not understand is left alone rather than applied at the wrong scope, so a rule kept from a Pro subscription stays dormant instead of suddenly limiting the wrong thing. But the list offered them anyway, so a rule set to either saved without complaint and then did nothing. Those two are gone from the free list.

What was applied and never offered

On Pro, Each customer role was missing from the list entirely. The rule engine has always applied it and the help centre describes it, and there was nowhere to choose it. It is on the list now.

Both came from the same thing: the list you choose from and the list being applied were written out separately. They are one list now, so the editor can only offer a scope that will actually be applied.

Fixes & improvements

• StoreMaster → Settings → Product tabs has existed since 1.12.0; the help centre still said there was nowhere to set them. It now points at the screen.

A wishlist and a monthly reorder list are not the same list. A signed-in customer can now keep both, name them, and choose which one "Save to my list" means.

Choosing where things are saved

The saved-list page carries a picker naming the list being saved to. Switch it and the button on every product page files things there from then on — and the confirmation names the list it went to, so there is nothing to guess at.

That target is remembered rather than worked out. Going by whichever list was touched most recently would move it every time a customer opened a different one, and they would find things filed somewhere they never chose.

Naming, starting and removing

The same place renames the list being shown and starts another one. Deleting is offered once there is a second list to fall back on — the list things are being saved to should not be the one that stops existing.

A guest still keeps one list. Theirs lives against the browser session, so a second would be one they could not get back to. Signing in still brings the list they built with them, and it stops expiring.

Fixes & improvements

• An access password now has to say what it opens before it can be created, and a category or product it names has to exist. A mistyped id saved without complaint and then opened nothing.
• The saved-list and product-comparison pages load the stylesheet their markup has always expected, so the lists, the controls and the comparison table are laid out rather than stacked.

Create a password, say what it opens — the whole store, or particular categories and products — and anyone holding it gets in. That is what the help centre has always described, and until now it did not work: a password could be created, stored and revoked, and it opened nothing.

What "opens" means

Three rules, and each is a decision rather than an accident.

A category includes everything beneath it. Protect a parent category and point one password at the parent, and the subcategories are covered too — the same way your access rules already inherit.

The whole store does not include a rule that names one product. A rule written about a single product is a specific decision, and the broadest password in the shop does not get to overrule it. If you want that password to open the product too, name the product as well.

Nothing is whole-store unless you say so. A new password opens nothing until you name what it opens.

If a password does not open your shop

A private shop is protected by a rule about the whole store, so only a whole-store password opens it. Enter a narrower one and the page now tells you the password was right and does not open this shop — rather than returning you to an empty form to try again.

Fixes & improvements

• A password past its expiry date no longer causes a locked page to ask for a password. Nothing could have satisfied it.
• Diagnostics → Explain access now reports that a visitor would be asked for a password in the cases where they actually would be.

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

StoreMaster → 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

StoreMaster → 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: StoreMaster 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 StoreMaster 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 StoreMaster 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.

StoreMaster 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 StoreMaster 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

StoreMaster 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. StoreMaster 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.

StoreMaster 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 StoreMaster 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

StoreMaster → 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.