Types of Customizations

The single biggest question we get when someone is looking to update their theme is "what about my customizations". The problem is that we have no idea what customizations you're talking about - how they were done, when they were done, why they were done.

Our recommendation is always let go of your previous setup and install the newest update the theme from scratch. Our theme philosophy is that if someone were installing a theme from scratch, what would the best configuration be? That is how we design the theme, regardless of how it was designed in the past.

A "theme update" is actually a brand new theme install, with modern best practices.

The best way to do this is to create a staging site and just install the new theme, then go through and see what you need to change (and ask yourself: why am I making this change?).

We recommend not making extensive customizations, because troubleshooting is incredibly complex. Once you've started customizing and configuring the theme outside how it's designed to behave on the demo site, you've created your own custom theme that is entirely your responsibility to maintain. Custom themes cost $10,000 to have built, not $75. An off-the-shelf child theme is not a custom theme.

Here's a breakdown of ways we've seen people customization their themes and how(/if) they can be preserved.

Editing theme files

Don't ever edit theme files.

These changes are overwritten during updates and extremely difficult to maintain and carry over.

These have to be done with a diffcompare/diffchecker tool, on a file-by-file basis, using the original theme files. This can only be done manually by someone familiar with the files, at around $100/hour.

All customizations should be done in the "Additional CSS" screen, or the code snippets plugin.

CSS customizations in "Additional CSS"

Difficulty: Easy peasy.

Supported: Paid customization.

Install the new theme (you don't need to delete the old one) and then simple copy (ctrl+c) the "Additional CSS" screen from the old theme, and paste (ctrl+v) it into the "Additional CSS" in the new theme.

Done.

We change very few of the selectors/classes in the theme, so almost all the old CSS will stay in place.

CSS customizations in style.css

Difficulty: Very hard.

Supported: No.

You've edited the theme file, and you shouldn't have. The "Additional CSS" is where styling customizations belong.

In order to figure out what you've done, you'll need to use some sort of diff compare program (Google it). This is tedious and time consuming.

Copy everything you find over to your "Additional CSS" screen so you don't have to do this again.

CSS customizations in a custom plugin

Difficulty: None.

Supported: No.

The plugin will not be modified by our theme during a theme update and all your customizations should stay in place.

While not the recommended scenario (hard to track down + troubleshoot), at least this stays in place.

CSS customizations in the code snippets plugin

Difficulty: None.

Supported: Paid customization.

The Code Snippets Plugin comes with some examples on how to add/insert CSS, and anything in the code snippets plugin isn't lost by changing themes.

A note of caution: Having the CSS output in the header with the right "priority" is difficult. We recommend you use the "Additional CSS" screen instead of the code snippets plugin for this, because it's overkill.

Coding customizations in functions.php

Difficulty: Very hard.

Supported: No.

This was the defacto standard for years, and even we recommended this. Everybody did. It was a stupid setup from everyone from WordPress through Genesis and all child themes, with the idea that "child themes should never be updated".

We're sorry. Nobody knew better.

At least now, we can recommend the code snippets plugin.

Unfortunately, there's no automatic way for us to pull these over.

In order to figure out what you've done, you'll need to use some sort of diff compare program (Google it). This is tedious and time consuming.

Take these differences and drop then into the code snippets plugin so that you never have to do this again.

Coding customizations in a custom plugin

Difficulty: None. (usually)

Supported: Paid customization.

Similar to the CSS customizations in a custom plugin, these action and filter overrides aren't changed by the theme during an update. This means they're preserved.

Certain things are removed from the themes as they become obsolete, and this may affect customizations in a custom plugin.

While custom plugins are a viable option, they fail at being simple to edit and maintain. Any custom plugin coding should be moved to the Code Snippets Plugin.

Customizations + features in the Feast Plugin

Difficulty: None.

Supported: Yes!

The Feast Plugin is our solution to the problem of features and coding in the child themes. By putting things into a plugin, we can provide features that can be updated without having to re-install the theme. We can rewrite, improve, account for new cases and generally improve features over the years and deliver them to everyone through an automated update that properly preserves settings.

A perfect example of this was the Genesis 3.1.0 release, where we were able to squash the piece of code in Genesis causing an issue, the very next day. It took 2 weeks to find a comparable solution for the themes.

These features also (mostly) work across all themes, meaning you don't have to switch themes just to get a certain feature.

Our focus has been primarily on introducing improvements and new features, rather than rewriting existing features in the themes. Newly rewritten and improved versions of theme functionality will be introduced in the future in a way that is compatible with the block editor.

Additional reading

Want to better understand the role of themes and customizations? Read these:

• Themes vs. Customizations
• What am I paying for with a theme?
• Theme update philosophy
• Customization referrals
• Principles and Best Practices