Upgrading a retailer to Magento 2.4.8, and why checkout broke

A specialist hobby retailer’s Magento store was two major versions behind, missing a year of security patches, and loading a ten-megabyte home page. Then checkout died. This is how we brought it current and what we found underneath.

The upgrade

We moved the store to Magento 2.4.8 with every isolated security patch Adobe had published, on a current PHP, on the retailer’s own isolated install rather than a shared one. The upgrade itself is procedure: composer, database schema, a full static-content rebuild, reindex, cache flush, then click through the storefront, the cart and the checkout as a customer before announcing anything.

Why checkout broke, and the lesson

Checkout failed with a script error that pointed at a core JavaScript library. The cause was Magento’s static deployment: even when forced, it does not overwrite files that already exist. The new release had shipped new JavaScript with new integrity hashes, but the old files were still being served, so the browser refused them. The fix is to move the old static directories aside before every deploy rather than deploying over them. We now do this every time, on every store, and we check the hash manifest against the served files before calling an upgrade done.

A related trap: if a CDN sits in front of the store and static files are not signed with a version, the CDN keeps serving the old files against the new hashes long after the origin is correct. Enable signing or purge the CDN. Both, ideally.

Don’t patch what an update will overwrite

The store’s hero slide was lazy-loading itself out of the largest-contentful-paint measurement because of a speed optimiser extension. The tempting fix was to edit the extension. We did not, because the next extension update would silently revert it. The real fix was a configuration flag the extension already offered, and where configuration cannot do it, we write our own small module that overrides the behaviour and survives updates. The same rule applies to purchased themes.

Category pages that sell

Category listings showed out-of-stock items mixed in with available ones, which for a hobby store with long-tail stock meant customers scrolling past things they could not buy. We built a small module that sorts in-stock products first on every category page, independent of the sort the customer chooses. It took an afternoon and it changed how the store feels.

What the SEO audit found

• No canonical tags, and category-path URLs, so each product was reachable at around five addresses. Google was indexing all of them.
• Meta titles set to the manufacturer name on more than four hundred products.
• Analytics tracking code from a product Google retired in 2023, so no data had been collected for years. We set up GA4, Search Console and Merchant Center access through the API so reporting no longer depends on anyone logging in.
• A duplicate, abandoned analytics account and a former agency still holding access. Both removed.
• Demo CMS pages from the theme install still in the sitemap.
• Home page weight of ten megabytes and a largest-contentful-paint measured in tens of seconds on mobile, mostly oversized PNGs. We resize and recompress in the original format; we do not convert customers’ product imagery to formats that look worse.

Each of those became a ticket in a prioritised backlog rather than a vague “improve SEO” line. That is the difference between an audit and a report.

If your store is a version or two behind

Every unpatched month is a liability and every slow page is lost revenue. We upgrade, patch and run Magento and WooCommerce stores for retailers who would rather be selling.