Scripts for the steps we kept forgetting at the end of a long day.

The boring fix

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.

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.

A wide stock photo beside the text
Working notes from the review

Where it breaks

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.

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.

What to check next

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.

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.

The short version

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.

Permissions tend to drift. A role that made sense at launch picks up one extra capability each year until nobody can say who is allowed to do what. We list the roles, list the people and compare them with what the job actually needs. It is a dull hour, and it has found more real problems than most scanners.

What we found first

Every feature has a running cost, even when nobody touches it. It needs testing on each upgrade, explaining to each new editor and checking in each review. When a client asks for something small, we ask who will look after it in two years. Sometimes the honest answer is that it should stay a good idea.