root@labs:~$ cat building-the-new-rootlabs-us-the-process.md

Building the new rootlabs.us: the process

The last post covered what the new rootlabs.us runs on. This one is about how we actually got from the old site to this one without breaking things in public.

Step one: put up a curtain

Before touching anything, we pointed the domain at the new server and parked a construction page behind HTTP basic auth. That let us work on the real site at the real domain, with real HTTPS, while visitors saw nothing but a password prompt. No staging environment, no docker-compose theater. A password in a Caddyfile.

Step two: migrate, then demolish

We copied the old site over and immediately started deleting. The old Root Labs was built as an IT services company, and the new one is not, so out went the services pages, the payment integration, the client case studies, and every hardcoded credential we found along the way (there were several, and they all live in a .env file now, where they should have been from the start).

Step three: design before code

We mocked three visual directions as plain HTML before committing: an industrial workbench look, a loud zine style, and a quiet lab notebook with a terminal streak. The notebook won, then got refined through a second round of variations. Only after that did we rebuild the actual pages. Designing in throwaway HTML was faster than designing in the real codebase, and much faster than arguing about it in the abstract.

Step four: make WordPress blend in

The blog needed to feel like the same site, not a stock theme bolted on. So the theme you are reading loads the exact same stylesheet as the main site and reuses its sidebar. A few hundred lines of blog-specific CSS handle post typography and the forums.

What went wrong, because something always does

A missing display rule made an invisible div eat the entire page layout. A cached stylesheet made the new site look like the old one at the worst possible moment. A config tool wrote an unquoted constant into wp-config.php and took the blog down for about a minute. Each one taught us something, which is the whole point of writing these down.

The lesson

Working behind basic auth on the production domain is underrated. Every mistake we made happened in private, on the exact infrastructure the public site now runs on. When launch day came, launching was just deleting four lines of config.

Leave a comment

Your email address will not be published. Required fields are marked *