Dragon Product Visibility for WooCommerce

Hidden products are no longer named or linked in Store API cart errors, checkout links, the comments feed or address redirects, and category and tag rules can now target every role.

What's new in 1.0.14

• Security: adding a hidden product to the cart through the Store API by its ID now gets a plain "no access" error, instead of WooCommerce's message naming the product and its stock. A WooCommerce checkout link (/checkout-link/?products=...) that names a hidden product is refused as a whole with the same plain message, and nothing is added to the cart.
• Security: a hidden product's address is no longer revealed by redirects (?p=, ?attachment_id=, a mistyped product URL) or by the add-to-cart error, which now sends the visitor to the shop. Reviews of a hidden product are refused, through the review form and through the REST API, and its reviews no longer appear in the site comments feed.
• Fixed: on sites with a persistent object cache, WooCommerce's product and review widgets and the older product grid blocks could show one visitor's product list to another. Visitors with hidden products now get their own list. Widget and product grid output cached before this update clears at the next product save or WooCommerce cache reset.
• Performance: products hidden by a category or tag rule no longer have all their data loaded on every page, which on a large hidden category could exhaust memory.
• Fixed: on Products > Visibility Rules, a role whose id is not all lowercase (for example one added by a membership or wholesale plugin) can now be chosen. Where two roles differed only by capitals, the rule used to be stored against the wrong one.
• Fixed: a grouped product form posted with a non-numeric item no longer causes a fatal error, and a malformed customer list sent to the product save is ignored.
• Multisite: the customer search and the saved customer list on the product screen only show accounts of the current site. Customers from other sites already on a product's list are kept when the product is saved.
• Rules you have already saved, on products and on categories or tags, are unchanged.

Uninstalling now deletes your data only when the delete-on-uninstall opt-in is clearly switched on.

What's new in 1.0.13

• Fixed: uninstall deletes data only when the opt-in is clearly on (1, true, yes or on). A value set by hand to "false", "no" or "off" used to count as a yes and now keeps your data.

Rule pickers only show where they take effect.

What's new in 1.0.12

• The customer and role pickers only appear when a product is restricted, so rules always take effect.
• Bulk rules can target every role.

Security: restricted products are hidden everywhere.

What's new in 1.0.11

• Security: restricted products and their variations are hidden from the store API, the WordPress REST API, product blocks and shortcodes, product images and reviews.
• Visiting a restricted product's address redirects to the shop with a notice.
• Customer names and emails on the product screen need shop manager access.

Translation-ready throughout.

What's new in 1.0.10

• Every screen, email and alert is now translatable, and translations bundled in the plugin's languages folder now load. Counts use proper plural forms, and numbers and dates follow your site's language.
• Product names in the cart notice are escaped.

An interrupted save can no longer make a product visible to a customer you blocked, and a failed save is reported instead of shown as saved.

What's fixed in 1.0.9

• A failed save can no longer make a product visible to someone you blocked. The customer list was deleted before the new one was written, with no check on either step, so a database error part-way through could leave a blocked customer able to see the product while the screen still said "saved". The save now applies its changes in the order that tightens access first, so an interrupted save never leaves the product more visible than it was. Where the database supports transactions the save is reverted on failure; where it does not, each write that landed is undone individually and confirmed. If even that cannot be completed, the notice tells you what is actually stored instead of claiming your previous rules survived.
• The AJAX save checks permission for the specific product. It previously only required the general "edit products" capability; it now also requires that you can edit the product whose rules are being changed.
• Activation only records the database version once the table really exists. Previously the version was stored regardless, so a table that failed to create was never retried. The table is now confirmed first, and a missing table (including one dropped later) is recreated on a later admin page load, checked at most once every five minutes.
• The table definition can now be upgraded in place. It is written in the form WordPress's dbDelta() can compare against the existing table, so future schema changes will apply on update rather than being skipped. No change is made to the table itself in this release.
• Category/tag rules report save failures. On the Visibility Rules screen, adding or deleting a rule whose save did not land was still shown as a success. Both now show an error and leave your existing rules unchanged.
• A failed read can no longer save as a success. If the list of a product's existing customer rules could not be read, the save treated it as "no rules" and committed, leaving the stored rules untouched while reporting success. The read is now checked and the save is refused instead.

No settings or data changes otherwise.

Performance follow-up to the new category/tag visibility rules.

= 1.0.8 =

• Performance: category/tag visibility rules now prime WordPress's term cache for the whole candidate set, so a shop with a large hidden category no longer runs an extra term lookup per product on front-end and Store API requests.

Hide or restrict entire product categories and tags by user role in one place — no more setting visibility product by product.

= 1.0.7 =

• New: category & tag visibility rules. Under Products → Visibility Rules, hide a whole category or tag from chosen roles, or show it only to them, in a single step. Rules on a category automatically cover its sub-categories, and "show only to" also hides the products from logged-out visitors. Rules set on an individual product still take precedence.

Important security fix: restricted products are no longer exposed to logged-out visitors through the Store API, search or sitemap.

= 1.0.6 =

• Security: products restricted from a visitor are now correctly hidden from the WooCommerce Store API, generic site search, and the product sitemap (previously they could leak to guests).
• Performance: visibility checks no longer run one query per restricted product on catalog pages.

Tested and verified on WordPress 7.1.

• Compatibility: tested up to WordPress 7.1.

Small polish release: the WooCommerce-required notice now only appears on the Plugins screen instead of everywhere in wp-admin.

Your data now survives uninstall by default.

Uninstalling no longer deletes the plugin's data unless you explicitly opt in first, so removing it to debug — or coming back later — keeps everything intact. Where the plugin has a settings screen you'll find a new "Delete all data on uninstall" option; leave it off to keep your data.

• Initial release
• Per-customer product restrictions
• Role-based access control
• Direct URL protection
• Cart validation