Designing the empty state

What a site looks like on its first day says a lot about its theme.

What we changed

Clients rarely remember the clever parts. They remember whether the site stayed up, whether the invoice matched the estimate and whether someone answered when it broke. We try to write code with that in mind. A plain solution that a tired person can repair at the end of a long day beats an elegant one.

Writing it down was the last step and possibly the most useful one. A short note about what we tried, what failed and why we stopped has saved us more time than any tool. When this comes up again, and it will, someone will search the repository, find these paragraphs and skip the whole expensive afternoon.

How we tested it

We started by reading the code rather than the documentation, because the code is what runs. Most of the surprises in a WordPress project live in the gap between what a function promises and what the theme actually asks of it. An hour with the templates open told us more than a week of status meetings ever had, and it gave us a list of real questions to bring to the client.

The first measurement is always the most useful one, even when it is rough. Write down the query count, the page weight and the time to first byte before you change anything. Without those numbers you cannot tell an improvement from a coincidence, and three weeks later nobody will remember what the site felt like before you touched it.

What we would do differently

Caching hides problems as often as it solves them. A page that is fast only when the cache is warm is a page that falls over on the morning after a release, which is exactly when people are looking at it. Test the cold path on purpose. Clear everything, load the home page once, and read what the database had to do.

Nothing here needed a new plugin. The fix was a small change to a query and a better idea of when to run it. That is usually the case: the expensive part of a site is rarely the code you can see, and adding a layer on top only moves the cost somewhere harder to find. Delete first, then decide what is still missing.

The boring fix

Escaping belongs at the point of output, where a reviewer can see it. When a value has been cleaned three functions earlier, nobody can tell by reading the template whether it is safe, and the next person to touch that line will not know either. We moved every escape next to its echo and the file got shorter and easier to trust.

The review took longer than the fix, and that is the right way round. Most of the time went on working out what the code was meant to do and who depended on it. Once that was written down, the change itself was four lines, a test and a note in the changelog that future maintainers will actually thank us for.

Where it breaks

A throwaway site is the cheapest tool in the kit. We can build one in a minute, break it completely and delete it without a single awkward conversation. Everything risky in this post happened there first, including the mistakes we are not going to mention, and nothing touched production until it had survived a full run from a clean start.

Releases go badly when they are exciting. Our best ones are dull: a checklist, a backup someone has actually restored, a rollback plan and a time of day when the people who can fix things are awake. If your release needs courage, something earlier in the process needs more attention, and a calmer Tuesday afternoon will show you what it is.

What to check next

Keyboard testing costs nothing and finds real bugs. Put the mouse in a drawer and try to use the page with the tab key alone. You will find focus styles that vanish, menus you cannot leave and buttons that are really links. None of these need a specialist to spot, and most of them take minutes to put right.

We kept the change small on purpose. It is tempting to tidy everything nearby while the file is open, but every extra line makes the review slower and the rollback riskier. A short diff that does one thing gets merged this week. A long diff that does six things gets argued about until someone quietly closes it.

The short version

Scheduled tasks deserve more suspicion than they get. WordPress runs them on the back of ordinary page views, so a slow job can land on a visitor who did nothing to deserve it. List what is registered, work out what each job does and how long it takes, and move the heavy ones to a real system cron.

Names matter more than cleverness. When a function says exactly what it returns, the template that calls it reads like a sentence and the bug has nowhere to hide. We renamed more than we rewrote on this project, and the reviewers noticed. Six months from now that will be worth more than any micro-optimisation we could have shipped.

What we found first

Migrations fail in the details: serialized data, hard-coded URLs and that one plugin nobody remembers installing. We make an inventory before we move anything, then we move it twice, once for practice. The rehearsal always finds something. Finding it on a Wednesday at a desk is much better than finding it on launch night with the client watching.

Good defaults are a kindness to the next person. If a feature only works after someone reads a long page of setup notes, then for most sites it does not work at all. We would rather ship something modest that behaves well on a fresh install than something impressive that needs a careful afternoon before it shows anything.

Why it matters

The numbers moved less than we hoped, and that is worth saying plainly. Posts like this tend to end with a dramatic chart, but real work mostly produces a steady, unglamorous improvement. The page got a little faster, the logs got a lot quieter and the support inbox stopped filling up on Monday mornings. We will take that.

Logs are the cheapest witness you have. Before anyone proposes a theory, we turn on debug logging on a copy of the site, repeat the problem once and read what it left behind. Half the time the answer is sitting there in plain words, and the other half we at least know which theories to stop discussing.