Ok, the first-thing I wanted to double-check is that rather than make
any modifications to parent PHP, you simply create one with a
duplicate name in the child directory which completely overrides the
parent file?
No. You don’t create a theme with the same name. You create a theme with whatever name you choose and provide the appropriate header in the style.css file to point to the parent.
/*
Theme Name: Twenty Fifteen Child
Theme URI: http://example.com/twenty-fifteen-child/
Description: Twenty Fifteen Child Theme
Author: John Doe
Author URI: http://example.com
Template: twentyfifteen
Version: 1.0.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
Text Domain: twenty-fifteen-child
*/
The “Template” line is the one that points to the parent:
- The Template line corresponds to the directory name
of the parent theme. The parent theme in our example is the Twenty
Fifteen theme, so the Template will be
twentyfifteen. You may be working with a different theme, so
adjust accordingly.https://codex.wordpress.org/Child_Themes#How_to_Create_a_Child_Theme
Next…
Master stylesheet remains in parent but the live stylesheet will be
from child which will typically import the parent stylesheet at the
header of child CSS.
Yes. The child stylesheet will be read by WordPress Core for basic theme data, but still needs to be enqueued. The parent stylesheet will not be. It seemed to be pretty common to @import the parent and if I recall correctly the Codex used to suggest such a method. A CSS @import is not an efficient way to load a stylesheet though. It introduces lag in the page load as both stylesheets cannot load synchronously. A better way is that which now appears in the Codex using Core enqueue functionality:
function theme_enqueue_styles() {
$parent_style="parent-style";
wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
wp_enqueue_style( 'child-style',
get_stylesheet_directory_uri() . '/style.css',
array( $parent_style )
);
}
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
Anyway back to child themes… the main thing I am unclear about is
that we’re supposed to leave parent functions.php in tact. However
parent functions.php typically define a whole load of include/requires
which refer to files in parent directory.
That is correct, and that is why you leave that file alone (among other things).
Do you need to remember to over-ride these in your child function.php
each time you create a child.php?
You only need to override the files and code that you need to override. The rest continues to function as normal based on the parent theme code. That is the point of the parent/child relationship and is why that structure is so powerful and flexible. You can leverage the code base of one theme to greatly reduce the effort needed to make another one.
The child functions.php run before the parent functions.php so the
override sould work.
Here you have to be careful. You can only override code that is meant to be overridden. For the most part, that means files included via get_template_part() and related functions that are child-theme sensitive and functions wrapped in if(!function_exists)'...')) conditionals. Code include via PHP’s require and include (or the *_once versions) cannot be overridden. Similarly with functions you can only override functions that are wrapped in if(!function_exists('...')) as you see used in the Core pluggable.php file. If you try to override any other function by providing one of your own of the same name you will get a fatal PHP error. PHP does not allow multiple functions of the same name.
You might be interested in this answer as well.