10 Mistakes you could avoid in wordpress plugin development ...

Even the best idea can be made useless if the implementation isn’t up to standard. I’ve learnt how to make plugins mainly by opening the code of other people in trying to understand it.

After a few month of development I can see the differences between good and bad code. Like in graphic design, the details in coding are important too. Even if all the plugins I have tested were working fine most of them could have used a rewrite, so here are a few things I think one shouldn’t do when developing a plugin.

Output valid xhtml

Plugins that have non valid code never last long on my sites. Of course you can write whatever you like in the admin but the front end should stay clean.

Refrain from adding a link to the footer without giving the user control over it

We all want recognition for our work but sticking a sneaky link in the footer or somewhere else is a bit intrusive. At least provide the user the option to opt out from the admin.

Don’t always start from the same old plugin because “it’s quicker”

Wrong and wrong again. It is ok to learn by hacking another plugin but when you know what you are doing it is best to start from scratch. Plugins don’t always use the latest/appropriate function and if you always rewrite from the same base you miss opportunities to explore other ways of doing things.

Don’t hesitate to look at many different plugins to see how people do things. Some people do better code than others…

Don’t print out CSS/javascript in the site header

Don’t output stuff randomly at the top of a page. For example you shouldn’t include a javascript file on every pages if it is only needed on the single post page. Conditionals tags are your friends. And please don’t add css in a style tag at the top, it’s very annoying. Having all your CSS in one file makes it easier for people to modify.

Use an array to store custom data / options

When you don’t require to store a vast amount of data it is ok to use the Wordpress option table. To many times I see plugins creating on entry for each option but their is a smarter way to do this: store an array of options.

Bad:

add_option( amy_option_one, option 1);
add_option( amy_option_one, option 1);
add_option( amy_option_one, option 1);
add_option( amy_option_one, option 1);
add_option( amy_option_one, option 1);
add_option( amy_option_one, option 1);

Good:

$my_options = array( amy_option_1=>option 1, amy_option_2=>option 2, amy_option_3=>option 3, amy_option_4=>option 4, amy_option_5=>option 5);

add_option( amy_options, $my_options);

Wordpress takes care of the serializing / unserializing so you just give it your array and forget about it.

Use good names for functions/variables

I estimate at 5 the average number of plugins on a Wordpress blog (this is pure guess) so you need to be sure that yours is not gonna clash with what’s in place already. By using too common names for your functions you increase the risk of function duplication. Choose a good prefix at the beginning and stick with it.

Bad:

function save(){
...
}

Good:

function myplugin_save(){
...
}

Use wp_enqueue_script

Like before, you’re not the only plugin the user will use. And if 4 plugins call jQuery at the top of every page it is 3 times more than needed. Luckily Wordpress provide a function called wp_enqueue_script that will prevent this issue.

function my_init_method() {
    wp_enqueue_script( iscriptaculous);           
}   
 
add_action(init, my_init_method);

Comment the code

Well this one is not just for plugin development of course. Commenting code is the base.

Upload it to Wordpress repository

Wordpress provide a huge repository hosting all the good and not so good plugins out there. You also get an SVN slot for your creation in order to keep them updated. Plus you won’t pay for the bandwidth if your plugin is a big success. It also allow the plugin to be updated automatically from the wordpress admin without you coding anything for it.

Specify privileges to the admin pages you create

This is a big mistake I am guilty of doing in my first development. Not checking the user permission could end up in anyone the is registerd on the blog to be able to use the admin page of the plugin. And you wouldn’t like that with some of the big plugin everyone use.

global $user_level;
get_currentuserinfo();
if ($user_level <  8) die(Nice try, you cheeky monkey!);

 Original Source:
http://www.yoursiteisvalid.com/validnews/10-mistakes-you-could-avoid-in-wordpress-plugin-development-1060.html