Objective Best Practices for Plugin Development? [closed]

Question

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.

Answer 1

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.)

Answer 2

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.

Answer 3

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.

Answer 4

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:"

Answer 5

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.

Answer 6

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..