Themetry is no longer operational. This site is here for archival purposes. See what Leland is working on at le.land.

Have you ever created a custom theme, and seen an unexpected update notice?

Ever click that unexpected update notice, and find that your custom theme has been replaced by a totally different theme?

If you haven’t run into this situation before, it may sound implausible. But it isn’t.

If your theme happens to have the same slug and lower version number as one hosted on WordPress.org, this exact scenario is totally possible. But not to worry, I’ll show you how to prevent it from happening.

Simulating an unwanted update notice

The following two conditions need to be met:

  • Your proprietary theme slug must match one on WordPress.org
  • Your proprietary theme version must be lower than the one on WordPress.org

Let’s say my proprietary theme has a slug of “bravado” (wp-content/themes/bravado/) and the version in the stylesheet is set at 1.0.0.

But there’s also a theme called Bravado hosted in the WordPress.org theme directory and its version number is 1.0.1.

The slug matches. The version number is lower. Both conditions are true. Update notice for a totally different theme appears.

Preventing an unwanted update notice

There are several techniques to prevent an unwanted update notice from appearing.

Use a weird slug

Your slug can be super weird, and your clients probably won’t even notice since the WordPress.org theme update system goes by the slug, not the name.

Use a weirdly high version number

If your proprietary theme was versioned at something wild like 99.1.52, you would probably never have to worry about a higher-versioned-same-slugged theme causing an unwanted update notice.

Cut off the source

Plop the following function (remembering to update prefix_ with your own), and never worry about unwanted theme updates again:

function prefix_disable_wporg_request( $r, $url ) {
	if ( 0 !== strpos( $url, 'https://api.wordpress.org/themes/update-check/1.1/' ) ) {
		return $r;
	}

	$themes = json_decode( $r['body']['themes'] );

	$parent = get_option( 'template' );
	$child = get_option( 'stylesheet' );
	unset( $themes->themes->$parent );
	unset( $themes->themes->$child );

	$r['body']['themes'] = json_encode( $themes );

	return $r;
}
add_filter( 'http_request_args', 'prefix_disable_wporg_request', 5, 2 );

Don’t yell at WordPress.org about this

The answer is to be aware of the issue and defend against it, using one or more of the techniques outlined above.

Previous Post
Arguing that theme updates should not induce panic attacks
Next Post
Running your own WordPress theme and plugin update server