Hide SKU for WooCommerce: safe setup, failure cases, and rollback

Direct answer

To hide a WooCommerce SKU safely, change only the native public product-page visibility decision and leave the stored SKU untouched. Preserve WooCommerce's original result in administration, REST, AJAX, cron, CLI, feeds, archives, and uncertain contexts. Support the official Product SKU block explicitly instead of deleting data or applying a site-wide CSS selector.

StoreFixKit's Hide SKU for WooCommerce follows that display-only boundary. Free supplies one public product-page switch. Pro adds selected products, selected categories, and individual Show or Hide choices while every SKU remains saved.

Stored SKU and visible SKU are different things

A SKU can be used by:

• the product and variation editor;
• product search and inventory operations;
• imports and exports;
• REST API and WP-CLI integrations;
• order items and emails;
• feeds and reports;
• a shopper-facing product template or block.

Hiding one public display must not disable the first six systems.

WooCommerce's current wc_product_sku_enabled() function exposes the wc_product_sku_enabled filter. WooCommerce also documents an official woocommerce/product-sku block. These are two native rendering paths, and they do not imply that every third-party theme or builder asks the same visibility question.

Why deleting or blanking the SKU is the wrong fix

Blanking the product field certainly removes the public value, but it also removes the identifier from operations that may depend on it. That can affect search, warehouse mapping, import matching, feeds, reports, and order support.

A merchant asking to “hide SKU” normally means:

Keep the identifier for the business, but do not show it to the shopper on this page.

That sentence is the product contract. It does not authorize changing the product record.

Public complaints reveal the real edge cases

The common global filter often solves one native surface but not every frontend renderer. A merchant asked to hide SKU from more than the single product page and was told the remaining work was custom development. Another wanted to retain admin SKUs but hide them for one category and received theme-specific PHP and CSS. A third wanted one product's SKU retained in data but hidden from shoppers and was given product-ID CSS or code options.

These reports show three separate needs:

1. a safe global product-page switch;
2. category and product selection;
3. an explicit individual exception.

They also show why “hide everywhere on the frontend” is too broad. Archives, blocks, feeds, quick views, tables, and apps have different owners.

Fail passive outside a supported public product request

A data-preserving implementation should return WooCommerce's incoming visibility result when any of these is true:

• WordPress is in administration;
• the request is AJAX, cron, REST, or CLI;
• the request is a feed;
• the page is not a public single-product request;
• the product is missing, unpublished, or malformed;
• the context is uncertain.

This prevents a global PHP filter from unexpectedly disabling SKU-dependent administration or integration code.

For the official Product SKU block, filter only that documented block's rendered output, resolve the block's product context, and return the original HTML unless the same public product-page hide rule definitely applies.

CSS hides pixels, not data or ownership

A CSS rule such as .sku_wrapper { display: none; } can appear simple, but it has several limits:

• the SKU remains in page source and may be read by scripts;
• a theme or block may use another class;
• the selector can hide a different component;
• !important rules become hard to override;
• per-product and category conditions need body classes or generated CSS;
• browser output and accessible output can diverge.

CSS can be a theme-level presentation choice, but it is a weak foundation for a plugin promising data-preserving behavior across named native paths.

Test data preservation, not only the product screenshot

Use a disposable SKU and verify it before and after activation:

Also test a simple product, a variable parent, a variation, a product with no SKU, an unpublished product, and a custom builder page.

If a third-party surface still prints the SKU, identify its owner before changing code. Do not broaden the global filter until that surface's data and request context are understood.

Make Pro precedence easy to explain

Free supplies one store-wide public product-page switch. Pro adds bounded exceptions and selections:

1. an individual product can explicitly Always keep native SKU visible;
2. an individual product can explicitly Always hide native SKU output;
3. up to 50 selected products can be hidden;
4. up to 50 selected categories can be hidden;
5. the Free switch is the fallback.

The individual choice wins because it is closest to the product. Use broader setting removes that override.

This model handles common catalog differences without a rule builder, query language, bulk edit, or catalog scan.

Official block support has a precise boundary

WooCommerce's block reference names the official block woocommerce/product-sku. Supporting that named server-rendered block does not mean supporting every block that happens to display a SKU.

A theme or plugin can:

• call WooCommerce's visibility function;
• use the official Product SKU block;
• call $product->get_sku() and print its own HTML;
• fetch SKU through REST and render JavaScript;
• cache custom product markup.

The first two paths are inside this release on supported public single-product requests. The others remain with their owners. StoreFixKit does not intercept REST, mutate product objects, buffer the whole page, or search the DOM.

Resource and failure boundary

The public render already has the product. Free needs one small option read. Pro may read the current product ID, category IDs, and one owned product setting.

It needs no:

• catalog scan;
• SKU query loop;
• product or variation write;
• custom database table;
• cron or Action Scheduler job;
• frontend CSS or JavaScript;
• import or export hook;
• customer cookie;
• telemetry;
• StoreFixKit request from the storefront.

Missing WooCommerce, invalid settings, an unsupported surface, inactive Pro, an expired license, or an unavailable license service returns the previous visibility result. No SKU changes.

The Hide SKU documentation includes real screenshots, exact setup, official-block limits, troubleshooting, rollback, uninstall ownership, and privacy-safe support evidence.

Beginner launch checklist

Record a disposable SKU

Use a non-sensitive test product and write down the exact SKU before activation.

Test the native template and official block

Confirm the classic product meta and official Product SKU block separately. They are different rendering paths.

Verify operations

Open administration, authorized REST, approved import/export, one report, and one historical order. The SKU must remain intact.

Test exceptions

With Pro, test one selected product, one selected category, one explicit Keep visible product, and one explicit Hide product.

Test the off path

Disable Free, deactivate Pro, deactivate Free, and clear caches. Native public output must return and stored data must never change.

Test update and rollback

Move from the previous package to the current one, downgrade, then restore the current package. Version 0.1.2 adds official Product SKU block support; version 0.1.1 does not.

Security and support evidence

Only a user allowed to manage WooCommerce should save global and Pro rules. Product fields require product-edit permission. Every write needs a nonce, capability check, ID validation, and owned-key deletion on uninstall. WordPress's plugin security guidance covers checking capabilities, validating and sanitizing input, and escaping output.

Useful support evidence includes the product ID and URL, simple or variable type, disposable SKU, surface name, expected result, actual result, Free and Pro versions, WooCommerce version, theme or builder owner, cache/CDN, and screenshots. Remove customer data, credentials, order keys, payment details, and full license keys.

FAQ

Does Hide SKU delete or blank product SKUs?

No. It never writes to the SKU field.

Are SKUs hidden in administration, REST, imports, orders, or reports?

No. The plugin deliberately preserves WooCommerce's incoming result outside supported public single-product output.

Does it support the official WooCommerce Product SKU block?

Yes, version 0.1.2 supports woocommerce/product-sku on supported public single-product requests.

Why does a custom builder still show SKU?

That builder may read and print SKU independently instead of using WooCommerce's native visibility function or official block.

What happens when Pro expires?

The Free store-wide switch continues locally. Selected product, selected category, and individual-product rules require an active product-bound license.