The Architectural Conflict: Store vs. Product Identity
In standard e-commerce implementations, a product’s existence is tied directly to its store database row. If a store item is re-priced, renamed, or temporarily created during a checkout test, the entire public catalogue shifts. In professional software platforms, this coupling creates catastrophic regressions: test items pollute public recommendation grids, pricing changes break permalinks, and product documentation becomes tethered to database primary keys.
The SOVEL Decoupled Catalogue Architecture
To eliminate this failure mode, SOVEL introduces a four-layer separation of concerns:
- Layer 1: Permanent Product Identity: Governed by the canonical Product Registry and the
sovel_cataloguepost type. Every product possesses an immutable architectural identifier (e.g.,SOVEL-AEOS,SOVEL-BCE,SOVEL-CGFE) independent of database IDs. - Layer 2: Canonical Editorial Specification: Product overviews live on dedicated, semantic page templates documenting system inputs, stage gates, requirements, and support paths.
- Layer 3: Ephemeral Commercial Layer: WooCommerce products act solely as commerce drivers (order accounting, tax, checkout fields, and payment gateway webhooks).
- Layer 4: Publication Gate: A strict database and SQL query gate prevents unapproved WooCommerce products from appearing in public loops, search queries, or category archives—even when an administrator browses the frontend.
Results in Practice
Because editorial identity and commercial status are decoupled, internal quality assurance tests can simulate purchases, test gateways, and verify order notifications without the slightest risk of public store pollution. Meanwhile, customers experience clean, high-performance category navigation backed by verified packages.