Child Theme vs Duplicate Theme Renamed

Question

Okay, I quite often see people talk about child themes and the reasons for using them instead of modifying the existing theme, but they all seem to center around the idea that if the parent theme is updated all changes will be lost. When I've created sites in the past, I have always made a duplicate of the starting theme, changed the theme name in style.css, and worked directly there. It seems to me that using a single theme instead of a child theme would save overhead, and allow greater control over the code - removing unnecessary functions rather than working around them, for example. If I run into issues, I always have the original theme files to reference, and if the parent theme is updated, my child theme could still break anyway if function names and such change, so I don't see that as a real benefit.

My web searches haven't turned up much on this topic save "developer preference", which is not really a reason.

Are there any real benefits of using a child theme over duplicating and renaming the theme?

Answer 1

Child Themes are useful for users who mainly want to make style changes to their Theme, but don't want - or know how - to maintain the underlying code. Grokking PHP/WordPress Theme Development is an entirely different thing than grokking CSS.

Child Themes are also useful for users who want to implement minor functional changes to their Theme. This is especially useful for Themes that provide a lot of means for modification: action/filter hooks, pluggable functions, etc. Granted, such mods could just as easily be implemented via custom Plugin, but such a Plugin would only apply if the correct Theme is active, so it makes just as much sense to put this code in a Child Theme.

If you're comfortable with maintaining a forked Theme, and find that your modifications exceed what would be reasonable for a Child Theme, then by all means: fork the Theme.

It all boils down to the method that is most beneficial to the individual end user.

Answer 2

In addition to Chip Bennets answer

Some developers like myself have their own custom frameworks or are using one like Genesis, Hybrid, etc. Those frameworks don't bundle too much styling, but more functionality like their own templating and hooking mechanisms. Sometimes also stuff like CPT or CT base classes, meta box libraries, css frameworks, etc. It's often just easier to maintain all your code in separated repos, bundle them in a "Theme" and then just use those parts in your child theme.

In my case, my framework/library/parent theme has nothing than the loading mechanism for my library parts, my hooks and tempalting and a bootstrap function. In a child theme I can then just define what I need for a specific task, add single task modules or extend parent base classes. Last but not least: the Child Theme contains all of my UI parts: Styles, scripts, images.

So for me and many other devs it's just a neat way to keep things generalized, organized and reusable.

Answer 3

One of the biggest uses for child themes is in MUWP instances. Often, in a multisite install, the related sites share some or most of the theme, but may need to have some custom page layouts or element styles. In this case, it makes a lot of sense to use child themes. Elements that are the same are addressed in the parent theme (which may in fact be a custom theme based on a duplicated default theme, as per your hypothetical), elements that need to differ are addressed in the child theme(s).

The beauty of child themes is that the only differences between the child theme and parent theme are clearly seen in the child theme itself. Want to know what's different between a parent and child theme? The child theme itself is the sum of those differences. Need to change something on the child theme? You need only look through a few rules and functions, rather than wading through the code for the entire theme.