DEV Community: Eren Labs

Five WooCommerce Back-Office Workflows That Need More Than a Generic Manager Plugin

Eren Labs — Tue, 25 Aug 2026 21:07:48 +0000

Disclosure: I build the Eren Labs plugins mentioned below. They are free on WordPress.org. This post is about the operational design problems behind them—the checklist is useful whether you use my plugins, another tool, or custom code.

WooCommerce is excellent at being the system of record for products, orders, customers, and stock. The difficult problems tend to happen around the edges: staff counting shelves, a cashier selling in person, a catalog that must not reveal prices, or a merchandiser maintaining hundreds of variations.

After building tools for these workflows, five patterns kept appearing.

1. Physical inventory needs a frozen baseline

A stock editor and a stocktake tool are different things.

During a physical count, new online orders may still change WooCommerce stock. If the comparison uses the live number, the variance moves while staff are walking the shelves. A reliable stocktake therefore needs:

a snapshot of the expected quantity at the start;
blind count entry, so staff do not simply confirm the expected number;
barcode, SKU, and name lookup;
an audit trail of expected, counted, and adjusted values;
a reversible adjustment rather than an opaque bulk overwrite.

That is the model behind Stocktake for WooCommerce.

2. A retail POS should create native WooCommerce records

The easiest POS to demo is often the hardest POS to operate: a separate catalog, separate inventory, and a sync layer that becomes one more failure point.

For a WooCommerce-first store, an in-person sale should ideally become a normal WooCommerce order and use the same stock rules as the online shop. Returns, receipts, taxes, barcode lookup, and reporting can then follow the store's existing data model instead of being reconciled later.

Eren Labs Retail POS for WooCommerce follows that Woo-native approach.

3. Variation creation is a matrix problem

WooCommerce's default variation workflow is workable for a few combinations. It becomes expensive when a product has several attributes and every row needs a price, SKU, stock state, and quantity.

The useful abstraction is a matrix:

Choose the attributes.
Generate valid combinations.
Edit price, SKU, and stock per row without opening dozens of panels.
Optionally generate predictable SKUs.
Decide explicitly whether variations have independent stock or share the parent quantity.

Quick Variable Products puts that workflow on one screen.

4. Dynamic categories need composable rules

"Put discounted products in this category" sounds easy until the rule becomes:

In stock AND (brand is A OR brand is B) AND NOT tagged clearance.

A practical rule engine needs nested AND/OR/NOT groups, a preview before applying changes, scheduled refreshes, and a clear policy for products that were assigned manually. Silently removing a merchandiser's manual choices is worse than leaving a category slightly stale.

Smart Categories for WooCommerce is built around those safeguards.

5. Catalog mode is a data-leak problem, not a CSS problem

Hiding the price element in a theme template does not hide the price.

Depending on the store, price data may still appear in:

HTML and block-theme output;
structured data used by search engines;
WooCommerce Store API responses;
REST API responses;
GraphQL responses;
variation data embedded in the page;
caches or fragments generated before the visibility rule changed.

A serious catalog or request-a-quote mode must treat every surface as part of the boundary. If quote requests are needed, representing them as native WooCommerce orders also avoids creating a second customer and reporting system.

PriceVeil for WooCommerce applies that multi-surface model and includes a native request-a-quote flow.

The broader lesson

The safest WooCommerce operational tools tend to share three qualities:

they preserve WooCommerce as the source of truth;
they make bulk changes previewable and reversible;
they account for concurrent activity instead of assuming the store is paused.

I maintain these projects at Eren Labs. If you test one and find an edge case, especially around blocks, APIs, caching, or concurrent orders, I would genuinely like to hear about it.

Hiding WooCommerce Prices Is a Data-Exposure Problem, Not a CSS Problem

Eren Labs — Mon, 24 Aug 2026 22:18:22 +0000

Catalog mode sounds simple: remove the price, replace “Add to cart” with “Request a quote,” and move on.

That approach works only until someone checks the data behind the page.

Modern WooCommerce stores do not render every product from one PHP template. A price may be present in the initial HTML, variation data, a Store API response, structured data, a feed, a REST response, GraphQL, or a cached fragment. Hiding the visible label can therefore create a false sense of security: the page looks price-free while the number is still available to browsers, crawlers, integrations, and curious customers.

This article explains how to treat price hiding as a data-exposure problem and how to test it systematically.

Start with a threat model

Before writing hooks, define what “hidden” means for the store.

For a wholesale catalog, it may mean:

guests cannot retrieve a numeric price;
approved, logged-in customers can still buy normally;
search engines must not receive an Offer with a price;
read-only API credentials should not expose prices to third-party services;
a block theme must not fetch a price after the PHP page has loaded;
disabling the visible button must not leave the cart API writable.

This definition is much stronger than “there is no price text on the product page.” It gives you a testable security boundary.

Map every public price surface

The exact surface area depends on the theme and extensions, but a practical WooCommerce test matrix should include at least the following.

1. Classic storefront rendering

Check single-product pages, shop and category loops, related products, grouped products, variable-product ranges, the cart, the mini-cart, checkout, and customer emails.

Removing price HTML through a display filter is useful, but it covers only views that use that filter. Custom themes may call lower-level product methods directly.

2. Variation data

Variable products commonly send a JSON object containing every variation to the browser. Removing the visible range does not help if the variation payload still contains display_price, display_regular_price, or price-formatted HTML.

Inspect the document and network responses, not only the rendered text.

3. WooCommerce Store API

Block themes and modern cart/checkout blocks depend heavily on the Store API. Product responses can contain numeric price fields, formatted price HTML, ranges, and cart totals. Protection needs to happen before the response leaves the server.

A useful rule is:

If the customer is not allowed to see a price, the client should never receive that price.

Blanking a React component after fetching sensitive data is not access control.

4. Structured data and SEO integrations

Even when a theme is clean, JSON-LD may publish an Offer, price, or lowPrice. Test WooCommerce core schema plus the SEO plugins actually used by the store. A crawler does not care whether the price is visible to a human visitor.

5. REST and GraphQL

Review WooCommerce REST endpoints for products and variations. If WPGraphQL or WooGraphQL is installed, check the product fields at resolver level. A storefront rule that never reaches these APIs is incomplete.

6. Feeds and caches

Product-feed plugins, edge caches, full-page caches, and custom integrations deserve explicit tests. Some are outside the control of a catalog-mode plugin, so the admin interface should say what is protected automatically and what needs a manual check.

Remove the value server-side

CSS is presentation. JavaScript is presentation. Neither should be responsible for protecting a business-sensitive value.

The safer pattern is to enforce an audience decision on the server, then sanitize each public representation before serialization. For example, the same policy function can answer whether the current visitor may view prices, while individual adapters apply the decision to storefront output, Store API schemas, REST responses, and structured data.

Conceptually:

function visitor_can_view_catalog_prices(): bool {
    if ( is_user_logged_in() && current_user_can( 'view_wholesale_prices' ) ) {
        return true;
    }

    return false;
}

The important part is not this small function. It is using one consistent decision across every outbound surface.

Catalog mode also needs write protection

Removing “Add to cart” from the page is not enough. If the Store API still accepts a cart mutation, the missing button is merely cosmetic.

When catalog mode is active, test both halves:

the UI no longer offers a purchase action;
the underlying cart endpoint rejects an equivalent direct request.

The same principle applies to quote forms. Nonces help with request intent, while honeypots and rate limits reduce automated abuse. Quote records should also be separated from paid orders so they do not inflate revenue reporting.

Build a regression test, not a one-time checklist

WooCommerce, themes, and SEO plugins change. A store that passed today can leak after an update introduces a new response field.

A repeatable test should:

request representative storefront pages as a guest;
scan HTML and embedded JSON for known product prices;
query Store API product and cart endpoints;
inspect REST and GraphQL when enabled;
parse JSON-LD for offer values;
verify that cart writes are rejected in catalog mode;
run again after WooCommerce, theme, or SEO-plugin updates.

False positives matter. Product IDs, SKUs, stock values, and dimensions can resemble prices, so assertions should target known fields and formats rather than blindly searching for every number.

A practical implementation

I built PriceVeil for WooCommerce around this surface-mapping approach. The free plugin covers classic storefront output, block-theme Store API responses, WooCommerce REST, common SEO schema integrations, GraphQL, carts, checkout, and quote-request handling. It also includes wp priceveil selftest so the server-reachable checks can be repeated after updates.

The broader engineering notes and screenshots are available on the PriceVeil project page. I am sharing it here because the underlying lesson applies beyond one plugin: when a business rule says a visitor must not see a value, treat every serialization boundary as part of the feature.

Final checklist

Before calling a WooCommerce catalog price-free, verify:

the number is absent from HTML and variation JSON;
Store API and REST responses are sanitized;
GraphQL is covered when installed;
JSON-LD and product feeds do not publish an offer price;
caches have been purged and tested as a guest;
cart writes are blocked, not merely hidden;
logged-in exceptions behave as intended;
there is an automated regression test for future updates.

The visible label is only the beginning. The real feature is controlling where the underlying value can travel.