How MyPharmacy Fixed
Its Prescription Flow Without Turning Off Caching

A choice no pharmacy should have to make

Imagine being forced to pick between a fast website and a prescription flow that actually works. That was the corner MyPharmacy had been backed into. This UK online pharmacy runs two catalogues: a Pharmacy range that works fine on its existing forms, and a Prescription range of around twenty categories where products stay locked until the customer completes that category’s clinical questionnaire. To make the old prescription flow show the right per-customer state, the client had been forced to switch off full-page caching across the entire site, which made every page slow for every visitor. And even with caching off, the flow still leaked. As a specialist OpenCart development company, Stallyons Technologies rebuilt the prescription experience as a native OpenCart module that moves all form state server-side, so caching stays on, every answer reaches the order, and the pharmacy team manages every questionnaire itself.

Why the old flow was quietly dangerous

On the surface, the prescription journey worked. Underneath, the way it stored state created compounding problems across performance, safety, and maintenance.

• Cookies forced caching off. Answers and unlock-state lived in browser cookies, so cached pages could not reflect per-customer state. The only fix was to disable full-page caching site-wide, slowing every page for every visitor.
• Orders arrived incomplete. Even with caching off, the cookie approach intermittently dropped questions, so some orders reached the pharmacy without the full answer set. That is a clinical risk, not just a bug.
• Every change needed a developer. Adjusting a question, an eligibility rule, or the cookie wiring meant a phone call and a deployment. The client could not manage their own forms.
• Unlock was not provably isolated. The pharmacy needed certainty that one person’s completed form could never unlock a category for anyone else, on any device. The cookie model could not guarantee that.
• The experience was not built for the job. There was no clean styled popup, no built-in clinical gating, and no pharmacist review flags, all things a prescription journey needs.
• Twenty branching forms to maintain. Each category has its own questionnaire with questions that branch on earlier answers, which is a lot to keep straight by hand.

The solution: keep the journey, move the machinery

The rebuild keeps the customer experience familiar and moves the engine server-side. When a customer opens a prescription category, a styled popup walks them through that category’s questionnaire, supporting Yes/No, tickboxes, multiple choice, free text, and image upload, with later questions branching on earlier answers. Each answer is saved server-side the moment it is given, tied to a single opaque session identifier, so nothing is lost and the storefront page itself stays fully cacheable.

Some answers fail the form and stop an ineligible customer before they ever reach the basket, and the customer can step back and edit any earlier answer at any point. On completion, the category’s products unlock, but only for that session, and the complete answer set is attached to the order. In the OpenCart admin, the answers arrive alongside the order, and any answer the team has flagged as clinically significant is highlighted in red for fast pharmacist review. Through an admin form builder, MyPharmacy creates and edits every questionnaire, its questions, branching, fail rules, and flags, without touching code.

The promise in one line: caching stays on, every answer reaches the order, and the client manages the forms, with unlock scoped to a single session and existing history untouched.

Why a native OpenCart module was the right call

The instinct might be to reach for an off-the-shelf form plugin, but that is exactly what created the cache conflict in the first place. A native module was the right answer because it lives inside OpenCart’s own request cycle rather than fighting it. That let the platform handle the catalogue, the admin, and the order pipeline, while our OpenCart development services focused on the hard part: holding per-customer questionnaire state reliably while keeping the whole storefront cacheable, and doing it so one customer’s progress can never leak to another.

OpenCart’s flexibility is a recurring theme in this kind of work. In another project we delivered a static-to-dynamic OpenCart rebuild for Economia Verde that was all about preserving search rankings through a migration, and here the same platform underpins a security-and-performance-critical clinical flow. The stack is deliberately lean: OpenCart on PHP with an MVC-L module, MySQL for forms, answers, session state, and an audit trail, a JavaScript popup matched to the MyPharmacy theme, server-side session state that replaces cookies so caching can stay on, secured file storage for patient image uploads, and full-page or CDN caching re-enabled site-wide.

The four decisions that made it dependable

Server-side session state, not cookies. A single opaque session identifier ties each visitor to answers stored server-side, so the cached storefront HTML never has to vary per customer. Full-page caching stays on, the site is fast again, and because every answer is persisted as it is given, the complete set is always available at checkout.

Eligibility scoped to the session, never shared. Unlock is granted only to the session that completed the questionnaire and is re-checked server-side on every request. No other device, browser, or location can inherit someone else’s completed form. This is enforced by the server, not trusted to the browser.

Clinical safety built into the form engine. Fail answers gate ineligible customers before they can buy, and admin-flagged answers surface in red on the order so a pharmacist reviews the right cases at a glance. The checks live inside the flow, not in a manual step someone can skip.

Client-owned form management. A form builder in the OpenCart admin lets MyPharmacy create and change questionnaires, branching, fail rules, and flags itself. Changes that once took a phone call and a deployment now take minutes in-house.

The results and business value

Because state moved server-side and the form engine is configuration-driven, the rebuild fixed the performance, safety, and maintenance problems at once. The figures below are illustrative of a realistic delivery rather than audited data, and they show the shape of the impact.

In business terms: the site is fast again for every visitor, orders now arrive with complete clinical information, ineligible sales are blocked before checkout, pharmacist review is focused on the cases that matter, one customer’s unlock can never leak to another, and the pharmacy is no longer paying for or waiting on a developer to make routine form changes. Nothing in the existing customer history or the Pharmacy range was touched.

Have a form, state, or caching problem on OpenCart?

If a third-party plugin is forcing you to choose between a fast site and per-customer functionality, or if critical data is slipping through the cracks, a native module built into OpenCart’s own request cycle is usually the clean fix. Stallyons Technologies designs and builds exactly this kind of custom OpenCart module, from server-side state and branching form engines to admin builders and order integration.

Facing a tricky OpenCart build like this one? Talk to Stallyons Technologies, an OpenCart development agency that handles the hard parts, today.