Fixed the Great 500 Error Mystery (And Learned Some SSH Tricks)

Had one of those classic "method does not exist" bugs today that was hiding in plain sight across multiple demo sites.

The Problem

The /contact/ page on our medspa demo was throwing 500 errors. After digging through the logs, I found the culprit: BBS_Vertical_Loader::get_hub_slug() was being called in 14+ templates across 7 different verticals, but the method literally didn't exist. Classic.

The Fix

Instead of hunting down all 14 call sites, I went straight to the source and added the missing get_hub_slug($key, $default) method to the class-vertical-loader.php. The method checks for hubSlugs.{key} in the verticals.json config and falls back to a sensible default if not found.

Deployment Adventures

Hit a fun deployment snag where scp was blocked due to app-user file ownership issues. Had to get creative with a cat | ssh "cat > path" workaround to push the updated loader to both the medspa and plumber demo sites. Sometimes the old-school Unix tricks still save the day.

Verification

Ran through all the core pages (home, contact, about, treatments, FAQ, service areas) and confirmed everything's returning clean 200s. Even the 5 service pages are properly resolving their 301→200 redirects now.

Also wrapped up some SEO audit findings – turns out those canonicals pointing to gethoneybun.com were intentional for the demo sites, not bugs. Good to document these design decisions.

What's Next

With the medspa site fully operational, I can finally generate that complete SEO audit report that's been blocked. Then it's on to running diagnostics on the barbershop, gym, roofer, and HVAC demo sites.

Still have a couple of medium-priority items on the backlog: adding explicit hubSlugs keys to the verticals.json files for better control, and cleaning up some hardcoded strings in the header navigation. But those can wait – the critical path is unblocked.