Category: Plugins

Categories
Open Source Plugins WordPress

Releasing a WordPress Plugin – What’s Stopping You?

At OM4 we’re typically  creating a WordPress plugin in order to solve a requirement for one (or more) of our paying clients.

Some of the time, the problem we’re solving is quite specialised and unique, so there would be little benefit in releasing it to the masses.

However in a lot of other cases, the problem we’re solving for our client is a generic problem that applies to a lot of other people out there.

In those more generic cases, we have tried to make an effort to give away those plugins to the public by releasing them into the official WordPress plugins repository.

So far we’ve publicly released 4 plugins into the repository, and today we reached a milestone: our WordPress plugins have now been downloaded more than 100,000 times!

The main reason we released these plugins was because we wanted to try and give back to the WordPress community. After all, we had free access to WordPress and 25,000+ plugins due to the generosity of others, so why not return the favour?!

Speaking of why not, there are a few common arguments against publicly releasing a plugin, which I’ll try and address below.

1. But won’t I get too many support requests if I release my plugin?

Well, it depends.

In our case, we’ve had 100,000+ plugin downloads, but we’ve had a mere 18 support requests, which equates to:

  • 1 support request for every 5555 downloads
  • 1 support request every 11 weeks

Personally I think those numbers are very low, and I attribute that fact to the following 3 reasons:

a) A simple plugin designed to do one thing only

In our case, the plugins  we chose to publish are all very simple plugins, which are designed to done thing only.

The biggest plugin we’ve released is a mere 600 lines of code, however I’ve come across plugins in the repository that have 50,0000+ lines of code.

Now I have no doubt that those large plugins can be useful to people, but I personally wouldn’t want to release a plugin that large without charging for support (because there would be a lot of support requests)!

b) Decisions not options

The plugins we’ve published all have very few user options (which follows WordPress’ philosophy of Decisions not Options).

This helps keep your plugin small, simple, and easy to use.

Speaking of WordPress’ philosophy, in my opinion the main points that are relevant to plugins are:

  • Design for the Majority
  • Decisions not Options
  • Clean, Lean, and Mean
  • Striving for Simplicity
  • Out of the Box

I strongly recommend you read the philsophy and try and apply it to your plugins.

c) Clear & simple documentation

We have also put quite a lot of effort into documenting each plugin (in the plugin’s readme.txt file), so that the users can get up and running without having to ask questions.

Remember that you wrote the plugin, so you understand how to use it. However your users don’t have that knowledge, so they’ll need clear and simple instructions.

2. But isn’t releasing a plugin extra work that I won’t get paid for?

Technically, it is a little more work to publicly release a plugin, but if you’ve gone to the effort of writing the plugin for a client, why not spend another hour packaging it up and releasing it on WordPress.org?

Speaking of extra work: the major benefit to releasing your plugin is that other plugin developers might do some work for you!

I’ve had several developers who have been nice enough to send me bug reports (and pull requests) for our plugins, which has saved us some time and thus benefited our own clients.

If you’d like to encourage this community development, I strongly recommend putting your plugin’s code on GitHub (in addition to the WordPress plugin repository).

3. But I don’t know how!

If you are interested in releasing your plugin, I encourage you to have a look at the WordPress Plugin Developer Centre.

Conclusion

Now that I’ve been working with WordPress for ~6 years,  I can’t even guess how many lines of code I’ve written!

But when I pause for a second and compare that  to the amount of code that I have released publicly, I realise that there is still a lot of room for improvement. Is it too late to be making more new year’s resolutions?!?

I’m interested in hearing from you.

Is there anything in particular holding you back from releasing your WordPress plugin code to the public?

I’d love to hear why, and help encourage you to take the plunge and release it.

Categories
Development PHP Plugins Themes WordPress

New in WordPress 3.6: the attachment_url_to_postid() Function

If you’re writing a WordPress plugin, you may have a scenario where you have an attachment (file) URL, and you’d like to obtain the associated post (attachment) ID.

Luckily, this is very easy to do in WordPress 3.6 because of the new attachment_url_to_postid() function.

The function’s syntax is simple – you pass it a string (the file URL), and it returns an integer (the associated post id), or zero on failure.

Here’s a simple example:

As mentioned above, this function is available in WordPress 3.6 – it will cause a fatal error if you try to use it in any earlier versions such as WordPress 3.5.x.

Thanks to Zack Tollman for the heads up about this handy new function.

Categories
Development PHP Plugins Themes WordPress

Better Mobile Detection with WordPress’ wp_is_mobile() Function

Although WordPress themes typically use Responsive Web Design to tailor website for mobile devices, there is sometimes a need to use PHP (backend code) to detect whether the visitor’s web browser is running on a mobile device.

For example, there may be scenarios where you may want to output certain HTML markup (such as a mobile navigation menu) on mobile devices.

Alternatively, you may only want to output a slider containing large images on desktop and not mobile devices. Doing this via PHP (instead of CSS) means that the visitor’s mobile browser won’t have to download all of the slider images even though the slider is never displayed.

WordPress’ wp_is_mobile() function to the rescue!

wp_is_mobile() is a litte-known function built into WordPress that detects whether the visitor is using a mobile devices such as iPhone, iPad, Android, Silk, Kindle, BlackBerry, Opera Mini, and Opera Mobi.

The function was introduced in WordPress 3.4, and it can be used in a WordPress plugin or theme.

It’s a simple function that accepts no parameters, and returns a simple boolean (true/false) value.

Here’s a simple example:

Interestingly, WordPress core currently uses this function in a few different places:

  • To completely disable the Visual Editor for Opera Mini.
  • To enable jQuery UI Touch Punch in the WordPress dashboard for mobile devices.
  • To detect whether the current device can upload files.
  • To disable the “shake” effect on the WordPress login page when an incorrect username or password is entered using a mobile device.

Are you currently using the wp_is_mobile() function in your plugin or theme? If so, I’d love to hear what your use-case is.

Categories
Plugins WordPress

Embed a Github Gist in WordPress Posts/Pages

Looking for a simple way to embed a Github Gist in your WordPress website?

I spent some time reviewing the available plugins in the WordPress plugin repository, so I thought I’d share my findings.

Continue reading “Embed a Github Gist in WordPress Posts/Pages”
Categories
Plugins WordPress

Should I escape translated strings in a WordPress plugin or theme?

When writing a WordPress plugin recently, I wasn’t sure whether a translatable text/string is considered safe, or if it needs to escaped before being output.

Here’s a simple example:

The Problem

At first glance, that code looks like it should be safe, however what would happen if the string was translated to contained an angled bracket (< or >)?

That would result in invalid HTML code. Or even worse, what if the translation file contained a malicious <script> tag?

The Solution

Continue reading “Should I escape translated strings in a WordPress plugin or theme?”