The real problem
Firstline's entire catalog, 17,500 SKUs with their prices and stock, was visible to anyone. It should have been visible only to an approved wholesale buyer, and the registration flow already in place was not hardened enough to hold that line: nonce and capability checks were missing, email verification was not enforced, and there was no formal buyer state machine.
This is a production store with active buyers and a live Cin7 sync, so I proposed a phased roadmap and had it approved before touching anything: stabilize caching and backups, audit authentication, define buyer access states, optimize filtering, lock the catalog server-side, and only then choose a wholesale pricing plugin. The order is deliberate. You do not settle pricing before you have settled who can see it.
For the same reason nothing was tested against the real store. I stood up a local WordPress install in Docker and verified every access state there before proposing the change.
I designed the whole flow before building it: registration and a screen of its own for each state, pending, rejected and blocked, plus the verification route. An unapproved buyer has to land on the screen that fits them rather than a broken one, which is the same access problem seen from the other side.
Access is governed by user state rather than new WordPress roles, which would have created migration risk across an existing user base with mixed roles. It lives in its own plugin rather than the theme, so it can be rolled back safely. And because state, pricing, stock, and cart are all dynamic, I took the private catalog routes out of page cache entirely: performance there rests on taxonomy queries and object caching instead.
The client paused the project before final QA, so the catalog locking and the state flow are built and unpublished. The store still online is the earlier one, catalog still open.
Technologies
- Platform: WordPress, WooCommerce
- Languages: PHP, JavaScript, HTML, CSS
- Integrations: Cin7, wholesale pricing plugin, page and object caching
- Local environment: Docker (WordPress install for testing)
- Focus areas: Buyer flow design, access control, authentication hardening, cache policy, query performance
