Developer’s theme “Commune” is automatically upgraded to a different “Commune”

14 Comments

When WordPress checks for updates it runs a check for theme and plugin names against the WordPress.org directory to check for newer versions. So, in the case of themes it checks the slug of the theme as well as the title of the theme. If it finds a match, it prompts the user to update.

That’s exactly what happened in Cristian Antohe’s case, except that his theme was never added to the WordPress.org theme directory, and his users unknowingly upgraded themselves to a different WordPress theme.

Antohe had created a theme called Commune, a child theme of the popular WordPress theme framework Thematic. He chose to never upload it to the WordPress.org theme directory, distributing it via other means. Then, recently, another theme author created and uploaded a different theme to the directory, also called Commune. Since the slugs and the theme titles matched, this queued up the theme for an automatic upgrade for its users.

Antohe's theme is on the left, with the WordPress.org theme by the same name on the right.

This sort of thing has come up once or twice before, though Antohe has explained his situation well with his blog post, and linked to a relevant ticket on Trac (since closed as a duplicate of this one) and a tutorial by Mark Jaquith for removing themes and plugins from the automatic upgrade check.

This problem isn’t a common one, but could be something you’ve run into before. Have you ever had a theme or plugin update itself to something you didn’t intend? Have you used any specific techniques to avoid this problem from occurring with your own work?

14 thoughts on “Developer’s theme “Commune” is automatically upgraded to a different “Commune”

  1. Joost de Valk used this trick once to save people from a malicious plugin. He just requested plugin directory hosting for a plugin with the same name to have it automatically updated for the people who were affected by the malicious one. A very clever killswitch if you ask me. Although it can lead to some confusion!

  2. Also, it’s a child theme & it’s doubtful he could have it added to the repo even if he wanted to. At the time he developed it, child themes weren’t available in the wp.org repo.

    • You mean child themes are accepted in the wp.org rep now? I haven’t heard anything of this 🙂

      Also my solution to this problem (Mark Jaquith’s post) doesn’t work if the person just uploaded my Commune in his/hers themes folder. Chances are there will be an automatic update notice available even after activation until the transient update variable is purged.

      Even so, I think the best solution is to put something like version 100 on my theme and be done with it. This way the users won’t ever get a automatic update (Provided the repository theme doesn’t have an even bigger version number)

      I don’t think wp.org will go with unique ID’s anytime soon but talking about this is a good starting point with the increase of wp themes and plugins.

  3. I have run into this when making custom themes for clients. Haven’t actually overwritten my custom theme, but I have gotten update notices while developing a theme by giving it a generic name.

    Since coming across this issue I always make sure to give the themes I build for clients really unique names and directories, like the full business name. Another trick is to use words that the the dotorg guidelines say not to use, like WordPress and Theme.

    A theme name like “Acme Company Theme” seems pretty safe to me, but if you wanted to be really paranoid you could use a unique prefix like you should with function names.

  4. Sounds like a great way to pick up some users and even promote a new theme. Hey Cristian, what is your next most popular child theme? 🙂

  5. So, as I understand it there is no way I can prevent my theme from being overwritten via a WordPress.org repository theme update, if someone registers a theme with the same name and slug (folder name)?

    Sure, I can change the slug to be something obscure but there is nothing from stopping someone from simply copying that slug and then going ahead with registering a theme with the same name and slug on the WP theme repository.

    Oh, but I can then add code to my theme to disable theme update checks? Not really. If a user has temporarily deactivated the theme, the code wouldn’t run (only if it is active).

    Adding this code to a Plugin won’t work either as I can’t guarantee all my theme users would install the Plugin. I’m certainly not going to enforce usage of such a Plugin before the theme functions properly, that would just be crazy.

    Maybe I am missing something obvious here?

    Solution? Possible scenario would be for a theme to define a constant in functions.php to ‘opt-out’ of the WP.org automatic updates, whilst not turning off updates altogether (i.e. if I wanted to serve theme updates from my own site)?

  6. it’s a minor “bug” if you can call it that… it’s like if you’re a brand and you don’t buy your own domain name or twitter profile… kinda stupid if you ask me.

    • Yeah but you shouldn’t have to add a theme to WP.org inorder to prevent people from overriding your theme =). It will also sow confusion. Then you will have to call your other themes by some add on like Pro version so ppl don’t confuse the too.

Comments are closed.