Why edits inside a theme do not survive
A theme update replaces the theme's folder with the maker's new version. Anything you or a developer typed into those files lives in the folder that is being replaced, so it disappears. The theme handbook states the consequence for code plainly: a function added to the parent theme's functions.php will be gone the next time the theme updates. Teams usually discover this the first time an update is applied, and then postpone every later update, which leaves an outdated theme in place. The cure is not to avoid updating but to keep your changes somewhere an update does not touch.
- A colour or spacing tweak made in the theme's main stylesheet is lost in the same way as added code.
- Which customisations are lost depends on where each was stored, which is why the first step is to find them all rather than assume.
How a child theme is loaded
A child theme is a separate folder with a style.css whose header names its parent in a Template field. The handbook says the value must be a 100 percent match of the parent's folder name. The child's functions.php does not replace the parent's: both run, the child's first, so the child can add code and hook into the parent without copying it. Copying the parent's code into the child is discouraged because duplicated function names can cause fatal errors. Whether the child needs to load the parent's stylesheet depends on how the parent loads its own, and the handbook says you must read the parent's code because there are no hard rules.
- Add code in the child; do not paste the parent's functions into it.
- Check how the parent enqueues its stylesheet before copying any style.
What overriding means
A file in the child with the same name as one in the parent replaces the parent's version of that template. For block themes the same holds for template parts and patterns, and patterns must share the same registered slug. You can also add entirely new templates, parts and patterns. Because the child replaces the whole file, an override is a copy you now maintain: if the parent's template gains a fix in a later release, your copy does not receive it. That is the trade-off of using a child theme, and the reason to override as little as possible.
- Prefer a hook or a style rule over copying a whole template.
- Note the parent version each override was made against.
Block themes keep some changes in the database
The handbook explains that in a block theme the layers run from WordPress's default theme.json, through the parent and then the child, to user customisations, and that the user layer is stored in the database and can override theme.json, templates and patterns. It also says grandchild themes are not possible. This matters for a move: changes made in the Site Editor are not in any file, so a file comparison against the vendor's clean copy will not find them. The handbook does not say whether they continue to apply when the active theme changes from the parent to a child, so do not assume either way. Record them before the switch and compare them after it, on a staging copy.
- Take screenshots of the Site Editor's templates and Global Styles views before the switch, and compare them after.
- Do not treat a clean file comparison as proof that nothing was customised.
Settings the theme stores outside its files, and a safer way to switch
Some settings are not in the theme's files at all. The source shown on the set_theme_mod reference page saves a theme's modifications, the Customizer's theme settings among them, in one database option whose name is theme_mods_ followed by the active theme's stylesheet name, and the menu locations reference page shows menu locations read the same way, as a modification of the active theme. The stylesheet name is the folder name of the theme that is active, which for a child theme is the child's own folder; this guide's reading, which a staging copy will confirm, is that a child theme therefore starts with its own, possibly empty, set of these values. For widgets, WordPress's own code maps sidebars with the same slug across a theme change, moves leftovers to the inactive area and restores widget settings from a time the theme was active before, so widgets may need checking rather than re-entering. None of this is stated as a rule in the child theme handbook, which is silent on these settings, so treat each as something to compare, not as given.
A safer sequence is to switch first and update second. Take a full backup of the files and the database before touching the live site: the WordPress backup handbook says the database should be backed up always before an upgrade, that a backup has two parts, the database and the files, and that you need both to restore a typical site. Then activate the child theme while the parent is still at its current version and compare the pages and settings. Only when they match, update the parent and compare again. If the child and the parent update were applied together and something differed, you could not tell which caused it.
- Before the switch, record the menus, the menu locations, the widget placements and the Customizer settings, with screenshots.
- Compare the same list after switching to the child theme, and again after the parent update.
- Practise switching back to the original theme on a copy, so you know the way out before you need it.
Finding every edit, and what the paid job proves
The only reliable way to find edits made in files is to compare your theme folder with an untouched copy of exactly the same version from the maker, and to record every difference with a decision: keep, drop or ask. The child-theme job has a published test price of GBP 395 for a theme with fewer than about thirty differing files. It is accepted when every difference is listed with a decision, the named pages match their before screenshots first with the child active and the current parent and then with the parent replaced by the latest vendor version on staging, menus, menu locations, widget placements and theme settings match or are listed for re-entry, no new PHP error appears, and switching back to the original theme on staging restores the before state. Your site holder takes a test-restored backup before the live switch. If a clean copy of the same version cannot be obtained, the job does not apply.
- Send the theme name, version, where you obtained it and the pages that must not change.
- Prices are untested proposals and payment follows the agreed checks.
Sources and limits
- WordPress theme handbook: child themes Checked 2026-10-11.
- style.css is the one necessary file; its Template header must exactly match the parent theme's folder name.
- A child theme's functions.php does not replace the parent's: both load, the child immediately before the parent, and copying the parent's code into the child can cause fatal duplicate-function errors.
- A same-named template file in the child replaces the parent's; code added to the parent's functions.php disappears when the theme updates; for block themes, loading style.css is often not needed, grandchild themes are not possible, and user customisations stored in the database can override theme.json, templates and patterns.
- WordPress developer reference: set_theme_mod() Checked 2026-10-11.
- It updates a theme modification value for the active theme; the source on the page saves all of a theme's modifications in one option named theme_mods_ followed by the active theme's stylesheet name.
- WordPress developer reference: get_nav_menu_locations() Checked 2026-10-11.
- It returns the registered menu locations and the menus assigned to them, and its source reads them with get_theme_mod( 'nav_menu_locations' ), that is, as a modification of the active theme.
- WordPress developer reference: wp_map_sidebars_widgets() Checked 2026-10-11.
- Its source comments say that when themes change, sidebars with the same slug are mapped, other sidebars are mapped by an educated guess, leftover widgets are moved to the inactive sidebar, and widget settings are restored from when a theme was previously active.
- WordPress developer handbook: back up your WordPress site Checked 2026-10-11.
- It says to back up the database regularly and always before an upgrade, that a backup has two parts, the database and the files, and that you need both to fully restore a typical WordPress site; it lists themes among the files.