Changelog

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. StoreMaster now speaks CSV.

Take it out

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

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

StoreMaster'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 StoreMaster 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 StoreMaster cancels all of them.

StoreMaster has always been placed with shortcodes, which is a strange thing to ask of anyone on a modern WordPress: the editor has been block-based since 5.0 and the default theme since 6.0, so putting a product table on a page meant finding the shortcode block and typing into it.

There is now a StoreMaster block. Insert it, pick what it should show — product search, a product table, filters, the variation matrix, a saved list, opening hours, the quote basket, the trade registration form, the catalogue unlock form — and set that surface's options in the sidebar. The preview is the real thing, rendered by your site rather than an approximation drawn in the editor.

The list only offers what your site actually has. A surface whose module is switched off, or that is not part of your edition, does not appear — so nothing in the picker is something you cannot use.

Your existing shortcodes keep working exactly as they are. The block builds the same shortcode behind the scenes, which is deliberate: there is one implementation of every surface, so the block and the shortcode cannot drift into showing different things.

Pro has advertised tiered quantity pricing for some time, and the rule editor never offered it — the pricing engine knew how to apply tiers and there was no way to create one. That is fixed.

A discount rule can now carry up to three quantity tiers: from ten take five per cent, from fifty take fifteen, from a hundred charge a flat unit price. The highest tier the quantity reaches wins, and below the lowest tier the normal price stands rather than a guessed one. Each tier can take a percentage, a fixed amount per unit, or set the unit price outright.

Three tiers is what the rule editor can ask for today; the engine reads more, so a rule built by the command line or brought in from another site keeps working.

WordPress has built-in tools for the two requests a customer can make about their own data: send me a copy, and delete it. Until now StoreMaster took no part in them. A shop owner answering a request got an export that looked complete and quietly left out everything StoreMaster held, and a deletion left it in place.

StoreMaster 1.3.0 registers with both tools. An export now includes the extra addresses a customer asked to be copied on their order emails and the answers they gave to your checkout questions; with Pro it also covers back-in-stock alerts, saved lists, abandoned baskets, files they uploaded with an order, catalogue access they were granted, and quote requests.

Two things are deliberately kept, and the tool tells you so rather than pretending otherwise. Checkout answers stay on the order, because the order is a record you are required to keep — they go when the order goes, under your own retention settings. Quote requests are anonymised instead of deleted: the personal details are cleared and the record of what you offered, and for how much, survives.

Pro gains the seventh discount shape: buy a number of qualifying items and get one or more of them free. You set how many they have to buy and how many they get, and whether the free item is the cheapest qualifying thing in the basket or another of whatever they bought most of.

The gift arrives as its own basket line at no charge. If the basket stops qualifying — they remove something, or the item goes out of stock — the gift goes with it, while the shopper can still see it happen. If they take the gift out themselves it stays out, rather than reappearing on the next page.

This shape has been described on the discounts documentation page for some time and was not actually present in the software. It is now, and it is covered by tests that put real items in a real basket and check what the shopper is charged.

Fixes & improvements

• The advanced discounts health check used to report every discount family as available without checking. It now asks the rule editor's own list, so anything documented but not registered is reported as a problem.

No change to anything you can see. Three comments inside StoreMaster described a PDF renderer in the Pro edition that has never existed — invoices, packing slips and credit notes are accessible printable HTML in both editions, which every browser saves as a PDF, and that is what every page on this site has always said. The comments have been corrected so the code agrees with the product.

StoreMaster 1.1.7 removes the last places where the free edition described itself as a limited version of something else. None of it was a real limit — the caps went in September and nothing has been gated since — but the software still said otherwise in a handful of places, and saying it is enough to make it true for anyone reading.

The import screen previewed a configuration file and then showed an "Apply" button that could never be pressed. That button is gone: the screen shows what the file contains, and says so, without offering something it cannot do.

The setup checklist listed features that are not part of this build and marked them unavailable. It now lists the steps this build can actually do. A step whose module is simply switched off says so, and tells you to switch it on.

Several screens and help texts described a limit as belonging to "this edition" when the same number applies to both, and can be changed on your own site. They now say what the limit is, without the implication.

Fixes & improvements

• Invoices and packing slips download as documents again. They had been arriving as a blank page: the file was being sent in a format that broke its own stylesheet, so the browser rendered nothing.
• The free download contains no licensing code at all, rather than licensing code that never ran.
• Translations load the way WordPress loads them for every other directory plugin, which also removes a notice on WordPress 6.7 and newer.

The slide-out basket has never worked. Turning it on changed nothing: clicking a basket link went to the cart page exactly as it would with the feature switched off, and nothing ever slid out. StoreMaster 1.1.5 fixes it, and no setting needs changing — if you had it enabled, it starts working when you update.

Two separate faults, both in the same feature:

The panel's markup was written to the page *after* the script that drives it, so when the script ran there was nothing there to attach itself to and it stopped without a word. Every click it was supposed to intercept simply went where the link pointed.

Separately, "open the basket when something is added" was listening for the wrong announcement. WooCommerce has two add-to-cart buttons — the classic one and the newer block one — and they announce a successful add differently. Only the classic announcement was being heard, so on a block theme, which is what a new WordPress site uses, adding a product never opened the basket even once the first fault was fixed.

Fixes & improvements

• The fast cart panel opens when you click a basket link, and closes with Escape.
• Changing a quantity or removing a line in the panel updates the real basket.
• Adding a product from the shop opens the panel, on classic and block themes alike.

StoreMaster 1.1.4 is a maintenance release. It is a routine hardening pass over the parts of the plugin that decide who may see what — access policies, the REST endpoints, the catalogue filters and file uploads — together with the checks that keep those decisions honest as the code changes.

There is nothing to reconfigure, and no rule, policy or price behaves differently afterwards.

Fixes & improvements

• Security and reliability improvements throughout.
• A webhook endpoint must be a publicly reachable address; one pointing at the same machine or at a private network is refused when you save it.