Just Bricks is one of Australia's larger independent LEGO retailers. When I picked up their store it was running CS-Cart 4.5.2 on PHP 7.1 — a 2017-era platform, years past security support, sitting on an upgrade path that everyone involved had been carefully not looking at for a long time.
I took it to CS-Cart 4.20.1 on PHP 8.3.
There is no jump from 4.5 to 4.20. Each version will only offer you the next one, so the work is fifteen sequential major-version upgrades, plus two PHP major-version jumps sequenced against which versions the platform would actually run on. All of it on a store carrying 201,000 orders, 89,000 customers, 7,397 products and a 3.2 GB database, which had to come out the other side intact.
The interesting decision was what to do with the collisions validator. CS-Cart warns you which of a site's customisations each upgrade is about to overwrite, and you can skip the check. Skipping it is much faster, and it silently destroys the customisations that make the store the store. So I didn't — I used the validator's output at every step as a list of things to review and re-apply. That is most of where the time went, and it's the reason nothing was quietly lost.
Along the way: a Phinx migration that failed because of MySQL strict mode, the CS-Cart
4.11 product-variations data migration, missing primary keys across roughly 120 tables
that only surfaced under a newer MySQL, and a store-reopen mechanism that changed
underneath me partway up the path. I also delivered WebP image optimisation and rebuilt
the theme as a proper child of responsive rather than a fork, so the next upgrade is a
smaller job than this one was.
Along with the updates, we designed a brand-new, modernised look for the website, and it was up to me to take it from a set of figma designs to a fully-fledged theme. This didn't just involve exporting CSS, but building new layouts, sourcing and adding images, extrapolating for pages that weren't designed, and liasing with the client to make sure they were happy with the end result.
And a lot of tweaking.
With the platform current, the brief moved to card fraud.
PayPal Advanced Card Payments. The ask was a cardholder-name field without a billing-address block, plus card metadata recorded against orders so staff could review suspicious ones. Working through it, I established something the client hadn't expected: under PayPal's standard Smart Buttons flow, guest card entry is routed through an auto-created PayPal account, so the merchant never receives card data at all. That's why the metadata wasn't there. Both requests turned out to be the same problem, and moving to Card Fields solved both at once. Built with 3-D Secure, Apple Pay and Google Pay wallet capture, and funding-source recording — entirely through hooks, under a house rule of no core edits.
Order IP geolocation. Each order's stored IP is resolved to a country and city and
checked against the billing and shipping country, flagging mismatches for review. I
built it on the MaxMind GeoLite2 database already bundled with the platform, so it added
no runtime dependency, no per-query cost, and no customer data leaving the server —
with an automated, checksum-verified, atomically-swapped database refresh. CS-Cart's own
fn_get_country_by_ip() turned out to be IPv4-only, because it round-trips the address
through long2ip(ip2long()); I bypassed it so IPv6 orders resolve properly.
Checkout hardening. Inline on-blur validation, and blocking payment when a guest checkout email already belongs to an account — offering an in-place login instead.
Canvas Factory print wall art — you pick an image, pick a size, and they print and ship it. They run CS-Cart across Australian, New Zealand and US storefronts, and I was brought in to implement GA4 and Google Tag Manager ecommerce tracking across all of it.
Which sounds routine, and wasn't, because of one structural fact: the store doesn't sell products.
The images come from external licensing providers — Getty, Alamy and others — at a scale approaching 100,000 images. They aren't CS-Cart products. They don't have product IDs, they aren't in the catalogue, and they can't be, because the catalogue would be meaningless at that size and would need to track someone else's inventory.
What the store actually sells is a size of a print of an image. GA4's ecommerce model,
meanwhile, very much wants a product with an ID and a category. So the job became
designing a mapping: a composite item-ID scheme of {source}_{art_image_id} that stays
stable across sessions and providers, and a category hierarchy that GA4 would accept and
that the client's marketing team could actually read in a report.
An add_to_cart event that had never once fired in production. The listener existed
on the upgraded site, so it worked in every environment anyone tested in. It was missing
entirely from live. Nobody had noticed, because the absence of an event doesn't look
like anything — the reports just quietly had a hole where the most important step of the
funnel should be.
Event integrity across an iframe boundary. The canvas configurator — where the
customer crops and positions their image — is an iframe maintained by a third-party
developer, so events had to cross a postMessage handoff between two codebases, only
one of which I controlled. Debugging that meant establishing, for each event, whether it
was fired at all, fired twice, fired with the wrong payload, or fired into a listener
that had already been torn down. It's a good reminder that in analytics work the bug is
almost never in the analytics.
All of the tracking work shipped, and the client and marketing company involved were very happy with the results.
Area Safe Products sell road, traffic and public-safety equipment — bollards, wheel stops, street furniture — across two brands: Area Safe Products and Astra Street Furniture. Both storefronts run from a single CS-Cart backend.
I rebuilt their checkout and took it live in late March 2026.
Most eCommerce checkouts have one job: take the money. This one has three, because the customers aren't all the same kind of customer.
A member of the public buying a wheel stop pays by card. A council or contractor specifying street furniture wants a quote, not an order. An established trade customer wants to place the order against their existing account and be invoiced. Same catalogue, same cart, three completely different outcomes — and the sales team works the quotes and account orders that come out the other end.
The complication was that none of this sat on standard data structures. Order type and flow were carried on non-standard fields, layered over a heavily modified and by-then deprecated multi-step checkout addon. It was not a greenfield build; it was a rebuild threaded through several years of accumulated custom code, which is the harder and far more common real-world problem. I ended up writing a report for my director explaining why the checkout was so resistant to change, which was as useful to the client as the code.
swim_checkout_options — a custom addon managing order type and the branching checkout flow.shippings, destinations and shipping_rates tables, with GST applied per rate area.swim_forklift_charge — a custom addon that automatically applies a tailgate-unload surcharge when any item in the cart exceeds 80 kg. If you're buying something that needs a truck with a lift on it, the checkout works that out rather than the customer discovering it later.Later in the year I also spent time on the platform's reliability — the store had been going down repeatedly, and tracking that down turned into a separate piece of work involving PHP-FPM pool limits, memory saturation, and a fair amount of arguing with my own monitoring about what it wasn't telling me.