Everything here survives updates. That is the whole reason to use these routes rather than editing files directly.
#Getting a child theme
Two ways. By hand, as a classic WordPress child theme. Or with the generator built into our toolkit, which creates and activates a ready child theme in a few clicks.
The built in route is the one to use. The manual route is for people who want to control every file.
#Overriding templates
One idea covers all three sources: a file placed in the child theme takes precedence over the file in the product.
- The theme
The native WordPress mechanism. Copy the template or the template part into the child theme, keeping the same path, and edit the copy.
- The Pro plugin
Move the plugin's templates folder into the child theme and rename it to the plugin slug.
- An integration
The same rule, with the folder named after the integration slug.
So the child theme ends up with the theme files at their normal paths, and one folder per plugin or integration whose templates you override.
#Copy as little as possible
An overridden template stops receiving our changes. Every file you copy is a file that will slowly drift away from the product.
Before copying anything, check two things: whether a setting already does it, and whether a filter already does it. Both are cheaper than owning a template forever.
An overridden template is your code from that moment on.
If it breaks after an update, that is the expected consequence of pinning a file rather than a regression, and it is exactly why the advice is to copy the minimum.
#Filters, hooks and front end events
This is the supported way to change logic. Customization through these points survives updates; changes made around them do not, and are outside support.
The extension surface is being deliberately widened before release, so the specific names, signatures and examples are documented last. Publishing them early would mean documenting something that changes before anyone reads it.
What the surface covers: general extension points in the theme and the Pro plugin, filters over the query and the markup of post listings, insertion zones in the single post, and front end events fired when content loads without a page reload, which covers continuous reading and pagination.
If the extension point you need is missing, send a feature request. We do add hooks on request.
#Common questions
Does a child theme slow the site down?
Not measurably, since it loads one extra stylesheet reference, which is not where a page's weight comes from.
Can I create a child theme after the site is built?
Yes, because content and settings live in the database, though it is worth walking the site afterwards since a few settings are stored per theme and start empty on the child.
Which is better, a filter or a template override?
A filter whenever one exists, because it survives updates to the template while an override pins the file as it was on the day you copied it.
How do I know which template to copy?
Find the one that renders what you want to change and copy only that one, since copying a parent template "just in case" pins a file you never needed to own.
An override stopped working after an update
The template you copied changed on our side, so compare your version against the current one and reapply your edit on top of the new file, which is the standing maintenance cost of every override and the reason to keep the number of them small.
#Still stuck
Open a support ticket with what you are trying to change, and we will tell you whether a filter already covers it.
Last updated
