The problem of slug identification in the repository

As I announced yesterday, I just published a new WordPress plugin in the repository. Its name says everything: “Support Ticket“. So, as probably every plugin developer passionate about his/her plugin and thinking its the coolest/biggest/most comprehensive or whatever plugin out there, I now regularly check the download stats and hope they may rise like never seen before. When I stopped pressing F5 yesterday, I ended up with fifteen downloads. More or less as I did hope for ( I always create two “hope”-scenarios, one being fairly unrealistic and one based on comparison and experience. These two scenarios create a range where everything inside the scope is “as I did hope for” ).

Today will be about  the same. My poor F5 key will suffer again.

So, when I opened my computer I went to the repository to see what – oh my god! – I could have missed during my sleep. Well: Here’s the thing: WordPress says, I have 50+ active installs. This would break my “hope” range on the right side 😀

What did happen? Did one of the big blogs, WP Tavern or who ever, report about my plugin? About MY plugin?

No, nothing like this at all. But what a nice morning waking up with 50+ active installs. A lot of plugin developers would love it. If I now have a look into the newest plugins overview on page 2, I see plugins downloaded 4, 5 or 8 times and my plugin where it doesn’t say the number of downloads no more but 50+ active installs. This is a nice boost.

But speaking of downloads, let’s have a look on them. Ha, so yesterday another awesome fellow had downloaded my plugin and today two more. All together eighteen. This is more what I expected. But how come? 50+ active installs with 18 downloads. No way! Well, it could be possible. A guy downloaded the plugin and installed it on 50 different WordPress blogs. Why not. But – yeah – rather unrealistic.

So, how come? Lets talk a bit about how does WordPress knows how many plugin installations are actually active. Somehow the blogs seem to communicate with the WordPress repository?! No way, really? Of course, they do. This is to tell you about new versions of a plugin or a theme. Every once in a while your WordPress blog sends a list of the installed plugins to compare the versions installed and available. If you are interested in the technical details of this process, I wrote a (German) blog post about it. For non-German-but-PHP-speakers, have a look into the update.php.

The plugins identifier is its slug which is also used as the URL. I like my slug. Its simple and tells you right away what the plugin can do for you: support-ticket/support-ticket.php. Why I am telling you this? Your WordPress blog is sending each plugin slug to the repository to see, if there is a new version. It doesn’t matter if this plugin is hosted in the repository or not. Worth to mention: Every plugin has a slug! And this is, what I think is happening here. A lot of plugins are out there, not hosted in the repository. For example, they have been created for single clients or whatever. There might be quite some plugins out there already with the slug support-ticket/support-ticket.php. Until yesterday, the WordPress blogs where these plugins did run on didn’t receive any response about this plugin, since no plugin with this slug was hosted in the repository. Well, today, they got. Around 50 installations received suddenly a response. It’s not unlikely, they might be asked to update the plugin. And here the slug identification mechanism runs into a problem: If they do so, they are actually overwriting their plugin with a completely other plugin.

To illustrate the problem

I’ve developed a small plugin, which has the same slug, to illustrate the problem.

I saved this plugin in wp-content/plugins/support-ticket/support-ticket.php and if you like, here is the code 😀

As you can see, although it is a completely different plugin, I receive an update notice, which will overwrite this beautiful plugin extending my content with a stupid plugin for a support ticket system. This was not the idea.

To sum it up

I don’t think my plugin is really running on 50+ websites after just one day, but on these websites plugins with the same slug are active. The admins are already (or will sooner or later be) asked to update these plugins which will result in a huge problem for them. I think the plugin identification process for the automatic updates should take this into account and find a way to identify WordPress repository plugins in a more strict way. But the 50+ active installs… Looking good 🙂

If you are interested in my plugin, please have a look here, what it can do for you and help me to reach 100+ active installs by tomorrow XD

Edit

I just had a small chat with Ionut from themeisle.com. He pointed out that this problem also occurs with themes since they run through the same update process. He told me of some problems which studiopress.com is facing with one of their themes. Their WordPress theme Prose collides with the Prose theme of csthemes. For csthemes, this is a disaster resulting in an average rating of 1 star, since every studiopress.com user who updates ends up being quite annoyed.

I think in this case it would be good practice by studiopress to hook into the update checking process and removing the own theme from the list to prevent this collision. This is not only fair for csthemes (I suppose, they didn’t want to “steal” these customers and if so, well too bad for them) but also a good service for the customers of studiopress. What do you think?

If you develop plugins or themes, which are not supposed to end up in the WordPress Repo, I developed this small solution to prevent the update action to show up. Another approach, maybe better, comes from Mark Jaquith.