Hi there 👋

I hear the claim of 100% uptime thrown around a lot. Although is 100% uptime really a good goal to have? Like most things in tech, the answer is, it depends. If your running your Magento store within a fault tolerant cluster, sure 100% website uptime is a good goal. Whereas if your are running Magento on a single instance, or even multiple servers but not in a cluster. Then claiming to aim for 100% uptime is more of a red flag than something to be proud of....

🔥 Hot Take: Stop offloading poor engineering practises onto clients. There is no wonder merchants are apprehensive about using Magento 2, when we are quoting them excessive amounts to even keep their store up to date and secure. In some recent research, I’ve seen estimates in excess of 100 hours for an update. That seems wild to me! I’ve found Magento releases have been getting a lot more stable & bug free in recent years, especially since Adobes acquisition....

Chaos. Those who know me, knows that I love a bit of chaos in my work. Data center caught fire? Server fell out the rack? Its like a free roller coaster. For someone who’s role is to reduce the chaos, I enjoy and thrive on it a little bit too much. Why implement Chaos Engineering practises? This is where Chaos Engineering comes into play, nobody wants to be woken up at 3am because OOMKiller has decided your database is not important any more....

The default Nginx sample configuration, and htaccess files shipped by Magento have the /setup/ route publicly accessible. And this route displays your current magento version, including patch level. For all prying eyes to see. Currently this affects all Magento versions up to 2.4.7-p1 (the latest at time of writing), including 2.4-develop. It is worth noting, I believe the web installed was removed in 2.4. Is there any need for this route to continue to exist, apart from leaking version data?...

I do a fair bit of performance oriented consulting/contracting work with Magento Agencies / Developers. A common theme seems to be difficulty monitoring/debugging Varnish. The Varnish Service Watching a specific URLs Age We can monitor how long a specific URL is staying in cache, by wrapping a curl command within a while loop. (Note: You may need to update your varnish config to stop removing the Age header) while true; do curl -Iso /dev/null -w '[%header{Date}] %{http_code} %{url} %header{x-cache} %header{age}\n' https://example....

I was doing some health checks on some new brownfield projects we’ve taken on recently, ahead of migrating them to our own infrastructure. And I noticed that their NewRelic invoices seemed abnormally high for the amount of traffic the stores received. I was expecting most of the stores to still be in the free tier, or at least under 200/300GB total ingest. Looking at the “Manage Data” account page in NewRelic....

So it appears the Magento 2 Trojan order exploit (CVE-2022-24086) is making the rounds again. With the recent rise in exploit attempts I am going to go out on a whim, and assume the exploit kit was recently sold/released again. Trojan Order was identified and patched back at the start of 2022. The relevant security Bulletin is APSB22-12. It states versions 2.3.0 to 2.3.3 are not affected but any other versions below 2....

Typically a lot of Magento 2 stores are slow to build, some taking up to and over an hour. This becomes a bigger pain point as stores grow and more themes & locales are added. Often optimising build time is often towards the bottom of the priority list. The Magento Static Content Deploy Docs provides a good amount of detail on this subject, and is a good read. Just remember, typically, your pipeline execution time also affects your time to release fixes to critical production issues....

Often when debugging frontend functionality, I find myself reaching for access into Magento Javascript components. To either read the current state or invoke various methods within that component to test return values. But how do we do this? How do we get, lets say, the current quote? It’s quite simple really, we just call require instead of define like we would in a component. Slap a debugger call in the body and now you can play with that component to your hearts content....

There are a handful of guides on how to clean-up old Github Action Artifacts. The issue I have with the ones I’ve seen, is they are really convoluted solutions for such a simple task. I am making an assumption here that you are using the Github CLI tool. If you are not, then your missing out, go give it a go (even just for this task). You can even use the CLI directly within your workflows if you can to run the clean-up as a nightly task etc....