Arguing that theme updates should not induce panic attacks
Sounds like a pretty reasonable expectation, right?
But when it comes to WordPress themes that include everything but the kitchen sink, that’s not always the case.
Here’s an example, quoted from a WordPress.org support forum thread entitled Premium Themes That Won’t Give Panic Attack Upon Updating?
[Premium” theme name redacted]’s had 7 updates and a few have required days to repair my site. Many elements on site become completely changed, different and terrible looking.
This makes me sad.
Why theme updates are necessary
No theme is perfect. Coding standards change. Bugs are overlooked. Security vulnerabilities are discovered. New core features need to be accounted for.
But a balance needs to be struck between managing technical debt and not completely disregarding theme customizations made outside of the parent theme.
It seems like some theme makers, however, would rather deal with support blowback rather than manage technical debt in a responsible way.
How theme updates can break sites
The easiest way for a parent theme update to break a child theme’s customizations would be to change the HTML markup.
If a child theme is trying to style .this_selector, and the parent theme changes it to .this-selector, that child theme CSS rule gets thrown out the window.
Besides that, it could be any combination of function name conflicts, use of deprecated functions, use of functions that aren’t supported by the user’s PHP version, and a few other things.
If any of these scenarios occurred, using a child theme wouldn’t prevent your site breaking.
Child themes are not a magic bullet
Child themes (and custom CSS plugins) are frequently touted as the “safe” way to preserve your theme customizations.
Child themes are certainly a safer alternative to modifying parent themes directly. Any child theme code is immune to being overridden by a parent theme update. That much is true.
But characterizing child themes as “safe” while ignoring the risks that irresponsible parent theme updates bring to the table can lead to a false sense of security.
Consider retiring old themes
Just like you can’t buy the original iPod from Apple anymore, themes don’t last forever either. WooThemes has a long list of retired themes, and their reasoning makes perfect sense.
We do this when we feel we’ve managed to replace aging products with newer ones that have better design and more functionality and features, but also because only a bit of value remains in older products.
Retiring products ensures that everyone receives the best. Retirements also help us focus on and develop current and future products that our customers are waiting for.
Instead of retirement, forking is an option as well. Recently, Thematic was discontinued by its developers only to start fresh under another name.
Not only does this offer the opportunity to leave behind legacy code, having a technically new theme much more effectively manages a user’s “upgrade” expectations…because it’s not an upgrade.
A user must deliberately install a new theme to take advantage of it, even if the code is largely the same after the initial fork. It’s not as easy as clicking the “Upgrade” button in the admin.
Use a staging site, seriously
Ultimately, the only way to prevent a panic attack when updating themes on a live site is to…not update themes on a live site. Many managed WordPress hosts offer this as a feature.
Testing code before deploying on a live server before is a pretty common practice in the software development world, yet for some reason, many WordPress site administrators go the cowboy coding route.
At the very least, take a backup beforehand, and have an easy method of rolling back if necessary. VaultPress is a great choice for this, if you don’t use a managed WordPress host.