Table of Contents
Automatic Updates are great. They are one of the best if not THE best feature WordPress has. I’ve loved it since it was introduced in 2.7 (2.5 for plugins) and it’s something that really makes my life easier.
If I’m not mistaken, WordPress automatic updates for themes and plugins are based on the folder name first and then on the name of the plugin and theme.
Things aren’t perfect in the land of WordPress Updates.
You see, two years ago I released a child theme for Thematic called Commune. It has over 10.000 downloads and a lot of people are using it for their blogs.
A month ago, another theme called Commune was approved on the WordPress.org Theme Repository. Since it had the same name as mine, it issued an automatic update. One of the users of the Commune Child Theme saw the update and clicked it. After all, it had the same name, it came from WordPress, what could there go wrong?
As you probably suspected the update overwritten the Commune Child Theme and activated the WordPress.org theme. You could say the user was quite surprised and unhappy:
Hi Cris – just updated Commune @ http://t.co/Cj6dycV & the format is ruined ): no menus, columns & widgets gone… HELP! (twitter status)
So where’s the fire?
Well, there isn’t one. These things happen and life goes on. I’ve help my child theme user to reinstall my theme, she had to recreate her widget settings and that was all. So if you have my Commune theme installed please don’t update it. It’s the WRONG theme.
Also @nacin already created a bug report on the track to address this issue.
What I’m hopping to achieve with this post is to raise awareness.
With WordPress powering 50 Million websites and the large number of developers and theme designers something like this is bound to happen sooner or later.
And the same things is valid for Plugin Updates as well. Let’s say you create a custom plugin for a client, name it appropriately (no one uses this plugin name on WordPress.org either). Since this is a custom plugin you don’t bother to upload it to the repository.
Months later, someone comes along and creates another plugin with the same name and uploads it to WordPress.org. You’ve guessed it! Your original plugin get’s an automatic update. Client updates the plugin and brakes it’s site.
What can you do as a developer?
Mark Jaquith wrote about this in the past. You can setup your plugin and theme so they are excluded from the plugin updates. It’s a simple piece of code and you can learn more about it by clicking here. I’m also including that in all my child themes and custom plugins just to be on the safe side.
The thing is that I never really thought this could ever be an issue until it happened to me. Also it’s a very obscure thing that not many people know about it. Hopefully if you’re a developer and create custom themes and plugins take this into account.
No-one is to blame here really but can this be done differently?
I think so. Issuing an unique identifier on which to base the automatic update shouldn’t be that hard (or is it?)
I’m writing about this hoping to raise awareness to this issue, not to mention the 3.3 milestone features a refresh to the update system and might even go so far as updating WordPress in the background, without your intervention (these are rumors mind you).
So let me know what you think in the comments. Should Automatic Updates be issued based on an unique identifier and not just the Theme/Plugin name?
Related Articles
15+ Best WordPress Membership Themes in 2024
Looking for the best WordPress membership theme? We collected 20+ free and premium options, all of which make a great option for membership websites.
Continue Reading
Best WordPress Monetization Plugins & Tactics to Grow Your Revenue
You will agree that finding the best WordPress monetization plugins (and tactics) to grow your revenue is challenging. If that describes your situation, you're in the right place, and we have your back as always. Like you, I had big dreams when I started my first WordPress site. Also, like you, I was skeptical about […]
Continue Reading
23+ Most Useful WordPress Plugins: Improve Any Site in 2024
Searching for the most useful WordPress plugins to improve your site in all kinds of helpful ways? Plugins are one of the best parts of WordPress. But with so many different options, it's hard to find the best plugins to help you create a better site. To help you skip the grunt work, we've curated […]
Continue Reading18 thoughts on “WordPress Automatic Updates Based on Folder Name. Is That a Problem?”
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Agreed. Not sure how to register for a Unique Identifier though since there are tons of developers who don’t even have an account on WordPress.org. Perhaps something like adding the WP Auth salts once the theme gets activated.
I got burned by the same theme name issue as well. Seems like there are lots and lots of quirks, but who knows where or how to check for them until they arise?
Newest theme related oddity for me has been the inability to delete a child theme from within the admin, if the parent theme was deleted first.
Hi Kel,
Thanks for your input.
There isn’t really a place to register for a Unique Identifier. I’m only suggesting that could be a solution.
Also didn’t know about the issue deleting the childtheme if the parent theme exists. Interesting.
Hi Christian,
Yep – I meant I wasn’t sure how WP would go about adding the Unique ID – not me. I’m certainly not qualified since I suggested using something like the Auth salt tech 🙂
The child theme issue seems to stem from it’s link to the parent. Once the parent is gone, the child’s css causes WP to think the theme is broken – thus it moves to the bottom of the listed (thumbnailed) themes and then cannot be deleted.
There is no need for every WP developer should have a unique ID.
What if WordPress.org assign an ID to the themes and plugins uploaded their. so whenever there would be an update on wordpress.org, the system would update only those themes and plugins which are assigned a unique ID from wordpress.org
The theme update checker system matches based on the slug and the name of the theme. Both have to be exact matches. If two different themes have the same slug and name, then the one in the directory is going to show up as updates.
This doesn’t seem like a problem to me. If you are going to intentionally not be in the directory, then I think that’s kinda on you to deal with that issue. Either use a unique prefix or your company name or something in your theme names/slugs, or add code to make it check your site for updates for that theme, or add code to disable the update check. WordPress.org isn’t going to enforce uniqueness among theme names, except amongst those actually hosted on WordPress.org.
We may add something to make the update check a bit smarter, such as not matching child themes to parent themes, but that doesn’t solve the underlying issue. What if both were a child theme? In the end, a false match is going to happen if you use generic names like “Commune” and such. If you want your theme to be uniquely recognized everywhere, then it has to have a unique name. This is no different than the problem of plugin function name prefixes and so forth.
Hi Otto,
As I’ve said I’ve taken steps to disable automatic updates in my child themes.
The problem is that it’s such an obscure issue that when it happens it has big/unexpected consequences.
Also it’s not something it comes to mind when building a theme or plugin. That’s why making this a bit harder to happen is what I was hoping.
Hoping that others learn from my mistake and take steps to prevent this.
I know this thread is old, but this does not appear to be true anymore. I had a theme with the directory name “shopper” but with “Theme Name: Square Candy Design: Shopper’s Guide 2013” in style.css. I was still being offered automatic updates for another theme with the slug “shopper” but a completely different title/name.
I have since changed the slug to be more unique, but I just wanted to comment that it seems to only be checking the slug, not for an exact match on both name and slug as suggested here.
I completely agree. Contacting WP.org and updating themes & plugins based solely on the name (and slug) of the theme is just wrong. I understand it was probably the simplest way to add this functionality, but simple implies insecure.
Otto’s take on this has things completely backwards in my opinion. Checking for updates should be an opt-in feature, not opt-out. Hosting a theme on WP.org is discretionary, not default behavior. “If you are going to intentionally not be in the directory…” That’s like saying if you’re going to intentionally not move to Russia, the burden is on you to let Russia know.
In the world of private/custom themes and plugins, there is no reason a developer shouldn’t be able to name a theme “My Theme” or something equally generic and expect it to work, especially in a situation like yours where it worked for years before it was broken. And there is no reason for WordPress to send that info to a third party (WP.org) without explicit permission. Requiring developers to add some very obscure code to prevent unexpected behavior is backwards.
The comparison to namespacing of functions is a red herring. You can control whether you have more than one theme/plugin with the same name. (In most production sites, there is no reason to even have more than one theme in the first place!) You can’t control what third-party plugin developers name their functions (or future WP functions for that matter).
There is also a security concern. If a scammer finds a plugin or theme in the wild that is not hosted on WP.org, all they have to do is duplicate the code (or come relatively close), add their own nefarious code, and submit it to WP.org. Naive users would automatically update and may never notice the difference. For example, two seconds with Ctrl-U informs me that this site runs a theme called “Cozmic Dream”; it is a child of Thematic and the slug is “cozmic.” Another 5 seconds at WP.org reveals that no theme with that name is hosted there. If I uploaded a theme with that identity, your WP install would start nagging you to update to my code.
As for what to do about it, there are many possible solutions. Here’s one idea: WP.org could automatically add a unique identifier to each package they host (a text file with a GUID, say), and WP could limit update checks to packages with an identifier. There would be no burden on the developer, because the identifier would be added when the plugin is uploaded.
I have been finding not only wordpress update failing on me on a regular basis but also larger plugins like All In One SEO. I am not sure why do you have any ideas. At first i thought it was bad net connection or time of day that I am trying to do the updates, but I am really not sure if that is the case. Your guru incite would be greatly appreciated.
[…] 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 […]
[…] אנטואס (Cristian Antohe’s), מפתח וורדפרס, סיפר על מקרה מאוד נדיר. הוא פיתח ערכת עיצוב עבור לקוחותיו […]
I think a unique identifier should be key to automatic updates. Any problem that can be avoided without causing the user possible loss of time and lots of stress is a good idea. I had a recent unrelated problem where I installed a new wordpress blog as an add on domain. It was supposed to assign a new MySQL Database name. Instead it duplicated and overwrote a blog with hundreds of post. To say I was a little upset is an understatement. So please push for the implementation of anything that will prevent a users nightmare.
Think about this. You make a plugin with the same name as of someone’s plugin that was not added to WordPress repository but it’s very popular. Now you add your plugin to WordPress and all users of the plugin will be notified that there’s an update available… you now have lots of downloads for whatever stupid plugin. Not to mention the problems that this can cause to users…
So there be should definitely another identifier that the plugin name.
Dear Cristian, First of all Why you didn’t added your theme to WordPress.org Themes repository? You could have done it years back. So I will blame you 🙂 LOL
Just learned this the hard way. I had a custom theme made, which uses the organisation name as folder name. When content manager updated WordPress and themes (a WordPress newbie) the site suddenly got killed. What had happened? A public theme with the same name was installed over our theme, losing all the content and programming. And yes, theme folder was totally replaced.
I think this is quite dangerous function, since many edit theme files directly in the server.
Allways do backups 🙁
Yep, another victim here 🙁
The weird thing is that we name our themes with a suffix e.g. “Template Name (company name)”. But the slug is the same as the repo version I guess, which is enough to allow wordpress to update the theme with those files. This goes against what Otto has said above about the name and slug needing to be the same?
I’m just sitting here waiting for more and more tweets to come in to our account… eurgh!
Phil
Is there an existing issue for this on https://core.trac.wordpress.org ? I would love to give this a +1 somewhere where it might have some effect.
I agree this is a major problem.
There is this, but I don’t know about a ticket related to something more generic. https://core.trac.wordpress.org/ticket/18097