This is an overview of a short series about setting up a local development workflow for a WordPress client site. There are more detailed posts on each stage — the repository cleanup, the database preparation, the child theme, and the rebuild. Start here and follow your curiosity.
The site was built. The client was happy. It was live on the internet doing what it was supposed to do.
It should have felt finished.
The thing was, I’d built it almost entirely in the WordPress Block Editor — clicking, dragging, adjusting — and while I understood what it looked like, I couldn’t really explain how it worked. If something went wrong, could I fix it? If I wanted to try something without breaking the live site, how would I do that? If I needed to hand it over, or rebuild it from scratch, where would I even start?
These weren’t questions that needed answers on day one. But they would need answers eventually, and so I decided to find them.
What I actually did
The project already had a GitHub repository. It had started life as a place to track plans and designs, and somewhere along the way it had accumulated the entire WordPress installation — all of it. Plugins, parent themes, cache files, language packs. Things that had no business being in version control.
So I started there: cleaning the repository down to only what was mine and only what was necessary.
The next job was the database. WordPress stores almost everything in a MySQL database — content, settings, styles, layout and so on… To run the site locally, that database needed to be exported from the live server and prepared for local use. That meant more than just downloading a file : URLs needed replacing (in more formats than I expected), the table prefix needed changing, and a handful of host-specific tables needed removing. The full story of what that involved is worth reading if you’ve ever wondered what’s actually in a WordPress database export.
With a clean repo and a portable database, I could look at the theme properly. The site was running on WordPress’s Twenty Twenty-Five theme, but there was also child theme in the repo — something I’d exported at some point during development — and that’s where all the real design decisions could be found : the colour palette, the typography, the layout widths, the custom font files. Understanding what the child theme actually contains, and why those decisions belong in code rather than the database, turned out to be one of the more useful things I learned.
The final step was the proof : a fresh local WordPress install, copy the theme files from the repo, import the prepared database, and see what happened.
What this means in practice
The whole thing now lives in a handful of files in a private GitHub repository. To spin up a local copy of the site — on any machine — takes about five minutes and a copy-paste of one paragraph from a setup document.
That’s not a huge achievement in the grand scheme of things. But it’s the difference between a site that simply exists, and a site you actually have control over. Early days and baby steps but, for a first client project, I’ll take it.
Leave a Reply