An update notice appears for the parent theme. You pause before clicking, because you cannot quite remember what your child theme depends on. So you start reading code, and that turns into half a day of excavation every single time.
It takes that long not because it is hard but because nothing was written down. Dependencies are obvious while you are creating them and vague two months later. Record them as you go and the update becomes a checklist.
What belongs on the list
The most dangerous of these is the overridden template, because an override is a copy frozen at a point in time. When the parent revises that template your copy keeps the old markup and ages without a single error. If a new feature arrived in that file, your site is the only one missing it.
Hooks fail just as quietly. Rename a hook upstream and your callback simply never runs; nothing fatal happens, so discovery is late. Ironically, calls to parent functions are the safest of the group — remove the function and you get an immediate fatal error rather than silence.
Generate the list, do not write it from memory
Memory leaves gaps. Most of this can be extracted mechanically with a search.
# Overridden templates — any file whose name also exists in the parent
ls child-theme/*.php child-theme/template-parts/*.php
# Places depending on parent functions (search the parent function prefix)
grep -rn "parenttheme_" child-theme/ --include="*.php"
# Places attached to parent hooks
grep -rn "add_action|add_filter|remove_action" child-theme/inc/Collect the results into one document inside the repository. No special tooling is needed, and keeping it beside the code is what makes it get updated. A document that lives elsewhere is guaranteed to go stale.
Also record the parent version you verified against. The next review can then start from “what changed between that version and this one”, which narrows the work dramatically on its own.
The review procedure
The order is clone to staging, swap the parent, walk the list, merge the differences, then ship — production is always the last step, never the first.
Never click update in production. Put the new parent on a staging copy and work through the list line by line. Overridden templates in particular need a three-way comparison: the old parent file, the new parent file, and your copy. Carrying the parent’s changes into your copy is the actual work of this stage.
Turn automatic updates off. Unverified changes arriving on their own sits in direct conflict with deploying what you tested. An update is “verify the new files on staging, then swap them in” — not a notification you dismiss by clicking it.
Closing the series
Across eight parts we went from the template hierarchy through asset load order, template parts, the build setup, output escaping, secondary queries, asset removal and update reviews. One principle ran through all of it: confirm rather than guess. Which file renders, in what order things load, what actually broke, what you depend on — every one of those was checkable.
That is also why WordPress has lasted. The rules are documented and the extension points are public, so you can build the screens you want without ever touching the parent theme. What causes trouble is never the tool — it is time accumulating without a record.
If you would rather hand this work over — version upgrades, performance, security review, structural clean-up — our optimization program takes it as one job, and the exact order we work in is published on the process page.