Month: August 2015

The problem of slug identification in the repository

WordPress Plugin Downloads

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.

Active Installs after one day
I had 50+ active installs after one day in the repository?!

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.

... and the download history
… the download history gives us a more realistic insight.

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.

This is another plugin with the same slug
This is another plugin with the same slug

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.

WordPress Support Ticket

Some weeks ago, I had a small job which led me out of the WordPress cosmos. Basically I had to adjust a running webpage on which a ticket support system was included. I immediately missed a lot of the nice filters and features WordPress comes along and which are usually used by plugin and theme developers. The support ticket system had its own templating system but was lacking basic requirements. So the menu was generated automatically and you had to change either the core code or the language files (which I decided to do) to have the “Home”-Link called “Home”. And this was just one of the disadvantages which bugged me.

I got quite annoyed with the system and continued to talk about the advantages of WordPress, but we had to stick to a solution out of WordPress. Anyway, after I finished my job, I decided to go for my own support ticket system and write the WordPress plugin, I would have dreamt of working on. I am very happy to announce WP Support Ticket is now an official member of the WordPress repository family.

Of course, I started to work on my plugin even before I had a close look into the repository, I guess that’s the developers approach. So, after I was almost done, I started my research on what plugins are already on the market. Of course, there are already some nice plugins out there and compared to them, my support ticket plugin lacks some features. But my central goal was to create a plugin where almost every setting and functionality can be somehow overwritten by add ons. So there are dozens of action and filter hooks, which I describe in the plugins codex and which enables developers to create plugins on top of my support ticket software. And of course, I have already a small roadmap in mind, where to head next and which other features to include. And I already start to keep track of some minor bugs, which I will solve the next days. For example: The plugin is fully translateable and comes already with a German translation. The table overview has status classes. A closed ticket would have the class “close”, but unfortunatly, the plugin translates this right now, so the class won’t be applied. You know, these kind of bugs.

Here are some screenshots from the plugin. Have a look:

Create a new ticket in the backend
Create a new ticket in the backend
Create a new ticket in the frontend
Create a new ticket in the frontend
Ticket settings
Ticket settings
Edit a ticket
Ticket agents can answer tickets in the backend
Tickets overview
Here, you see all the tickets in the backend.
The user settings
The user settings
Create a new form field
You can create textfields and selectboxes, so your users can for example leave the order ID or the product name in question.
The email settings
The email settings

So, anyway: Happy to announce my latest plugin, a lot of work has been done and much more is to come. If you are interested in a flexible support ticket solution for WordPress, you should definitely have a look.