Changelog

A shopper often knows the colour, the material or the range — and not what you decided to call the thing. Until now the search box matched product names and SKUs, so those shoppers got nothing.

With the catalogue index built, the same box now also matches a product's categories, tags and attribute values.

Names still win

A product *called* "Bracket" ranks above a product merely *filed under* Brackets, and it is not close: one word in a title outweighs several matching categories. That ordering is the point — without it, a broad category would drown the product somebody was actually searching for.

An exact SKU still outranks everything, which is what pasting a part number means.

What it leaves out, on purpose

Parent categories. Filtering by a parent finds everything beneath it, which is right for a filter — but in a search box a top-level category covering most of your catalogue would match nearly every product equally, and that is no more useful than matching nothing.

Nothing to configure, and nothing changes for stores without the index: there, search matches names and SKUs exactly as before.

Live preview did not work on the storefront. The product appeared on the canvas, but there was nothing to type into and nothing to upload with, so a customer could never see their engraving or artwork on the product — and no design was saved to the order either.

It works now.

What a customer sees

Each preview area you set up gets the controls you allowed it, and only those:

• a text box where the area accepts text, respecting the character limit you set
• an upload where the area accepts a picture
• sliders to move, resize or rotate — whichever of those the area permits

Type, and the canvas updates as you go. The design is saved with the order as the composition rather than as a flat picture, so it can be re-rendered at any size for production.

If you already sell personalised products

Nothing to configure. Your existing preview areas gain their controls the moment you update, using the settings they already have.

And if you have been wondering why nobody ever personalised anything: this was why. We are sorry — it should not have taken this long to find.

The release before this added a Site Health check warning that, if you used access rules without building the catalogue index, a search could return fewer results than it should.

That was wrong, and the check has been removed.

Searches already apply your access rules before counting out results — the products a shopper may not see are excluded when the matches are gathered, not afterwards — so the situation the warning described does not arise. If you saw it, nothing was wrong with your store and nothing needed doing.

We would rather tell you this than quietly drop the check. A warning you acted on for no reason costs more than the one we were trying to save you.

If you use access rules and have not built the catalogue index, a search can return fewer results than it should. Nothing restricted is ever shown — that part was never at risk — but a shopper can see a short list where there were more matches they were allowed to see.

Site Health now says so, and tells you the fix: build the index.

Why it happens

Without the index, a search asks for a batch of matches and then removes the ones this shopper may not see. If enough of that batch was restricted, what is left is short. With the index built, the rules are applied first and the results are counted out afterwards, so the list is the right length.

It is the kind of thing nobody notices, because a short list looks exactly like a store with less in it.

Product tables can now show a product's choices in the row. Three attributes and forty combinations is exactly where a row per variation stops being readable — this keeps one line per product and puts a menu on it for each thing to choose.

Choices in the row

Open a table, set Products with variations to *Choices in the row*, and each product with options gets its menus on the line. Pick from them, type a quantity, and add — without opening the product page.

There are now three ways to handle a product with options, and you pick per table:

• Link to the product page — the default, and what tables have always done.
• One row per variation — best when there are a handful and your buyer wants to see every price at once.
• Choices in the row — best when there are many, or several attributes.

It works with JavaScript off

The menus are part of the order form, and the choice is matched to a variation when you submit. Nothing depends on scripts loading, which matters on a trade order form that someone is working down at speed.

If a menu is left unanswered, or the combination genuinely does not exist, that line is not added and the product is named so you know which one to go back to. The rest of the order goes through — one unfinished line does not cost you the other thirty.

A product with sixty variations meant sixty rows to open if you wanted to move every price, or clear every sale, or take a line out of stock. There is now a screen for it.

Variations

StoreMaster → Variations. Choose a product and its variations are listed with SKU, price, stock and whether each one is enabled. Tick the rows you want, choose what to change, and apply.

You can set the regular or sale price, stock quantity and status, SKU, weight, image, and whether a variation is enabled. Leaving the value empty clears the field — which is how you take a sale price off the whole product at once.

It changes the rows you ticked and only those. There is no "apply to everything matching the filter", because a filter re-checked on the server can disagree with the rows you were looking at when you pressed the button.

It tells you what it did not do

If WooCommerce refuses one — a duplicate SKU is the usual reason — that variation is reported as left alone rather than quietly skipped. "12 changed, 3 left alone" means exactly that, so you know to go and look at three of them.

Large products are edited a page of 100 at a time, so a product with 900 variations does not become one request that times out half way through.

The matrix settings have a screen too

Whether the storefront matrix replaces WooCommerce's variation dropdowns, and whether it behaves as an order form or a price matrix, could be stored but not set from anywhere. Both are now on the same screen, with the attributes to use down the side and across the top.

A product table could show a product with variations, but not sell one. The row offered a link to the product page, so a buyer who already knew they wanted the large one had to open that page and choose it there — on every line of the order.

A row per variation

Open a table and pick how products with variations should appear:

• Link to the product page — what tables have always done, and still the default. Nothing you have already built changes.
• One row per variation — each variation gets its own row, with its own name, SKU, price and Add button.

In the second mode a buyer works straight down the form, typing quantities against the exact things they want, and submits once. For a trade customer reordering forty lines, that is the difference between a form and a chore.

Variations that cannot be bought are left out, so the table does not offer something that will be refused at the basket. A product with nothing available at all keeps a single row and its link, so it never disappears on you without explanation.

Rows per page still counts products

Worth knowing before you set it: a page of ten products can draw forty rows if each has four variations. The page is longer than the number suggests — it is not showing more products than you asked for.

Product options could ask for a line of text, a date, a choice from a list. They could not ask for the photograph — which is the one thing a personalised product usually needs.

A new option type

Add a field of type An image the customer uploads. It appears on the product page as an ordinary file box. JPEG, PNG and WebP, up to 12 MB; anything else is refused with a message the customer can read rather than a silent failure.

What happens to the file

It is re-encoded, not stored as sent. The bytes are decoded, checked and written out again as a fresh image — so a file that merely calls itself a picture does not survive the trip.

It is kept outside your public uploads folder, where no web address reaches it. That is why the order screen shows the customer's own file name instead of a link you could paste anywhere: opening one needs a signed address that expires.

An upload that never reaches an order is deleted after seven days. Once it is on an order it stays as long as the order does.

What the order keeps

The order records which file was uploaded and what it was called, not a copy of the image buried inside the order. An order from years ago still points at the right picture rather than at a stale copy of it.

Fixes & improvements

• A refused upload now says why. Before, an optional field left empty by a rejected file passed validation quietly, and a customer could reach the basket believing their photograph was attached.

A filter panel drew one thing: a list of links. It can now draw five more.

Pick a style

“ [storemaster_filters facets="cat,stock,price" style="checkbox"] “

• label — links, the default, applying as soon as they are clicked.
• checkbox — several values at once.
• radio — one value, with an Any to clear it.
• dropdown — the same in a select, for a facet with a lot of values.
• image — the category picture you already set in WooCommerce, beside the name. A category without one shows its name as usual, so the list never has a hole in it.
• range — two number boxes, which is what price has always used.

Set one style for the panel, or pick per facet with styles="cat:image,stock:dropdown".

One button, not six

As soon as any facet uses checkbox, radio or dropdown, the whole panel gets a single Apply filters button — including the price boxes, which join the same form instead of keeping their own. Panels made only of links and images carry on applying the moment they are clicked.

A style this plugin does not have falls back to links. A typo in a shortcode should cost you the style you asked for, not the filter.

There is no colour swatch

WooCommerce does not store a colour against an attribute term. We could only invent one, or read a setting that belongs to another plugin — and a swatch showing the same grey square for every value would be worse than not offering it. The image style exists precisely because the opposite is true: category pictures are already yours, already set, already where you expect them.

A quantity rule set to Each product counted one basket line at a time. So a maximum of ten refused eleven of one size, and then accepted ten of one size plus ten of another — twenty of a product you had capped at ten.

It now counts the product across the whole basket, which is what the setting has always said.

Read this before you update

This can refuse baskets your shop accepts today. That is the point of the change, and it is still a change: if you have a per-product maximum that customers routinely reach across several sizes, they will start being stopped at the number you set.

The minimum moved the same way, and that direction only ever helps: three of one size and two of another now satisfy a per-product minimum of five, where before they were refused against a total the basket plainly met.

What has not changed

A rule scoped to a variation still counts that variation on its own. That is what a variation rule is about, and counting its siblings would refuse a second size for the sins of the first.

Rules scoped to a category, a customer role or the whole store still count one line at a time. Each of those needs its own answer to "ten of what?" — every product in the category? the whole basket? — and we would rather decide that deliberately than guess at it and change your shop twice.

Approving a trade application used to tell the applicant nothing. Neither did turning one down.

Silence was the old behaviour

Someone applied, you reviewed it, you decided — and the person who had asked heard only what WordPress sent them when they signed up. If you approved them, the first they knew was noticing the prices had changed, assuming they came back to look. If you turned them down, they waited for an answer that had already been given.

Five emails now go out: application received, to them and to you, and approved, turned down and suspended, to them.

All five are yours to rewrite

Open Trade emails. Every box starts filled with what would actually be sent, so you can read the wording before deciding whether to change it — rather than facing an empty field that implies nothing goes out.

Clear a box and ours comes back. None of them is ever sent empty.

You can use {name}, {site}, {tier}, {reason} and {login}. The screen lists them, because a placeholder that does not exist is printed to your customer exactly as you typed it.

Fixes & improvements

• {reason} is the note you wrote with the decision. Leave it blank and the space closes up, instead of leaving a gap in the middle of the message.
• Changing only an email's subject keeps our wording for its body, rather than taking the body away with it.

Yesterday's release fixed five emails that only spoke English. Looking for more of the same turned up the errors themselves.

Where they were

When a customer uploads a photo for a personalised product and it is refused — too large, wrong format, did not finish arriving — the sentence explaining why was English, whatever language the shop sells in. The same was true of every refusal around quotes: an offer that has expired, one that has already been answered, a request with nothing in it. And of the messages shown to you when a configuration import is turned down.

All of them are translatable now.

Why escaping them would have made it worse

The obvious fix is to escape these strings where they are written. It is the wrong one here: they are already escaped where they are shown, and escaping twice turns an apostrophe into '. A French or Italian translation is full of apostrophes — so the fix would have broken the languages it was for.

Five messages still used the old name

The rename to StoreMaster reached every string that could be translated. These five could not be, which is exactly why they were missed — including the one that told you a file was "written by a different version of StoreMaster".

Fixes & improvements

• One message is deliberately left untranslated, and now says so: a failure to create the upload directory is a server fault that only ever reaches a log, and putting it in the translation file would offer it to a reader who can never see it.

If your store sells in a language other than English, some of the email StoreMaster sent on your behalf was arriving in English anyway.

Which ones

Three went to your customers: the back-in-stock confirmation, the back-in-stock alert, and the abandoned-basket reminder. A fourth, the quote offer, told the customer in English that their prices were not being held — a sentence that is there precisely so nobody is surprised later, and which only works if it can be read. Two more went to you: the trade-application notice and the quote-request notice.

The back-in-stock emails were the strangest of them. Their subject was translated and their body was not, so a reader was greeted in their own language and then addressed in somebody else's.

All of them are now translatable, with the placeholders ordered so a translator can move them around the sentence.

Fixes & improvements

• A build check now reads every function in the plugin that sends email and refuses one that contains an English sentence it cannot translate. It is scoped to the whole function rather than the send itself, because a message is usually assembled line by line above it — which is exactly where these were hiding.

You can set up a trade tier, price it, and hide what it should not see. Until now the only way to check any of that was to keep a second account and log out.

Preview, without becoming anybody

Open the wholesale screen, pick a tier, press Preview. Visit your shop and the prices — and what you are allowed to see at all — are that tier's. A bar along the bottom of every page says which tier, and offers to stop.

Nothing signs you in as anyone. You stay yourself: your account, your capabilities, your admin bar. The only thing that changes is what FileDeck Store Master's pricing and access engines are told about the shopper.

It stops at the basket, on purpose

Preview applies to the catalogue, product pages, quick view and tables. It does not apply to your basket, the checkout, the Store API, or anything in wp-admin.

So a trade price you are previewing cannot end up on a real order — including a manual order you happen to be writing at the time. If your basket shows retail totals while the shop shows trade prices, that is the line being held rather than a fault.

Fixes & improvements

• Preview ends by itself if you lose the capability that granted it, or if the tier is deleted — there is no stale state to remember to clear.
• A previewed page is never cached for anybody else.

A wholesale tier already decided the price and whether it was shown with tax. It now decides three more things.

Coupons, delivery and payment, by tier

Open a tier and you can hide:

• Coupons — removes the box, and refuses a code typed anywhere else. A retail offer that reached a trade buyer's inbox stops working for them, which is the point. Hiding only the box would be an invitation rather than a setting, so it is one switch for both.
• Shipping methods — the ones a tier should not be offered. Ticking a method hides every instance of it across your zones.
• Payment gateways — the same, for how a tier may pay.

What you can tick is what your store actually has installed, read from WooCommerce when the screen opens. You cannot tick a gateway you do not run, and one you add later stays visible to everyone until you say otherwise.

The last one is never hidden

If what you ticked would leave a customer with no delivery method to choose, or nothing to pay with, nothing is hidden and the shop behaves as before.

A misconfigured tier should cost you a setting that did not apply. It should not cost you a checkout nobody can finish.

Tiers can be edited

They could only be created before. Everything on a tier — its name, its description, how prices are shown and now what it hides — can be changed after the fact, from the same screen.

Fixes & improvements

• The tier table shows what each one hides at a glance, rather than making you open it to find out.