WordPress Child Theme functions.php That Survives Updates

You changed a few lines in your theme, the theme updated, and your changes are gone. That is the problem a child theme exists to solve, and it solves it completely, as long as the child theme’s functions.php is written the way WordPress actually loads it.

The short answer: put your changes in a child theme, which is a separate folder whose style.css names the parent in a Template: header. The child’s functions.php does not replace the parent’s; both run, and the child’s loads immediately before the parent’s. So you add code to it, you never copy the parent’s functions.php into it, and you change parent behavior through hooks rather than by redeclaring the parent’s functions.

Everything below follows the WordPress Themes Handbook page on child themes, read 2026-09-11, with WordPress 7.1 as the current release.

Before you touch a live site

Back up first, and do this work on a staging or local copy, not on production. A single PHP syntax error in functions.php can take the whole site down, front end and admin together. Keep a copy of the working file, make sure you have file access to the server (SFTP or your host’s file manager) so you can undo a broken change without the dashboard, and avoid editing theme files through the dashboard’s built-in file editor on a live site. If the site does go blank, finding the error behind a WordPress white screen walks through recovery step by step.

The one file a child theme needs

The handbook is precise about the minimum: a child theme needs a style.css with a file header containing the Template field. Its example:

/**
 * Theme Name: Grand Sunrise
 * Template:   twentytwentyfour
 */

The Template value “must be a 100% match of the folder name of the parent theme, relative to the wp-content/themes folder.” Not the display name. The folder name. Twenty Twenty-Four will not work; twentytwentyfour will. A wrong value here is the most common reason a child theme shows up as broken in the Themes screen.

Everything else, including functions.php, is optional. Add it when you need PHP.

How the two functions.php files load

This is the fact that decides how you write every line of the child’s functions.php. The handbook states that “they are both loaded, with the child being loaded immediately before the parent.”

Three consequences follow.

1. Your file is additive. It does not replace the parent’s. Anything the parent’s functions.php does still happens. You are adding code alongside it.

2. Never copy the parent’s functions.php into the child. The handbook warns against it directly: the same functions would be declared twice, and PHP stops with a fatal error. That exact failure, and why a function “runs twice”, is covered in Cannot redeclare function in PHP. Copy the one function you want to change, rename it, and hook it in.

3. You cannot override a parent function just by declaring one with the same name, unless the parent wrapped its function in a function_exists() check. Because the child loads first, a parent that does check will see your version already defined and skip its own. A parent that does not check will collide with yours. Read the parent’s source before relying on this: if the function is not wrapped, overriding it by name is not an option.

Change parent behavior through hooks

Because both files run, the durable way to change what the parent does is through the actions and filters it exposes:

• To add output or behavior, attach your own callback to the action the parent uses.
• To change a value the parent produces, use the filter the parent applies to it.
• To stop a parent callback running, remove it with remove_action() or remove_filter(), called after the parent has added it. Since the child’s file loads first, the parent’s add_action has not happened yet when your file runs, so do your removal from a hook that fires later, such as after_setup_theme or init.

Hooks are the contract a parent theme offers. Code attached to them survives updates as long as the parent keeps the hook.

Loading the parent’s stylesheet

For classic parent themes, the child usually has to load the parent’s CSS. The handbook’s recommended code:

add_action( 'wp_enqueue_scripts', 'grand_sunrise_enqueue_styles' );
function grand_sunrise_enqueue_styles() {
    wp_enqueue_style( 
        'grand-sunrise-parent-style', 
        get_parent_theme_file_uri( 'style.css' )
    );
}

If your child’s own style.css also needs loading and the parent does not already load it, enqueue it with the parent’s handle as a dependency so it always prints after the parent’s and wins the cascade. wp_enqueue_style (reference read 2026-09-11) takes that list of handles as its third argument:

wp_enqueue_style(
    'grand-sunrise-style',
    get_stylesheet_uri(),
    array( 'grand-sunrise-parent-style' )
);

Put that second call inside the same function. Before you add it, check the parent’s own enqueue code; some parents already load the active theme’s stylesheet, and loading it twice is harmless but wasteful.

Paths: child first, parent as fallback

Hard-coding a path to the parent directory is the quiet way a child theme stops being able to override anything. WordPress provides lookups that prefer the child. The reference for get_theme_file_uri (read 2026-09-11, since WordPress 4.7.0) says it “Searches in the stylesheet directory before the template directory so themes which inherit from a parent theme can just override one file.”

In WordPress terms, the stylesheet directory is the child and the template directory is the parent. get_stylesheet_directory_uri() points at the child, get_template_directory_uri() points at the parent. Use get_theme_file_uri() when you want “the child’s copy if it exists, otherwise the parent’s.”

Overriding templates, and the cost nobody mentions

The handbook says you can override parent templates, template parts or patterns by “adding a file of the same name in your child theme.” For patterns, the registered Slug field has to match.

This works, and it has a cost. An overridden template is a frozen copy. From the moment you copy it, parent updates to that file no longer reach your site: bug fixes, accessibility improvements and security-relevant escaping changes included. The child theme protects your changes from the update, and it also protects the old version of that template from every later fix.

So override as few files as possible, prefer a hook when one exists, and when you do copy a template, record which parent version you copied it from. After each parent update, compare your copy with the new original.

Block themes: most of the work moves to theme.json

If the parent is a block theme, the handbook notes that style handling is “generally done via theme.json” rather than style.css. A block child theme still needs the style.css header, but most of its visual changes live in its own theme.json, and its functions.php is for behavior only.

The same page notes that user customizations made in the Site Editor act as another override layer and are stored in the database, not in the filesystem. Changes saved there belong to the site, not to either theme, which is worth knowing when a child theme’s change seems to be ignored.

Small PHP habits that save a child theme

• Omit the closing ?> tag at the end of functions.php. A stray blank line after it sends output early and produces the error explained in Headers already sent in PHP.
• Prefix every function name with something unique to your child theme, so it can never collide with the parent or a plugin.
• Log errors, do not display them. On any site a visitor can reach, keep error display off and write to the debug log instead, as set out in WP_DEBUG_LOG without displaying errors.
• Keep site functionality out of the theme. A custom post type or a shortcode that content depends on belongs in a plugin, because content should survive a theme switch. A child theme is for presentation.

What survives a parent update, and what does not

Change	Survives a parent update?
Code in the child’s functions.php	Yes. The child folder is not touched by the parent’s update
Hook callbacks on the parent’s actions and filters	Yes, as long as the parent keeps those hooks
Overridden template files in the child	The file survives, but it stops receiving the parent’s fixes
Edits made directly inside the parent’s files	No. Replaced by the update
Code relying on a parent function by name	Only while the parent keeps that function

FAQ

Does a child theme’s functions.php replace the parent’s? No. The WordPress Themes Handbook says both are loaded, with the child’s loaded immediately before the parent’s. The child’s file adds to the parent’s.

Why did my site crash after I copied the parent’s functions.php into the child theme? Both files run, so every function is declared twice and PHP stops with a fatal “Cannot redeclare” error. Copy only the specific function you need, rename it, and attach it to a hook.

How do I override a parent theme function in a child theme? Only if the parent wraps it in function_exists(). Because the child loads first, your version is defined before the parent checks. If the parent does not wrap it, change the behavior through the parent’s hooks or remove its callback with remove_action() from a later hook.

Will my overridden template files be updated with the parent? No. A template copied into the child theme stays exactly as you copied it, so compare it against the parent’s new version after each update.