Changelog

StoreMaster had no starting point. You activated it, landed on a page headed "This store" listing your PHP version and database schema, and the one piece of guidance said the most useful thing to do next was export your configuration. Meanwhile nothing at all was running on your shop, because nothing runs until you switch it on — and there are thirty-five switches with no suggested order.

That is an inventory, not a beginning.

One question first

StoreMaster → Get started asks what you are setting up: a trade shop, a fast catalogue, made-to-order products, a private catalogue, restaurant ordering, or the routine order paperwork. Choose one and StoreMaster switches on what that kind of shop needs.

Before it does anything, it shows you exactly what will change — by name, not by internal id — including what was already on and, if you are on the free edition, what this build does not include. Nothing changes until you say so, and it can be undone.

It tells you what it has not done

This is the part a setup wizard usually gets wrong. Switching capabilities on is not the same as having a working shop, and StoreMaster cannot know your trade tiers, your prices or your opening hours. Inventing them would put real changes on a real storefront.

So it finishes by telling you what is left to you, in order, with a link to each one: create a trade tier, build the catalogue index, write the access rule that actually closes your catalogue. If a choice only you can make is outstanding, you are told so rather than left believing you are finished.

Fixes & improvements

• The Overview's next step now sends a brand-new shop to Get started, rather than to a list of thirty-five switches.
• Blueprints name the capabilities they turn on, instead of listing internal ids.

A setting you have never saved still does something — StoreMaster falls back to a sensible default, and every settings form declares what that default is. The form did not read it.

So a colour you had never set showed as an empty box, when documents were actually being printed in near-black. A switch that is on by default showed as off. The most likely next step is to "correct" a setting to what it already was, or to save a blank over a working default you were never shown.

Settings forms now show the value that is really in effect, whether you have saved one or not.

StoreMaster's free edition sells three rule-based capabilities — discounts, quantity rules and lead times. The engines that apply them have always been free. The editor that creates them was not: it was part of the premium build.

So a free shop could store, evaluate and apply rules, and had no way to make one.

The rule editor is free

It is the same editor, with the same four steps, the same plain-English summary of what a rule does, and the same check against a real product before it goes live. A free shop gets three sections — Prices and discounts, How much they can buy, Delivery promises — each able to create a rule that actually applies.

The premium edition adds more sections to the same editor rather than replacing it: trade tier prices, who may see what, who gets told, and the advanced discount and quantity families.

A section whose engine is not in your build no longer appears at all. It used to show as a tab that could not create anything.

Fixes & improvements

• The free download is smaller. Premium screens were being shipped inside it — inert, but there — because a comment in free code mentioned one of them by name and the build treated that as a reference.

StoreMaster's menu had twenty-three items and fourteen of them opened the Overview page. That was fixed last week by pointing each one at the right place. This removes the possibility of it happening again, and makes the menu shorter while it is at it.

Nineteen items, each a different destination

Every module now declares where it is configured, in one place, and both the WordPress menu and the control centre's own navigation are drawn from that. They cannot disagree, because there is nothing for them to disagree about.

The menu is shorter because it lists screens, not modules. Six modules are configured in the rule editor and seven on the Settings screen; each used to want its own menu item, which would have meant twenty-eight entries with thirteen of them opening one of two screens. Now there is one Rules and one Settings, and the detail lives inside them.

Every module says where it is set up

The place that detail belongs is the Modules screen — where you are standing when you have just switched something on. Each module now says what to do next: a link to the screen or form that configures it, the shortcode to copy if that is its whole interface, or plainly that there is nothing to set up.

That last one matters. Quick view and purchase orders work the moment you enable them, and a menu item for either could only ever lead somewhere disappointing. Filters and Saved lists are placed with a shortcode, which is now shown to you rather than left to be found in the documentation.

Fixes & improvements

• A module that is switched off no longer contributes a menu item, so the menu reflects the shop you actually have.

The last three menu items that led nowhere now lead somewhere. Every item in the StoreMaster menu opens a screen that exists.

Webhooks

StoreMaster can tell another system when something happens in your shop — signed, retried if it fails, and recorded if it never arrives. All of that worked and none of it could be set up.

You can now add an endpoint, choose which of seventeen events it hears about, and see anything that never got through. A failed delivery can be sent again once the other system is back; nothing is lost in the meantime.

Secrets are never shown back to you after saving. Leave the field empty when editing an endpoint and the existing secret is kept.

Promotions

The report on what your campaigns were carried on had no screen at all, on a module whose entire purpose is telling you what your discounts did.

It leads with the thing that matters: these are orders that carried a campaign, not revenue the campaign caused. StoreMaster cannot know what those customers would have done otherwise, and a number presented without that is a claim it cannot support.

Order emails

Which of WooCommerce's customer emails may carry an extra recipient has always been a setting, and there was nowhere to change it — so you got whatever the default happened to be. The choices are read from WooCommerce itself, so they are named the same as everywhere else in your admin.

Fixes & improvements

• The Variations menu item opens your product list, where a variation matrix is actually configured.
• Filters no longer has a menu item. It renders where you place its shortcode and has nothing to configure, so an entry for it could only ever lead nowhere.

The free edition has always been able to add a question to your checkout — a purchase order number, a delivery instruction, a VAT number — and there was no screen to build one on. The menu item existed and opened the Overview page.

Build a field

Under StoreMaster → Checkout fields you can now add one, choose what a customer sees, what kind of answer it takes, where on the checkout it appears and whether it is required. What a customer enters is saved to the order and shown on it.

Editing one you have already made is a click on its name. Removing it takes it off your checkout and leaves what customers already entered on their orders untouched.

The kinds of answer offered are the ones WooCommerce's own checkout can validate. Anything richer belongs on the product page, where it can be checked properly, and StoreMaster says so rather than offering something that would not work.

The free edition supports one field. When you have used it, the button says so instead of failing after you have filled the form in.

Three things that were built, worked, and could not be reached or believed.

Import / export can import

The screen was called Import / export and had an export button and nothing else. Importing a configuration is a Pro feature, it is on the pricing page, and every piece of it worked — you simply could not get to it from anywhere.

Paste a configuration exported from another StoreMaster site and you are shown what it would do before anything happens: where it came from, whether its signature still matches, how many rules it carries, which settings it replaces, and which modules it would turn on or off. Anything in it that does not exist on this site is listed. Only then can you apply it, and applying runs in one transaction — it either finishes or leaves your configuration exactly as it was.

Order desk shows all your orders

It showed the newest fifty and said nothing about the rest. With 94 orders, 44 of them could not be reached from the screen at all, and the status filter was no way round it. Worse, bulk actions applied only to the fifty you could see, which was never stated.

It now says Showing 50 of 94 orders — page 1 of 2, with Previous and Next, and tells you how many orders an action is about to affect. Changing page clears your selection, because the orders you ticked are no longer the ones on screen.

A refusal no longer looks like an empty product

On the Live preview screen, if StoreMaster could not load a product's areas — because you lacked permission, or the request failed — you were shown exactly what a product with no areas looks like. Same screen, same pixels.

So the natural next step was to draw the areas again and press Save, which replaced the stored areas with the emptiness left behind by the failed load. A refusal became data loss, silently.

A failed load now says so, and nothing can be edited or saved until it has been reloaded.

The Check step promises to show what a rule does before it goes live. It showed a green tick and a price whether or not your rule had anything to do with that price.

It runs as a customer now

Every check ran as a signed-out visitor. There was no way to say otherwise — so a rule that depends on a customer role, which is most trade pricing, could never be verified. The rule correctly did not apply to a visitor with no role, and the step reported success anyway.

There is now an As this customer control. Pick somebody with the role your rule names and you find out what they would actually pay.

The tick means your rule applied

It used to mean the request succeeded. So a rule the price engine had turned down was marked done, and the headline showed whatever price came back — which was another, already-live rule's work, presented as proof that yours worked.

Now the step says This rule applied or This rule did not apply, and only the first is a tick.

And when it does not apply, it says why

The engine has always recorded why it turned a rule down. Nothing showed it.

You now get the reason in plain words — the conditions were not met, its schedule has ended, another rule with a higher priority applied instead — and underneath, each condition with what it wanted and what it actually found, so you can see which one failed rather than guessing.

A rule that is not about price says so

The price preview would happily run a quantity or access rule through the pricing engine and show you a discount, which the real evaluation would never produce. It now tells you that this preview checks rules that change a price, instead of answering a question you did not ask.

Fourteen of the twenty-three items in the StoreMaster menu pointed at screens that did not exist. Clicking one drew the Overview page — no error, no message, nothing to indicate anything had gone wrong. It reads as the plugin being broken, or the click not registering.

Six of them had a working settings form one click away the whole time, so the usual conclusion was that a feature was missing when it was already there.

Where they go now

Access, Order documents, Fast cart, Opening hours, Stock alerts and Cart recovery open their own settings, and the page scrolls to that form and marks it — rather than dropping you at the top of a page holding nine unrelated ones.

Order routing opens the Rules screen, where routing rules live.

Product options opens the product options editor. Its menu item had a one-word difference from the screen's own address and had never worked.

Variations opens your product list, because a variation matrix is set up per product, not shop-wide.

Filters no longer appears in the menu. It has nothing to configure — it renders where you place its shortcode — so an entry for it could only ever lead nowhere.

The catalogue index can be built

Filtering and fast search show nothing at all until an index exists. StoreMaster knew this and said so: *"Build it under StoreMaster → Catalogue index."* That menu item existed and opened the Overview page, which then told you your shop was configured and running.

There is now a real screen there, showing how many products are indexed and whether an index has ever been built, with a button to build or rebuild it. Rebuilding is safe at any time — the current index keeps serving your shop until the new one is finished.

A wrong address says so

If you follow a link to a screen this build does not have — a bookmark, or a module you have since switched off — StoreMaster now tells you, instead of quietly showing the home page.

Fixes & improvements

• Four menu items still have no destination: Webhooks, Promotions, Checkout fields and Order emails. They are listed as known gaps rather than left to be rediscovered, and each now says what it is waiting for.

Two defects, both silent, both about the gap between what the control centre saved and what your storefront read.

A published rule now actually applies

Every rule the editor created was stamped with a kind no part of StoreMaster looks for. You could build a trade discount, publish it, see it listed, check it in the preview — and your shop charged full price. Nothing reported a problem, because nothing was wrong with the rule. It was simply filed under a name nothing asked for.

Four of the five sections were affected: prices and discounts, delivery promises, who gets told, and trade tier prices. Quantity rules happened to be filed correctly and always worked.

If you built rules and concluded StoreMaster did not work, this is why. Open each one and save it again and it will apply.

The editor no longer decides what kind of rule it is making. Each part of StoreMaster declares what it reads, the editor is told, and the server refuses to save a rule that nothing would ever read — with a message saying so, rather than accepting it and staying quiet.

Where a section has more than one kind of rule — access has three, since protecting your whole shop, a category and a single product are different jobs — you are now asked which you mean instead of getting one picked for you.

Product tabs, options and live preview open again

Turning on Product tabs — a free module — silently switched off the permission that four modules check, for everybody, including you. Product tabs itself could not create a tab, Product options and Live preview refused the site owner, and the Delivery promises section of the rule editor was greyed out with no explanation.

The cause was a permission named in a slot WordPress reserves for a different kind of check, which made WordPress treat it as unanswerable everywhere. Fixed, and all four are reachable again.

Fixes & improvements

• The rule sections are named for what they do — Prices and discounts, How much they can buy, Delivery promises, Who may see what, Who gets told, Trade tier prices — instead of showing the internal names pricing, quantity, leadtime, access, notifications and wholesale.
• Module dependency messages name the module: "Enable Catalogue index first" rather than "Enable catalogue.index first".
• A rule section with nothing in this build to read its rules now says so, instead of offering a New rule button that could only produce a rule that never runs.

The rule list — the screen this plugin is mostly about — never displayed a single rule. You could build one, save it, get no error, and find the list still empty. The rule was in the database the whole time and working on your storefront; the screen simply could not see it.

Your rules are there

Fixed. The list shows every rule for the section you are looking at, and a rule you just saved appears in it.

If you built rules in an earlier build and concluded they had not saved, they had. They are all still there and you will see them now.

You can archive a rule

There was no way to remove a rule once you had made one. There is now an Archive action on each row: the rule stops applying, stays in the list, and can be published again whenever you want. Nothing is destroyed.

The list reads like a list

The columns were Name, Type, Status, Priority, Revision. Revision is a database detail and Type only ever repeated the section you were already standing in, so both are gone. Priority now says which order a rule is applied in, rather than showing a bare number.

An empty section explains what a rule is and how to start one, instead of showing five column headings above nothing.

The section tabs said pricing, quantity, leadtime, access and notifications — the names the code uses. They now say Prices and discounts, How much they can buy, Delivery promises, Who may see what and Who gets told.

The first screen suggests something useful

Next step on the overview said *"Export your configuration"*, on every visit, to every shop — it was the fallback that any working store landed on. It also had nothing to click.

It now depends on where you actually are: nothing switched on yet takes you to choosing what StoreMaster should do; modules running with no rules takes you to writing your first one; a configured shop is the only one offered the configuration export. Each is a button rather than a sentence. When something needs attention it sends you to Diagnostics instead of repeating the warning printed directly above it.

StoreMaster's rule builder let you pick any comparison for any field. The price engine could only answer about half of the combinations that produced. The rest — "SKU is greater than SM-100", "Signed in is one of yes", "Product category is between 100 and 200" — saved without complaint, showed a finished tick and a confident plain-English summary, and then never matched anything, ever.

There was no symptom to notice. The rule sat in your list looking correct.

Each field now offers what it can actually be asked

Every field publishes the comparisons it can answer, and the builder shows only those. A category or tag offers is one of and is not one of; a number offers the full range including is between; text offers contains and is; a yes/no field offers is and is not. Nothing else is on the menu, because nothing else was ever answered.

Nothing was removed that worked. Every withdrawn comparison was one that could only ever return "no" — or, in one case below, one that quietly answered a different question from the one it appeared to ask.

The change is enforced in one place rather than two, so the builder cannot offer a comparison the server would refuse, and the API cannot accept one the builder would not show you.

Three that were worse than doing nothing

"Signed in is no" was saved as yes. The value box was free text, and any text at all was read as *yes*. So a rule written to target signed-out visitors targeted signed-in ones instead — not a rule that did nothing, a rule that did the opposite, confidently, to exactly the people it was meant to exclude. Yes/no fields now have a yes/no control, and typed words like no, false and off are understood rather than assumed.

"Product category is Sale" meant "Sale is its only category". Comparing a category, tag or product with is was answered as sole membership, so the rule matched a product filed only under Sale and silently skipped every product filed in two places. It passes on the single-category product you would test with. is one of is the comparison that means what it looks like, and is what the builder now offers. Existing rules are flagged rather than rewritten — see below.

"Quantity is between 10 and 5" saved cleanly and matched nothing. A range whose first number is larger than its second is now refused when you save it.

Rules you saved earlier are pointed out, not quietly changed

Site Health gains a check that reads your rules and names any carrying a comparison that cannot be answered — and separately, any using is on a category, tag or product, with the exact edit to make.

They are named rather than corrected on your behalf deliberately. Changing is to is one of makes a rule match *more* products than it does today, and a discount that starts applying more widely is not a decision StoreMaster should take for you while you are not looking.

Document branding has a screen

The Document branding module has always applied a logo and your colours to invoices and delivery notes, and there was no way to set any of them. It now has a form under Settings: logo from your media library, text and accent colour, whether a refund issues a credit note automatically, and which order emails documents are attached to — that last list read from WooCommerce itself, so it matches the emails your shop actually sends.

Fixes & improvements

• Choosing a different field in the rule builder no longer leaves behind a comparison the new field cannot answer.
• A new condition starts on a comparison its field supports, rather than always on "is one of".
• A condition that can never match no longer counts as finished in the builder's progress summary.
• Refusals name the field as you see it and, where there is one, the comparison to use instead.

A rule you build in StoreMaster's control centre is a promise about what your shop charges. Six places broke that promise: the form asked for one thing and the code read another, so the rule saved cleanly, listed as published, and did nothing — or worse, did something you never asked for.

No released version of StoreMaster is affected. The plugin is not on wordpress.org yet and nothing is running on a live store, so there is nothing to patch. It is written up plainly because the failures were quiet ones, and quiet is the property worth reporting.

A quantity threshold meant the number you typed

"Quantity is at least 3" was reaching the price engine as "at least 0", so it matched every basket. A bulk discount you meant for orders of three or more came off a single item, and nothing anywhere reported a problem.

The cause was the rule builder sending every value as a list, when only "is one of", "is not one of" and "is between" take a list. A single number arriving as a list of one could not be read as a number, and was quietly treated as zero.

The builder now sends the shape each comparison actually takes, and the validator refuses the wrong shape rather than guessing at it. A rule that cannot be understood never discounts anything — leaving your price alone is always the safe direction.

Rules already saved with the old shape are covered too. They are read on every page of your shop, so correcting only new saves would have left the problem running on precisely the shops that had it. Such a rule now declines to apply, and says so on the rule's own screen, instead of applying at zero.

Offers that priced nothing now price

Four of the offers you can build had the same disagreement between the form and the engine, each with its own symptom:

• Take a percentage off, Take an amount off and Set the price did nothing at all when built in the control centre. "Set the price" was the worst of them: it set the price to 0.00.
• Discount the whole basket over a spend threshold matched every basket — the threshold read as zero — and then took nothing off it. A £198 basket with "£15 off over £100" live stayed at £198.
• Buy X for a fixed price and A bundle price at a quantity left the price untouched.

All four now price what the form says they price. The percentage form of the basket-spend discount, which was described but could not be reached from the builder, is there as well.

Copies of an order reached the people you named

A routing rule that copies someone in on an order email had two faults in one field. The addresses you typed were never read, so nobody was copied; and the same field was also being used to decide which emails the rule applies to, so the rule was discarded before it could send. Addresses and email types are now two separate fields with two labels, and rules you saved earlier are read correctly under either.

Check your routes before your suppliers do. A route built before this release did not send, so its addresses have never received anything — and after updating they will. If a route names no email types, it applies to every order email WooCommerce sends for a matching order, and that includes the ones that go to your customer. Open StoreMaster → Order routing, confirm each route's addresses, and choose the email types you actually want it on.

A half-finished offer leaves your prices alone

An offer priced by dividing an amount across a line — "any 3 for £10", "5 for £50" — has a failure the percentage discounts do not: if the price box is empty, zero is not "no discount", it is free. A bundle with the price left blank priced five £12 items at nothing, and "3 for £" gave seven of them away for £11.97. A price typed as 1,000 did the same, because the comma made it unreadable, as did a stray minus sign.

Any offer StoreMaster cannot read a price for now leaves the price exactly as it found it. That is the rule everywhere in StoreMaster: a rule it cannot understand never costs you money.

The basket discount had the same problem pointing the other way — a minus sign in a box labelled "Amount off" produced a £15 *surcharge*, taking a £192 basket to £207. A negative amount off is now no discount at all, never a charge. And a basket rule with no threshold filled in used to discount every basket; it now waits until you finish it.

A rule never decides on something it does not know

StoreMaster has always refused to answer a question about a value it cannot see: a rule reading "basket is over £100" does not apply on a page where there is no basket yet. Three fields broke that promise — billing country, shipping country and order status — by treating "we do not know" as an ordinary empty value.

The visible effect was on the negative comparisons. A rule saying billing country is not GB matched on every catalogue page, every price preview and every simulation, because there is no order on those pages and no country to read. A discount meant for customers outside the UK came off for everyone. The same applied to "is not one of" and "does not contain".

Those three fields now behave like every other: unknown satisfies nothing, in either direction. If you want to ask whether a value is there at all, that is what the is set comparison is for. The same correction applies to product SKU, type and stock status when a rule is evaluated with no product in view.

Fixes & improvements

• Basket value constraints — minimum spend, maximum spend, minimum item count — now apply as configured.
• Advanced pricing and quantity rules are applied when StoreMaster is driven from WP-CLI, not only through the browser. They were skipped there, so a price worked out on the command line could differ from the one your shop showed — and the command line's was the undiscounted one.
• The rule builder shows a single box for a comparison that takes one value, and a list for one that takes several, instead of a list for everything.
• Changing a comparison after typing a value now reshapes the value to match, rather than leaving a list behind a comparison that wants one number.
• The uninstall answer in the plugin's own listing was wrong: it described arming a purge on a settings screen, and no such screen exists in this build. StoreMaster leaves your data alone when you uninstall it, always, and the listing now says so.

Writing a rule used to mean filling in a form: a name, a type, a status, a priority, an overlap setting, and only then the thing you actually came to say. The result was stored settings, and the only way to know what a rule did was to reconstruct it in your head.

Now a rule is four steps, and each one reads back in plain English.

One clause at a time

When · Quantity of this line is at least 3 Then · Take a percentage off Check · See what this does before it is live Name and turn on · Bulk trade discount

Open a step to edit that clause; the rest stay a sentence. A step shows a tick only when there is nothing left to fill in — a condition with no value says so rather than looking finished.

The internal terms are gone. Where the editor used to show draft, priority_first and not_in, it now says "Draft — saved, not running", "The highest-priority rule wins" and "is not one of".

Check it before it is live

The new Check step runs the rule you are writing — unsaved — against a real product and a real quantity, through the same engine your storefront uses, and shows every stage of the price it produces. Including the stages that changed nothing: knowing that no wholesale price applied is as useful as seeing the discount that did.

You no longer have to name a rule before you may find out whether it works.

A rule that did nothing

Building this found a genuine fault, and it is worth saying plainly.

A pricing rule created in the control centre never applied. The editor stored the amount you typed under one name, and the price engine looked for another, so it found nothing, treated it as zero, and left the price alone. The rule saved without complaint and looked entirely correct in the list.

"Set the price" behaved worse. With no amount to read, it set the price to zero.

No released version of StoreMaster was affected — this is the fourth release and the plugin is not yet on wordpress.org — so there is no live shop to correct. The engine now asks the editor's own catalogue which field to read, so the two cannot disagree again, and the tests build rules the way the editor builds them rather than by hand.

0.3.0 made StoreMaster deny a product when it could not read your access rules at all. This closes the same hole one layer in: a single stored policy whose data will not read back.

An access policy keeps its targets — the categories or products it covers — inside its own stored settings. If those settings could not be read, the policy came back describing nothing, and a policy that covers nothing protects nothing. The product it was hiding became visible, and because the read itself had succeeded, nothing anywhere reported a problem.

A policy that cannot be read is now treated the same way as rules that cannot be read at all: the shop denies rather than guesses, the health check goes critical, and you find out. Pricing is unaffected — a rule it cannot read simply does not apply, which leaves your prices exactly as they were.

The check that could not see it

The safeguard meant to catch this had a blind spot, and it is worth naming because it is the more instructive half.

It decided a policy was unreadable by looking at whether the result came back empty. For one of the two stored fields the "nothing here" value is genuinely empty, so that worked. For the other — the field holding the targets, the one that matters — the fallback value is not empty, so the test never fired. The safeguard covered the harmless field and not the dangerous one.

It now asks whether reading actually failed instead of guessing from what came back, which is a smaller and much harder thing to get wrong.