Protected catalogues and a private store Pro

Three shapes of protection, one policy engine:

• Private store — the whole shop is hidden. Your blog, contact page and everything else stay public.
• Protected category — a category, and everything under it, is hidden or locked. Subcategories inherit.
• Protected product — one product, regardless of its categories.

Who gets in

Each policy names the subjects who may see the protected thing:

• anyone signed in;
• a role — a wholesale tier, a members role, anything WordPress defines;
• a specific customer;
• a shared password — one password can unlock several categories, and a category can accept several passwords.

Hidden or locked

Every policy chooses one, and the choice matters more than it looks.

• Hidden (the default) — the product or category is absent. Not in listings, not in search, not in the sitemap, not in a menu, not in the REST API, and a direct link answers exactly as a product that does not exist.
• Locked — it still appears, and opening it asks for the password.

Pick hidden when the existence of the thing is the secret. A padlocked row in a trade catalogue tells every customer what every other customer can buy — which is why hidden is the default rather than the option.

Passwords

Create one under StoreMaster → Access. Give it a label, say what it unlocks, and set how long an unlock lasts.

• The password is stored only as a hash. Nobody, including you, can read it back — if it is lost, issue a new one.
• Entering it correctly gives the visitor an unlocked session, held as an opaque cookie. The cookie is not the password and is not reusable anywhere else.
• Revoking a password ends every session it granted, immediately. "Revoke" means revoke.
• A password that unlocks exactly one category sends the customer straight to it after they enter it.

You need a page containing the [storemaster_unlock] shortcode, and to select it in the access settings. A health check tells you if it is missing.

What a product in two categories does

If a product is in a public category and a protected one, the protected category wins. It is hidden.

You can override that for a specific product, but only when the protecting category has explicitly opted into exceptions. That is deliberate: an exception that could be granted from the product side alone would let a product edit quietly punch a hole in a category policy.

Where it is enforced

Everywhere, and this is the part worth trusting rather than assuming:

catalogue and search queries · product and category pages · menus and widgets · related products · category counts · the WordPress REST API · the Store API used by the Cart and Checkout blocks · sitemaps · feeds · add to cart · and the basket and checkout re-check, so a session that lapses while someone shops cannot be paid for.

Category counts are suppressed entirely when anything is being hidden from that visitor, because a count computed over products they cannot see is itself a disclosure.

Failure behaviour

If the policy store cannot be read, everything protected is denied and a health check fails. That is the deliberate direction: an access rule that is ignored fails open, so the code fails closed instead and tells you.

Catalogue listings are the one part of that you choose, under StoreMaster → Settings → Access:

• Show nothing in catalogue listings (the default) — while policies are unreadable, shop and category listings, product search, category lists, related products and the product sitemap all come back empty. You bought "these products are hidden", and an empty shelf keeps that promise where a full one does not.
• Keep listings working — listings behave as though nothing were protected. Choose this only if a briefly empty shop costs you more than a protected product appearing in one, and expect the health check to say so plainly. It has one limit that is not negotiable: if the fault is bad enough that we cannot tell whether your whole shop is private, listings stay empty anyway.

Either way, protected product and category pages, the REST API, add to cart, the basket and checkout all refuse. So does anything reached by a direct link.

You and your shop managers keep seeing the whole catalogue while this lasts, on the storefront as well as in wp-admin — being locked out of your own shop is not a good position from which to fix it. Sitemaps do not take that exemption, because a crawler reads those, not you.

Administrators are never locked out of wp-admin by an access policy.

Caching

Full-page caches are the one thing that can undo all of the above. If you run one, confirm it does not serve a cached page to a visitor holding an access cookie or a signed-in customer. A health check warns when it detects a cache plugin — it cannot check the configuration for you.