Things I Learned From Publishing My First WordPress Plug-in

Here are a few things I learned from the experience of writing my first plug-in for WordPress and using wordpress.org to host it.

Do Not Impose

WordPress will load all active plug-ins on every page refresh. If your script and/or stylesheet is not
required initially then don’t load it until you actually need it. Why bloat the whole site when you only need a script on a particular page?

When the plug-in is loaded, register all your scripts and stylesheets like so:

wp_register_script('jquery-validate', plug-in_URL . '/js/jquery.validate.min.js', array( 'jquery') , '1.10.0', true);
wp_register_style('bootstrap', plug-in_URL . '/css/bootstrap-forms.min.css', null, '2.3.1');

WordPress will not load the script into your page until you issue the command:

wp_enqueue_script('jquery-validate');
wp_enqueue_style('bootstrap');

So only issue this command in the places where you actually need the script.

The beauty of using this method means that you can enqueue multiple times but WordPress will only add the script once to
your page.

Store Your Version Number Somewhere

This is very useful when you come to upgrade later on. Having the version number stored away makes it much easier to
make decisions on what to do when upgrading. Your user may have skipped a version making the upgrade path slightly
different.

Store the version in an option that you can retrieve later like so:

get_option('plug-in_option');

Output The Version Number

I read about the usefulness of doing this in

Joost de Valk’s Article in Smashing Magazine
.
I have to say that I haven’t yet had any support queries to answer,
but if and when I do I am sure it will be useful to confirm what version my user is on simply by scanning their web page
source.

Do Not Change The Plug-In’s Name When Submitting It To WordPress!

Now this is very stupid and I’m sure most people would not make this mistake. I originally gave my plug-in a very simple
name contact-form. When I submitted it to WordPress using this form I entered ‘Clean and Simple Contact Form By Meg Nicholas’
assuming it was asking for the title. WordPress then renamed the plug in to ‘clean-and-simple-contact-form-by-meg-nicholas’.
This meant that as soon as WordPress approved it I had to issue an immediate update as I had referred to the original
plug-in name in my code (of course).

Remember to Namespace

When WordPress loads your plug-in, all your functions get put in a big bucket along with every other WordPress function.
So if you were to name a function

function Load() {};

there is quite a high chance that, either there is a function in existence already of the same name, OR, there could be in the future.

Namespacing in PHP was introduced with version 5.3. However, the minimum PHP requirements for WordPress is PHP 5.2.4. So unless you are developing
your plug-in for internal use where the version in use will be a known factor, then it is best to leave namespacing out for the time being.

A nice alternative is to use a class and put all your functions inside that class. Then your functions can be as plain as you want.
Of course give your class a name that is unlikely to be in existence already.
I have to say that when I first carried out my research into WordPress plug-in development I expected there to be some kind of namespace
directory, but there
does not appear to be one (am I wrong?).

Include a Readme.txt File

A Readme.txt file is a requirement for submission to wordpress.org and it is the source of the text that appears on the
plug-in’s own page on wordpress.org. I think it is well
worth spending the time to create a good document that explains thoroughly what your plug-in does and to provide some good screen shots
(not just of the settings screen). A well documented plug-in is more attractive to your potential down loaders and can help with reducing the
support load later on.

If you use the markdown syntax then it will look much better for your user. The idea of the markdown syntax is that it can look good both when viewed on
a web-page and when viewed as a text file.

The documentation on the markdown language on WordPress.org is quite scanty.
Wordpress provides a nice verification tool to help you.
In the absence of some decent documentation I found that that the best thing was to download another plug-in that already has a good read me,
and use it as a basis for yours.

Keep It Simple

Your first plug-in should be simple. Luckily I did not need to learn this lesson. My first plug-in was a simple contact form. I decided I had enough
to cope with negotiating my way through the administrative side of plug-in creation.

I may tackle something more meaty next time (smile).

Don’t Be Afraid To Repeat What Others Have Done

I decided that if there were already a-lot of plug-ins out there that do the same sort of thing as mine, then there must be a demand.

It’s worth giving yours a selling edge though. My edge was that it contains Twitter Bootstrap mark-up on the form. Bootstrap is becoming a very
popular framework.

Despite being one of many I feel my contact form plug-in is doing quite well from a download point of view.

Test On a Clean WordPress Install

There may be settings that your current theme is making that will not happen on the default WordPress theme.
So it’s well worth starting a new WordPress website
and checking that your plug-in still performs as expected.

Install A Debugger and Check For Errors

For your development install of WordPress it is recommended that you turn on debugging.
This is a very simple change to your wp-config
and is documented here on the WordPress Codex.

It is also very well worth installing a debugging plug-in.
BlackBox Debug Bar is excellent.

Sanitise All Input

The most common way for a WordPress blog to be hacked is through a plug-in that has security holes. A form
that will except xss is such a one, so don’t let your plug-in be the culprit!

As my first plug-in was based on a form this was a very pertinent issue.

This is how I sanitise the form post data:

$this->Name = filter_var($_POST['cf-Name'], FILTER_SANITIZE_STRING);
$this->Email = filter_var($_POST['cf-Email'], FILTER_SANITIZE_EMAIL);
$this->ConfirmEmail = filter_var($_POST['cfconfirm-email'], FILTER_SANITIZE_EMAIL);
$this->Message = filter_var($_POST['cf-Message'], FILTER_SANITIZE_STRING);

WordPress also recommends that you use a
nonce field in your forms.
This is a special code that is posted with the form so that you can verify where the post came from.

Nonce is very simple to use, simply place this in your html form:

wp_nonce_field('cff_contact','cff_nonce');

And then verify it server side like so:

if (!wp_verify_nonce($_POST['cff_nonce'], 'cff_contact'))
return false;

Use jquery() NOT $

This one was a real gotcha for me. I spent hours trying to work out why my jquery was not firing.
This was all due to the fact that WordPress works in noconflict() mode
in order to prevent compatibility problems occuring with other javascript libraries.

The upshot of this is that this will not work:

$(document).ready(function(){
	$(#somefunction) ...
});

But this will:

jQuery(document).ready(function(){
	jQuery(#somefunction) ...
});

Provide an UnInstall Script

It’s polite to tidy up after your plug-in is removed don’t you think?.

If your plug-in sets any options then remove them during un-installation.
All you need to do is provide an uninstall.php file and WordPress will see it and run it.

This is what my uninstall.php contains:

//if uninstall not called from WordPress exit

if (!defined('WP_UNINSTALL_plug-in')) exit(); 
delete_option('cff_options');
delete_option('cff_version');

As an aside, I do think that WordPress should provide an option to delete data or not.
In some cases you may actually want to uninstall the plug-in but have it remember it’s settings.