BuddyPress Desktop Notification 0.7 Release

Today, I am happy to announce the 0.7 release of my WordPress plugin “BuddyPress Desktop Notification“. If you do not know my plugin yet, I covered it in a small blog post here.

Today I’ve (finally) read a small complain in the support forum of my plugin:

Notification received excellent but repeating again and again

Basically, when a message is pushed through the notification API the same message won’t be displayed again, unless – and this is more or less the typical use case 😀 – you click-through the page. You read a message, you go back to the homepage, you edit your profile. In this case you will get informed again and again about lets say an unread message. This can become quite annoying. I was wondering a bit if I should solve this problem server or client-side, but I think it’s better to solve this issue on the client side.

One solution I was thinking about was to save somewhere in the database, which messages have been already sent to avoid sending them again. I didn’t like this solution since the database would get quite a lot of useless information after a while. Imagine a huge community and for every single activity we would need to save a lot of data, which person this message already got via the notification system.

So I decided to go with a client side solution. Here, we go with Javascript. In version 0.6 we had already an array, where the ID of the message is saved to avoid popping up again and again – on the same page. The question was: How do we save this array, when the user jumps to another page: The solution, sessionStorage. I do like this solution, since its small, quick and does not need any database storage. Some might say, the disadvantage of this solution is, the array is only saved for one browser session. But on the other side, this is quite nice, you might have missed a notification or whatever. Nevermind, you will be reminded in your next session.

What do you think?

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


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.

wp_remote_get() vs. wp_safe_remote_get()

Due to a small Twitter discussion, which started after a tweet of Pippin I realized again, the WordPress HTTP API has “safe” functions. Some days or weeks ago I’ve heard of them already, but I didn’t check on them. The topic is the following: The functions wp_remote_post(), wp_remote_get() and wp_remote_head() do have siblings, which are not documented in the Codex but only in the reference:

After the WordPress community discusses largely the top security, I was quite alarmed. What are these “safe”-functions and what do they do? What is the difference between wp_remote_post() and wp_safe_remote_post()?

How the HTTP API works

Before we start, let’s be clear, what the HTTP API actually does. In wp-includes/http.php several functions are located, with which you can perform HTTP requests. All these functions basically interact with the WP_Http() class, located in wp-includes/class-http.php.

So it is relatively easy to perform a POST request with the function wp_remote_post() and to work with the received data afterwards. Tom McFarlin has published a tutorial how to work with this function on Tuts+.

What is the difference between wp_remote_post() and wp_safe_remote_post()?

If you read the source code, you will find only one difference: wp_safe_remote_post() – and the same applies to all safe_remote functions – extends the argument array with the boolean 'reject_unsafe_urls' set to true:

As you can see, these arguments are passed to the WP_Http() class. So what does 'reject_unsafe_urls' accomplish there? Once this boolean is true, the URL gets validated by the function wp_http_validate_url().

What does wp_http_validate_url()?

Since WordPress 3.5.2 wp_http_validate_url() can be found in the core. If you read the description in the source, it says.

[The function] validate[s] a URL for safe use in the HTTP API.

How does the function perform this task? As a first step, it checks (by using wp_kses_bad_protocol()), if the URL has a valid protocol. Valid protocols are only HTTP and HTTPS. If 'reject_unsafe_urls' is not true SSL is also perceived as a valid protocol (s. wp-includes/class-http.php L186). If the protocol is not valid the function will return false.

Also a URL is considered to be unsafe, if it contains a username or a password, by which a user tries to authenticate himself. The following URL would be rejected: http://benutzername:passwort@example.com

If the host of the URL contains one of the following symbols, the URL will be rejected: :#?[]

URLs which do resolve to another port than 80, 443 or 8080 – so to speak the usual HTTP posts – will be rejected.

And this is for safety reasons?

To understand the history of the safe_remote functions it helps to study the ticket 24646. In WordPress Version 3.5.2 the core developers focused on securing the HTTP API against Server Side Request Forgeries. Lets just assume, the HTTP API would not check the protocols before firing the request and the requested URL would be dict://localhost:11211/stat. This would send the string “stat” to the locale Memcached, which usually listens to the port 11211. Since the request was locally, no firewall would prevent the server to respond to this request. To be short here: Danger! In 3.5.2 the developers closed this issue, but they overshoot a little bit. The result was, WordPress was not able to access the locale installation with the HTTP API. If you wanted to fetch your own feed using wp_remote_get() the script blocked the resource.

So they had to step back a little bit. Well, the mentioned attack above is not possible, even using wp_remote_get(). But they introduced the safe remote functions. As long as you can be sure the URL can not be used for an attack on the own system, you still can rely on wp_remote_get(), wp_remote_post() and wp_remote_head(). This is useful, if you want to perform HTTP requests, which target your own host.

But if you can not be sure about the URL, you should use wp_safe_remote_get(),wp_safe_remote_post() and wp_safe_remote_head() to raise the level of security. From now on the request is limited to the conditions mentioned above.


If you are not sure about the URL which will be passed through wp_remote_get() use wp_safe_remote_post(). It is simply the safe way to do it.

Of what use is wp_is_mobile() in times of responsive web design?

Today, I want to discuss a function in WordPress which some might believe is outdated: wp_is_mobile() (to be found in wp-includes/vars.php). This function detects whether a mobile device is used or not by using the user agent of the browser. What? In times of responsive web design? Five years after Ethan Marcottes legendary article about responsive web design?

Usage in the WordPress Core

And still, aren’t there uses where we need to know on the PHP level if a user visits the site is using a mobile device? Let’s have a look into the WordPress Core first and see, how the function is used there.

The admin bar

When WordPress renders the admin bar, it checks by using wp_is_mobile() if a mobile device is used. In this case, the class .mobile will be attached to the bar (see wp-includes/class-wp-admin-bar.php), although, if I am not mistaken, there are no additional styles attached to this class. Also the body-Tag in the admin gets extended by the .mobile class, which changes the behavior of the menu for example.

The editor

The WordPress editor in mobile view
The WordPress editor in mobile view

Most people will write their blog posts usually in the WYSIWYG mode. At least, they have the possibility. But not, if they use mobile devices. In this case the function user_can_richedit() (wp-includes/general-template.php) will return false and what remains is the text mode. The “Visual”-Tab, which you usually find on the top right disappears as well as the full screen button.

More uses

Furthermore, you will find this function is used by _device_can_upload(). But here it plays a minor role. WordPress uses this boolean also to pass it to Javascript, for example in the Customizer.

How works wp_is_mobile()?

The basic is very simple. It checks whether the user agent of the browser contains one of the following text strings: “Mobile”, “Android”, “Silk/”, “Kindle”, “BlackBerry”, “Opera Mini” or “Opera Mobi”. In this case, the function will return true otherwiese false. With these seven strings all major mobile browsers are detected, which lets this function work pretty accurate. Of course it can always happen, a user changes his user agent individually and is not detected correctly. But, these cases aside, wp_is_mobile() works quite well in detecting mobile devices.

More interesting use cases

Since the last mobile update by Google the topic is back again. Mobile devices take more time to render pages and in most cases the internet connection is slower than for desktop devices. All this is bad for the user experience. If you develop your site mainly for desktop, using heavy sliders and much more, for mobile users this results in a catastrophe. Not only many sliders are not as mobile as one wishes them to be, especially the loading times are horrible. This results in high bounce rates. So, why don’t you stop the output of sliders and other heavy features on mobile devices by using wp_is_mobile()?

Another nice feature, you could easily realize with wp_is_mobile()? You could add an additional feature for mobile devices. In many cases the top of the page has a bar with the contact details. Why not checking if the device is mobile and add a SMS button to this bar?


Even the WordPress Core is still using a function which looks a bit outdated right now. And I tried to present two small examples, where I think checking the device on the PHP level would be more efficient than using CSS. If you have other use cases for this function or you have another opinion about the function, I am always happy about comments. 🙂