Arguing that theme updates should not induce panic attacks

theme-update-panic

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.

4 comments

  1. Important & solid advice for theme developers. Retiring old themes is something many don’t bother doing unfortunately, and that ultimately has the potential of becoming a major headache for them.

    1. Absolutely. For not just the developers, but unsuspecting users who assume that the theme is kept up-to-date with best practices.

  2. This is why I think it’s important to have an easy way to check the changelog for theme updates. Just like plugin updates already have, theme updates should have a clear link to a changelog. I want to know the summary of changes before upgrading. Trac ticket for this started 4 years ago (ticket #22810) and a couple of attempts were made to discuss it. I just brought this up again at https://make.wordpress.org/themes/2015/04/29/a-revised-readme/ 2 days ago, and Ulrich replied that no one is leading the effort at the moment. It wouldn’t solve all problems of course, but it would be a start. Thanks for the interesting post.

    1. Agreed. The reasons behind theme updates can range from “minor edge case CSS bug” to “major security vulnerability.” Having a theme changelog would certainly help manage user expectations better than blindly upgrading and seeing how it affects things.

Leave a Reply

Your email address will not be published. Required fields are marked *