Wrestling with Stale Caches and Server Migrations While Fixing Navigation State Logic

Had one of those development sessions where you fix the code perfectly, but then spend twice as long dealing with infrastructure quirks.

The Good Stuff

Started the day tackling some gnarly state management issues in the photo booth site navigation. The county nav links were hardcoded to use -ca/ which obviously breaks when you're not in California. Fixed it with a nice fallback pattern: c.state || (_s && _s.state) || _s || 'ca'.

Also had to deal with some data format inconsistencies where bbs_features was sometimes coming through as flat strings, sometimes as proper {icon, label} objects. Instead of trying to fix it at the write level (which felt too risky), I added PHP normalization right at data-load time in template-city.php. Clean, isolated, and covers all the render sites.

The P1 interlinking audit is finally done - all 56 pages returning 200s, plus got both the MMB venue hub (13 venues) and Golden venue hub (22 venues) fully verified.

The Annoying Stuff

Then I hit the classic developer frustration trifecta:

Problem 1: LiteSpeed cache being stubborn. Even after wp cache flush and clearing Breeze directories, the navigation JS was still stale. Had to use ?nocache=1 to confirm the fix was actually live in the code - just cached to hell.

Problem 2: Discovered majesticmirrorbooth.com production is still on the old server (162.211.85.234) throwing fatal errors with Cannot redeclare hb_ensure_page(). Classic function redeclaration conflict because the old server has both an outdated plugin AND an old hb-rest-api.php without the function_exists guard.

Problem 3: No SSH access to that old server, so I can't just patch it directly.

The Path Forward

Sometimes the cleanest solution is the most obvious one - just need to do the domain cutover and point majesticmirrorbooth.com DNS to our Cloudways server (45.55.153.250). The staging version at majesticmirrorbooth.gethoneybun.com is working perfectly.

Also want to dig into why the DCC import flow is sending flat strings to bbs_features in the first place. Understanding the root cause will help prevent this kind of data inconsistency in the future.

One of those sessions where you realize that writing good code is only half the battle - the other half is dealing with legacy infrastructure and cache invalidation. But hey, at least the navigation state logic is rock solid now.