Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Starting a community wiki to collect up objective best practices for plugin development. This question was inspired by @EAMann's comments on wp-hackers.

The idea is to collaborate on what objective best practices might be so that we can potentially eventually use them in some community collaboration review process.

UPDATE: After seeing the first few responses it becomes clear that we need to have only one idea/suggestion/best-practice per answer and people should review the list to ensure there are no duplicates before posting.

share|improve this question

closed as not constructive by Rarst Aug 18 '12 at 18:44

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

show 3 more comments

37 Answers 37

Use Proper Names

Name hooks and filters (classes, functions and vars), so that people can identify them in even a year, when they don't remember any more, where that piece of cake or code comes from. It doesn't matter if hook/filter names get long. Ex. youruniquename_hook/filter_whatitdoes.

  • If your file contains a class named "dbdbInit", then the file that contains the class should be named "dbdbInit.class.php".
  • If you got inside your dbdbInit-class a function that registers ex. custom_post_types, then call it register_custom_post_types().
  • If you got an array that contains the names for custom_post_types, then call the variable where the array is assigned $custom_post_type_names.
  • If you got a function that handles an array write function array_handler( $array ) { // handle the array}..
  • Just try to name things in a way that you know what the sign does/where it belongs to by it's name.

Another thing: If you have to debug stuff then, in 99% of all cases, you get all your messages for not only your code, but for wordpress too. So try to use the same prefix ex. "dbdb" for your classes, public functions and variables/objects. This way you can find them easily between hundreds of files. (Wordpress loads 64 files before your theme and about 1,550 functions, not talking about hooks and filters.)

share|improve this answer
2  
sticking to the WP standards when naming files and functions is also nice, e.g. "class-db-init.php" codex.wordpress.org/WordPress_Coding_Standards –  gabrielk Jun 21 '11 at 16:29
show 1 more comment

Use WordPress's Coding Standards

http://codex.wordpress.org/WordPress_Coding_Standards

You know how much easier it is to update code you've worked on vs. code someone else has put together? Coding standards make it easier for any developer working on a project to come in and see what's going on.

We know your plugin or theme is your own, and the way you break your lines and add your curly braces is an expression of your individuality. Every indent is a carefully thought-out statement. But with your custom code, you're contributing to WordPress, even if your code isn't in the core application. Coding standards help developers quickly get up-to-speed with your code.

share|improve this answer
add comment

Decouple from WordPress core code

A Plugin should reduce the impact of the WordPress API to the needed minimum so to seperate plugin code from WordPress code. This reduces the impact of changes within the WordPress codebase on the plugin. Additionally this improves the cross-version compatibility of your plugin code.

This does not mean to not use WordPress functions (use them, as Re-Use existing functions suggests), but not to mesh your code with WordPress functions too much but to seperate your plugins business logic from WordPress functionality.

share|improve this answer
3  
Having been a developer on and off for 23 years I've seen many cycles and many suggested best practices come and go. I've seen the pendulum swing wide both ways. I now believe in moderation. In my earlier years I abstracted everything but I learned that abstraction adds complexity that is often worse than the expected benefit. When we see something that causes us trouble as people we immediately seize upon ways to protect ourselves from it in the future but often the medicine is more harmful than the disease. In the USA Sarbanes-Oxley is an example of this. –  MikeSchinkel Aug 26 '10 at 7:01
2  
Just from a short question i asked on wp-hackers: They hate you if you use global variables like $wp_taxonomies, because they are "internal" (i know there are some that should be used like $wp_query or $post)... –  kaiser Feb 16 '11 at 10:12
show 7 more comments

Care about future WordPress & theme versions

Note: After re-reading this advice, I now step back from this practice as checking every function for existence may slow down your site.

Check if functions are deprecated directly in your theme.

This is a "could be like that" example.

if ( ! function_exists( 'wp_some_fn' ) ) 
{
    $theme_data = wp_get_theme();
    $error = new WP_Error( 'wp_some_fn', sprintf( __( 'The function %1$s is deprecated. Please inform the author', TEXTDOMAIN ), "Theme: {$theme_data->Name}: Version {$theme_data->Version}" );

    // abort
    if ( is_wp_error( $error ) )
        return print $error->get_error_message();
} 
// else if no error - the function works and exists
wp_some_fn();

For proper/best practice error handling see this answer: link

You could drop even the $cause into the function. This will help you and your users to keep on track with functions or classes in your theme that might change.

share|improve this answer
add comment

Use wp options for plugin output strings

In order to make the plugin easily used and customizable, all the output strings should be modifiable. The best way to do that is use wp-options to store the output strings and provide backend to change the default values. Plugin shouldn't use displayed strings that cannot be easily changed using the plugin backend.

For example: Sociable - gives you the ability to change the sentence that appears before the icons part "share and enjoy:"

share|improve this answer
show 4 more comments

Use uninstall, activate and deactivate hooks

There are three different hooks for this:

  • Uninstall register_uninstall_hook();
  • Deactivation register_deactivation_hook();
  • Activation register_activation_hook();

A detailed instruction with a working example can be found here..

share|improve this answer
add comment

Use some kind of templating mechanism

Many plugins tend to mingle code and html freely, which makes maintenance and debugging pretty hard. A better way is to put all your html in separate files and use something like this:

function parseTemplate($file, $options) {
    $template = file_get_contents($file);
    preg_match_all("!\{([^{]*)\}!", $template, $matches);

    $replacements = array();
    for ($i = 0; $i < count($matches[1]); $i++) {
        $key = $matches[1][$i];
        if (isset($options[$key])) {
            $val = $matches[0][$i];
            $template = str_replace($val, $options[$key], $template);
        }
    }

    return $template;
}

Then use it like this:

// In mytemplate.html
<h1>{title}</h1>
<h2>{date}</h2>
<p>{text}</p>

// In your functions.php
echo parseTemplate("mytemplate.html", array(
    "title" => $title,
    "date" => $date,
    "text" => $somethingelse
));
share|improve this answer
3  
-1 I think additional level of abstraction can do more harm than good. And where it does make sense (content that should be easily editable via form for example) it is better to use tools already available (like shortcodes) rather than add own templating functionality. –  Rarst Jan 10 '11 at 7:46
2  
Using a template system seems rather silly. There is no valid reason why you can't just use simple php files for views. –  Backie Feb 16 '11 at 10:49
2  
-1 - WordPress' templating system is .PHP. Adding another template system adds complexity and reduces performance, neither of which are a best practice. –  MikeSchinkel Feb 16 '11 at 15:31
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.