Situation
“Don’t update the theme, it breaks the site”
We took on a WooCommerce store with that instruction attached. The reason turned out to be simple. Over the years, changes had been made directly to the theme’s own files on the live site: contact details in the header, a block of styling, a tracking tag, the colour scheme. Every theme update would have wiped them. So nobody updated, and the store fell further behind on security fixes with every release it skipped.
What we did
Put every change where it belongs
- Version control first The theme and plugins went into a repository, so from this point on there is a record of what changed and why.
- A child theme Every customisation found in the parent theme, and the CSS that had been pasted into the Customizer, moved into a child theme named for the store. The parent theme is now untouched and can be updated.
- The same store, tidied The sticky header was fixed to work in both scroll directions and to stop replaying its animation, a horizontal scroll on the homepage was removed, and the header logo was given its proper size.
- Updates applied With the customisations safe, the plugins that had been waiting were updated.
Result
Looks the same. Can be updated.
0customisations left in the parent theme
1child theme, under version control
The store looks the same as it did before. That is the point. The theme can now be updated, the changes survive, and there is a record of who changed what.
Worth checking on your store
If you have been told not to update something
- Ask why. The answer is usually an afternoon’s tidying that nobody got round to.
- Check whether a child theme is active. If the active theme is the commercial one itself, your edits are in it.
- Count the plugin updates waiting. Each one is a security fix you do not have.