Just like many fellow programmers out there, when I first started publishing my own code for the world to see and use, it wasn’t the greatest. I didn’t fully understand the WordPress API and all the tools it had to offer. I have since learned a lot about how to write WordPress plugins “the right way”—the most efficient, clean, and safe way, that is. WordPress has functions, classes, and hooks that work right out of the box to make plugins easier to code and less risky to use. Here are a few of my favorite tips.

1. Use the $wpdb object for all database queries

If you only read and follow one of these tips, make it this one. Setting up database connections with mysql_connect over and over again is a waste of code. If you’re in anything other than a standalone processing script, $wpdb is ready to go with just one line of code:

global $wpdb;

(If you are using a standalone script for something, just include two files to make $wpdb work: wp-load.php and wp-includes/wp-db.php.)

There are different functions for the $wpdb class to make different kinds of database queries (see the WordPress codex page for details on them all).

On average, I find that using $wpdb saves two to three lines of code for each time I make any sort of database query. For example, this:

$name = mysql_real_escape_string($name);
$result = mysql_query("INSERT INTO $myplugin->categories_table (name) VALUES ('$name')");
if (!$result)
    die("Could not insert into database. ".mysql_error());

turns into this:

$wpdb->insert($myplugin->categories_table, array('name' => $name), array('%s'));

One of the most important reasons to use $wpdb instead of mysql_query is that it automatically protects the database from MySQL injection attacks. More details about that are on the codex page as well.

2. Call jQuery using wp_enqueue_script

One of the most frustrating things I’ve seen responsible for my WordPress plugins not working is that other plugins are calling jQuery the wrong way:

<script src="../../../wp-includes/js/jquery/jquery.js" type="text/javascript"></script>

WordPress has its own way of handling calls to jQuery (and other common Javascript libraries). It’s called wp_enqueue_script. This is how WordPress would have you call jQuery in a plugin:

wp_enqueue_script('jquery');

So if WordPress itself needs to load jQuery, or an additional plugin calls it in this way, then it’s only loaded once, and it’s loaded in no-conflict mode. This means that there won’t be two jQuery scripts of different versions competing for attention. And if you prefer an external reference to jQuery (such as the one from Google Code), there is a method for doing that in a WordPress-friendly way, too (see step 2 on this linked page).

3. Use unique class & function names

If you have a function in your plugin called “load()”, then what happens if another plugin is activated on a user’s blog that uses a function called “load()”? Well, crap explosions happen. Plugins break. Solving this problem is easy: name all your functions something unique to your plugin. My personal method is to come up with a two- or three-letter representation of my plugin (like “sm” for SimpleMap) and use that as a prefix to all my function names. For example:

sm_display_map()

Easy as pie.

4. Prep all text for localization from the get-go

Even if you don’t include any translation files with your plugin, someone out there might want to write one for you (or for themselves). It’s pretty tedious to go back through your existing code and prep the text for translation, so make it a habit right away. First, you have to pick a key for your plugin’s translation files (this is usually just the plugin name or slug). Then you have to surround any text that gets displayed to the user with the following code:

__('This is the text to be translated.', 'PluginKeyHere');

Note: ‘PluginKeyHere’ would be the key you picked. For example, in SimpleMap this is ‘SimpleMap’.

The double underscore at the beginning will return the translated string to PHP. If you want to echo the string, instead of adding echo before the double underscore, you can use this shorthand:

_e('This is the text to be translated.', 'PluginKeyHere');

More details on localizing your plugin can be found in the WordPress codex.

5. Write a good README file

This is something I highly recommend. When I’m searching for a plugin to install, an inadequate or poorly written README file will often make me go back to my search results and keep looking. Writing a good README file shows that you care about the people using your plugin. If you treat it like it’s just a step WordPress forces you to take to submit a plugin to the repository, it’s going to make you look like an ass, and users won’t want to try your plugin at all.

To top it off, Mark Jaquith has recently released a plugin that makes good use of your README files on your own blog. It’s called I Make Plugins, and it automatically populates pages on your blog to promote the plugins you’ve created. You can see it in action here on Aliso the Geek.

Well, that’s all for now. More tips are sure to come in the future! If you have any suggestions, please leave a comment and share them!