Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to teardown argues that hiding prices with CSS or a template override leaves the number in variation JSON, Store API responses, JSON-LD and feeds. "Hidden" has to be defined per surface.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A price is not a piece of markup. It is a value the server computes once and then serializes over and over, and every serializer is its own exit door: the product template, the variation blob a variable product ships to the browser, the Store API document a block cart reads, the JSON-LD graph a crawler reads [2][4][5][6].
That is why a display filter is a weak boundary. Of the eight carriers dev.to enumerates, filtering the displayed price HTML touches one of them, and only in the views that actually call the filter; a custom theme reaching for lower-level product methods bypasses it entirely [2][3][1]. Before you get anywhere near the API, the same author's storefront matrix already lists nine view types to check, customer emails included [9][2].
The button half is the part that gets skipped. Removing "Add to cart" changes what the UI offers; it does not change what the cart endpoint accepts, and dev.to's test is explicitly two-sided, with the direct request rejected as well as the button gone [8]. The stated rule is worth quoting because it is an access-control rule and not a styling one: if the customer is not allowed to see a price, the client should never receive it, and blanking a React component after the fetch is not control of anything [7].
The construction that follows from this is one server-side policy answer about the current visitor, then a sanitizer per outbound representation, applied before serialization rather than after render [11]. That is cheap to reason about and awkward to ship, because the surfaces are owned by different code: WooCommerce core schema and whichever SEO plugin is actually installed both emit Offers [6], WPGraphQL or WooGraphQL needs the check at resolver level [2], and product-feed plugins, edge caches and full-page caches sit outside a catalog-mode plugin's reach altogether [12].
Which is the honest admission in the piece. The recommendation is that the plugin's own admin screen state what it protects automatically and what the operator has to verify by hand [12]. A catalog-mode product that ships a coverage list is telling you it is not a security boundary on its own, and an operator who buys one without reading that list has bought a stylesheet.
The definition to write down first is the wholesale one dev.to sets out: guests retrieve no numeric price, approved logged-in customers buy as normal, crawlers get no priced Offer, read-only API credentials return nothing, the block theme does not fetch a price after PHP has finished, and the cart endpoint is not writable [10]. Every clause there is testable by a logged-out request, which is the point. None of them is testable by looking at the page.
One non-obvious tail: the quote form that replaces checkout creates records that resemble orders, and the advice is to keep them separate so they do not inflate revenue, alongside nonces for request intent and honeypots and rate limits against automated abuse [13].
Ranked by verification strength, evidence, and original report placement.
Hiding the visible price label can create a false sense of security: the page looks price-free while the number remains available to browsers, crawlers, integrations and customers.
In modern WooCommerce stores 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; if WPGraphQL or WooGraphQL is installed, product fields should be checked at resolver level.
Removing price HTML through a display filter covers only the views that use that filter; custom themes may call lower-level product methods directly.
Variable products commonly send a JSON object containing every variation to the browser; removing the visible range does not help if that payload still contains display_price, display_regular_price or price-formatted HTML.
Store API product responses can contain numeric price fields, formatted price HTML, ranges and cart totals, and protection needs to happen before the response leaves the server.
Even when a theme is clean, JSON-LD may publish an Offer, price or lowPrice; WooCommerce core schema plus the SEO plugins actually used by the store should be tested, since a crawler does not care what is visible to a human.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One vendor-authored teardown, architecturally plausible, unreproduced
All claims trace to a single dev.to post by the author of a plugin that sells the fix. The technical substance is internally consistent and matches how WooCommerce serializes product data (variation payload fields, Store API responses, JSON-LD offers), and the article names specific fields and endpoints rather than speaking in generalities, which raises it above pure assertion. But there is no second publisher, no captured response, no store-level reproduction, no advisory or security identifier, and no measurement of prevalence, so the evidence base is a well-argued single-source design note.
Self-disclosed plugin release, no usage evidence
The only adoption datum in the supplied material is the author's own statement that he built and released the free PriceVeil plugin with a selftest CLI command. There are no install counts, no named stores applying the pattern, no third-party integrations and no evidence that any WooCommerce shop has adopted the per-surface sanitization approach described, so measured adoption is close to the floor.
Mildly overstated: real mechanism, unproven scale, vendor framing
The mechanism is real and the 'client should never receive the price' rule is sound engineering, so this is not manufactured alarm. The overstatement is in scope and urgency: the headline count of hiding places and the security framing rest on one unreproduced post by the plugin's author, with no exploit, incident, advisory or evidence of how many catalog-mode stores actually leak, and with the fix being the author's own product. That combination pushes the narrative modestly ahead of the demonstrated evidence and near-absent adoption.
Author markets the plugin that fixes the described problem
The post explicitly discloses that the author built PriceVeil for WooCommerce and links its project page, and the article's structure - define 'hidden' broadly, enumerate surfaces, argue that display filters and CSS are insufficient - maps directly onto the advertised feature list of that plugin. The disclosure is open rather than hidden, which is mitigating, but the commercial and distribution incentive to widen the perceived surface area is strong and there is no independent publisher in the cluster to counterweight it.
Design reasoning trustworthy, scope and impact unverified
Confidence is moderate: the architectural claims are specific, self-consistent and consistent with how WooCommerce exposes product data, and the recommended pattern is independently sensible. It is held down by the single vendor-authored source, the absence of reproduction or third-party confirmation, the unmeasured prevalence of the leak, and essentially no adoption evidence for either the pattern or the plugin.
build
Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock1 distinct publisher
build
A default JSON-LD bundle beats a taxonomy research project on every new site1 distinct publisher
build
A WordPress route is one function call; the contract around it is the actual work1 distinct publisher
build
Block themes move who controls layout, not just how templates are written1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 24, 2026