The Spinning Wheel of Death: How a Facebook Plugin Held Our Website Hostage for 30 Hours

Running a small audio shop is a daily exercise in wearing a lot of hats. Some days you’re testing a Marantz 2265 on the bench. Some days you’re carefully boxing up a pair of large Polk Audio tower speakers headed to a happy customer in Thunder Bay — speakers so large that traditional couriers won’t touch them, which means a 70‑minute drive across Ottawa to drop them at our freight forwarder, because that’s just what you do when you want a customer in Thunder Bay (about 1,400 km away — roughly the distance from Paris to Rome) to actually receive their gear in one piece.

And then, occasionally, you’re at your desk at 2 AM, staring at a frozen WordPress editor, drinking lukewarm coffee, and wondering whether the entire internet is broken or just yours.

This is the story of one of those nights. The good news: the website is fine, the gear is fine, and we (eventually) figured it out. The better news: there’s a useful lesson in here for any other small business running a website on WordPress — and a fairly entertaining 30‑hour rabbit hole along the way.

Buckle up.

The Spinning Wheel of Death Arrives

The first person to actually run into the bug wasn’t me — it was Sarah, our Office Manager (who, like most small‑business office managers, wears about six other hats on any given day). Sarah was trying to do something that should have been routine and joyful: adding new system photos sent in by Al & Angi — two of our absolute favourite customers — to our still‑growing Customer Systems Portfolio. As of writing, there are only about a dozen systems up there — our current site layout is still relatively new — but it’s growing like crazy and we absolutely love seeing it fill in.

Sarah went to open the page editor and was greeted instead by what she immediately christened “the spinning wheel of death.” A small black spinner where the editing tools should be. All controls greyed out. No error message. No timeout. Just… eternal loading.

She flagged it to me. I assumed it was a five‑minute fix. (Spoiler: it was not a five‑minute fix.) Little did I know I was about to disappear down a 30‑hour, two‑night, multiple‑coffee‑cup rabbit hole that would consume most of my work week.

Why We Were Pushing So Hard on Speed

This all landed right on the heels of a big infrastructure change for us. We had just migrated radique.com to a new hosting provider specifically to give our customers a faster, smoother website experience. Early benchmarks were showing the site loading roughly 80% faster than before — and we’re still tuning and improving things as we go.

That migration wasn’t just for our own satisfaction. A couple of our customers, Kirk and Stéphane, had very kindly (and honestly) told us that the old site felt sluggish. They were right. Their feedback nudged us to make the move sooner rather than later, and we’re genuinely grateful they took the time to say it out loud instead of quietly putting up with it.

First Suspect: Our WordPress Caching Stack

The page itself was working fine on the public side. Customers could browse, add gear to their carts, check out — the public side of the site was happily humming along. But behind the scenes, our ability to change anything on the site was completely frozen. New listings, blog posts, FAQ updates, and yes, Al & Angi’s beautiful system photos — all on hold.

Like most performance‑conscious WordPress sites, radique.com uses a layered caching setup designed to make the site fast for visitors. There’s server‑level page caching, an in‑memory object cache, and an edge cache that distributes our pages globally.

When something breaks in WordPress, the universal first instinct is: “It’s the cache. It’s always the cache.” And to be fair — about 60% of the time, it really is the cache.

We ran the standard rituals. Purged everything. Cleared everything. Rebooted everything that would let itself be rebooted. The spinner spun on, mocking us.

Thirty Hours of “Have You Tried Turning It Off and On Again?”

This is the point where, if you’ve ever opened a support ticket with a hosting company, you know what happens next: the back‑and‑forth begins.

Over roughly 30 hours and a small parade of helpful but increasingly stumped support agents, we systematically ruled out:

• ❌ Stale page caches

• ❌ Stale browser data

• ❌ The edge cache and firewall rules

• ❌ Our security plugin

• ❌ A leftover file from a long‑deactivated plugin

• ❌ A misbehaving WooCommerce shipping plugin

• ❌ The connection between WordPress and our in‑memory object cache (which kept reporting “all good!” — unhelpful in retrospect)

We even noticed the bug had a weirdly specific trigger: it only happened when the in‑memory object cache was turned on. Turn it off — Sarah could edit pages. Turn it back on — spinning wheel of death.

By about three‑quarters of the way through this process, I’ll be honest: I almost gave up and just left the object cache turned off permanently. That would have made the editor work again and let us move on with our day — but it also would have thrown away a big chunk of the speed gains we were getting from the new host. I’m very glad, in hindsight, that I didn’t cave to that temptation.

For a long time, the pattern pointed everyone — us, the hosting team, the specialist team — squarely at the cache as the culprit. It seemed obvious. Of course it was the cache. It’s always the cache.

Spoiler: it wasn’t the cache.

The 2 AM Debug Log Breakthrough

Around 2 AM on the second night, I did something I probably should have done earlier: turned on a deeper layer of debug logging, carefully reproduced the bug, and downloaded the resulting log file for analysis.

This is the part of the story where being a stubborn nerd at an inconvenient hour pays off. Buried in roughly 178,000 characters of debug output was one line that didn’t fit the pattern. Translated to plain English, it said:

Something is sending data to your customer’s browser before it’s supposed to.

Web browsers and websites have strict rules about the order in which information flows. If anything sneaks content out early — even a single rogue character — it can corrupt the responses that modern editors depend on.

That single line of debug output reframed everything. The problem wasn’t that the cache was broken. The problem was that something else on our site was misbehaving — and the cache was just changing the timing of when the misbehaviour fired, which is why turning it on made the bug appear and turning it off made it disappear.

I packaged up the finding, sent it to the hosting team’s specialist tier with a respectful “please look at this lead specifically,” and finally went to bed.

Root Cause: The “Facebook for WooCommerce” Plugin

A few hours later, the answer came back from a brilliant Level‑2 specialist named Darina. The culprit was a third‑party WordPress plugin called “Facebook for WooCommerce” — a connector tool that’s designed to sync product information from a WooCommerce store to a Facebook Shop, and to fire Meta Pixel tracking events for advertising purposes.

It’s important to be clear about what we’re describing here: this isn’t a problem with WooCommerce itself (the underlying e‑commerce platform we rely on every day, which works beautifully for us), and it isn’t a problem with Facebook as a service. It’s specifically this one plugin — the bridge between the two — that had a conflict with our particular site configuration.

In our case, the plugin was injecting background script data into the WordPress admin area in a way that interfered with how the page editor was trying to load its controls. The end result on our screens was that little black spinner and a frozen interface.

Darina disabled the plugin. The spinning wheel of death vanished. The website was whole again. Sarah uploaded Al & Angi’s photos. Order was restored to the universe.

Note: This post describes our specific experience troubleshooting a software conflict on our own website. We’re not making any general claims about the “Facebook for WooCommerce” plugin’s reliability for other users — many businesses use it successfully. Your mileage may vary.

Lessons for Other Small WordPress Shops

1. Caching is rarely the real problem — but it’s usually the loudest symptom

When a website misbehaves, caching is the easiest thing to blame, the easiest thing to toggle on and off, and the easiest thing to appear to fix the problem. In our case, turning the cache off made the symptom disappear — but the underlying bug was still there, waiting for the next trigger.

If you ever find yourself in a situation where toggling cache “fixes” a problem but you can’t explain why, treat that as a red flag, not a solution.

2. Plugins are software. Software has bugs. Even big‑brand software.

The “Facebook for WooCommerce” plugin is maintained by Meta — not some abandoned hobby project. And yet it had a real, reproducible conflict with one of the most popular page builders on Earth that, as far as we can tell, hadn’t been widely documented.

Useful reminder for any small business: every plugin you install is a small piece of someone else’s code running inside your house. Even from the biggest names. Especially from the biggest names, sometimes.

3. Debug logs are worth the time

The breakthrough came from spending 15 minutes enabling a deeper logging mode, carefully reproducing the bug, and reading the result. If you ever find yourself stuck in a long support cycle where every reply starts with “have you tried clearing the cache?” — get a debug log into the conversation. It changes the tone of the entire investigation.

4. A good Level‑2 specialist is worth their weight in vintage Marantz

Massive thanks to Darina S. and the team at our hosting provider for staying with us through this one. Once we got the right evidence to the right person, the fix came in under an hour.

What We’re Doing at Radique Going Forward

For Radique specifically:

• We’ve permanently uninstalled the “Facebook for WooCommerce” plugin from our site. WooCommerce itself remains in place — it’s the backbone of our entire store, and we have nothing but good things to say about it. We’ve simply removed the specific plugin that was creating the conflict.

• We weren’t actively using Meta Pixel tracking or Facebook Shop syncing, and the plugin’s value to our business didn’t justify the risk of another silent conflict. If we ever decide to add Meta Pixel tracking later, we’ll do it via a lighter‑weight, dedicated solution.

• We’ve documented the conflict in our internal playbook, so if anyone on the team ever sees a similar symptom in the future, the first question will be “Is the ‘Facebook for WooCommerce’ plugin installed?” — not “Is it the cache?”

• We’re keeping the object cache enabled so our customers continue to see the 80%+ speed improvement from the new host. The whole point of this late‑night investigation was to keep the speed gains and get our editor back, and we’re happy to say we achieved both.

• We’ve published this post in case any other small WordPress + WooCommerce shop is currently staring at a frozen editor at 2 AM and Googling for answers. If that’s you: try disabling the “Facebook for WooCommerce” plugin specifically (not WooCommerce itself, which is fine). You’re welcome.

Full Circle: From Wonder Computers to Radique Audio

Here’s a small confession to wrap up. Long before Radique, long before refurbishing vintage receivers and packing speakers for Thunder Bay, my very first business — many moons ago — was a computer company called Wonder Computers. We started in Ottawa in the early 1990s and grew over the years into a national chain, with retail storefronts, a corporate sales division, and even fledgling in‑house software and hardware divisions of our own.

What made Wonder a little different from most computer shops of the era was our specialty: we were an Amiga house. For readers who weren’t deep in computing back then, the Amiga was Commodore’s brilliantly designed multimedia computer — beloved by graphic designers, video producers, musicians, and a famously passionate community of enthusiasts who knew they were using something special.

Wonder’s story eventually didn’t survive the demise of Commodore, the maker of the Amiga. When Commodore closed its doors, a whole ecosystem of companies and customers felt the impact, and Wonder was one of them. I know that ending left mixed feelings for customers, employees, and partners alike. I carry those memories too. But what I carry far more vividly are the good parts: an absolutely incredible team of “Wonder‑ful” teammates across Canada, customers who became friends, and the deep daily satisfaction of helping someone walk out the door with technology that genuinely worked for them. (If any of that sounds familiar to how we run Radique today — well, it isn’t a coincidence.)

Spending two nights elbow‑deep in WordPress debug logs at 2 AM brought back a familiar feeling I hadn’t felt in years. The flavour of coffee changes, the operating systems change, the bugs change — but the experience of stubbornly sitting with a problem until it gives up its secrets? That’s exactly the same.

Different decade. Different industry. Same job, in a way. This little software saga, weirdly, brought me full circle — and made me grateful for everything that came before, even the hard parts.

In Closing: Audio People, Software People, and a Growing Portfolio

Radique is, at heart, a small Ottawa‑based audio shop that lovingly refurbishes used and vintage gear, builds custom cherry‑wood cabinets, and tries very hard to keep good audio out of landfills and in the hands of people who’ll enjoy it. You can read more about what we do on our Why Buy from Radique? page, browse our current inventory of used and vintage audio, or take a spin through our still‑growing Customer Systems Portfolio — which, thanks to this little adventure, now includes Al & Angi’s system as well.

But running a small audio shop in 2026 also means running a website, a checkout system, a shipping calculator, a newsletter, a YouTube channel, and a stack of WordPress plugins that, on most days, all play nicely together. When they don’t, somebody has to figure out why — usually at 2 AM, usually with cold coffee, usually muttering things that the cat is too polite to repeat.

Thanks for reading. Special thanks to Sarah for surfacing the bug and naming it perfectly, to Al & Angi for the patience and the gorgeous system photos, to our customer Mark in Thunder Bay for trusting us with those giant Polk towers, and to Kirk, Stéphane, and Darina for giving us the feedback and help we needed at exactly the right moments.

If you enjoy these behind‑the‑scenes write‑ups, we’d love it if you subscribed to our YouTube channel for gear reviews, unboxings, and the occasional bit of small‑business banter.

And to any old Amiga folks who found their way here because of this story: welcome — pour yourself a coffee, browse the systems gallery, and stay a while. We think you’ll feel right at home among all the lovingly maintained vintage tech.

Now if you’ll excuse us, there’s an inbound pair of B&W Matrix 804s that need our attention.

— Mark
Radique Inc.
radique.com