Roshan Sah

What Makes A Plugin Extensible?

In a nutshell, an extensible plugin means that it adheres to the "O" part of the SOLID principles of object-oriented programming — namely, the open/closed principle.

If you're unfamiliar with the open/closed principle, it basically means that other people shouldn't have to edit your code in order to modify something.

Applying this principle to a WordPress plugin, it would mean that a plugin is extensible if it has provisions in it that enable other people to modify its behavior. It's just like how WordPress allows people to "hook" into different areas of WordPress, but at the level of the plugin.

A Typical Example Of A Plugin

Let's see how we can create an extensible plugin, starting with a sample plugin that isn't.

Suppose we have a plugin that generates a sidebar widget that displays the titles of the three latest posts. At the heart of the plugin is a function that simply wraps the titles of those three posts in list tags:

function get_some_post_titles() {

  $args = array(

      'posts_per_page' => 3,

  );

  $posts = get_posts( $args );
  $output = '';

  foreach ( $posts as $post ) {

      $output .= '' . $post->post_title . '';

  }

  $output .= '';
  return $output;

}

While this code works and gets the job done, it isn't quite extensible.

Why? Because the function is set in its own ways, there's no way to change its behavior without modifying the code directly.

What if a user wanted to display more than three posts, or perhaps include links with the posts' titles? There's no way to do that with the code above. The user is stuck with how the plugin works and can nothing to change it.

Including A Hundred Settings Isn't The Answer

There are a number of ways to enhance the plugin above to allow users to customize it.

One such way would be to add a lot of options in the settings, but even that might not satisfy all of the possibilities users would want from the plugin.

What if the user wanted to do any of the following (scenarios we'll revisit later):

• display WooCommerce products or posts from a particular category;
• display the items in a carousel provided by another plugin, instead of as a simple list;
• perform a custom database query, and then use those query's posts in the list.

If we added a hundred settings to our widget, then we would be able to cover the use cases above. But what if one of these scenarios changes, and now the user wants to display only WooCommerce products that are currently in stock? The widget would need even more settings to accommodate this. Pretty soon, we'd have a gazillion settings.

Also, a plugin with a huge list of settings isn't exactly user-friendly. Steer away from this route if possible.

So, how would we go about solving this problem? We'd make the plugin extensible.

Adding Our Own Hooks To Make It Extensible

By studying the plugin's code above, we see a few operations that the main function performs:

• It gets posts using get_posts.
• It generates a list of post titles.
• It returns the generated list.

If other people were to modify this plugin's behavior, their work would mostly likely involve these three operations. To make our plugin extensible, we would have to add hooks around these to open them up for other developers.

In general, these are good areas to add hooks to a plugin:

• around and within the major processes,
• when building output HTML,
• for altering post or database queries,
• before returning values from a function.

A Typical Example Of An Extensible Plugin

Taking these rules of thumb, we can add the following filters to make our plugin extensible:

• add myplugin_get_posts_args for modifying the arguments of get_posts,
• add myplugin_get_posts for overriding the results of get_posts,
• add myplugin_list_item for customizing the generation of a list entry,
• add myplugin_get_some_post_titles for overriding the returned generated list.

Here's the code again with all of the hooks added in:

function get_some_post_titles() {

  $args = array(

      'posts_per_page' => 3,

  );

  // Let other people modify the arguments.

  $posts = get_posts( apply_filters( 'myplugin_get_posts_args', $args ) );
  // Let other people modify the post array, which will be used for display.

  $posts = apply_filters( 'myplugin_get_posts', $posts, $args );
  $output = '';

  foreach ( $posts as $post ) {
      // Let other people modify the list entry.

      $output .= '' . apply_filters( 'myplugin_list_item', $post->post_title, $post ) . '';

  }

  $output .= '';
  // Let other people modify our output list.

  return apply_filters( 'myplugin_get_some_post_titles', $output, $args );

}

You can also get the code above in the GitHub archive.

I'm adding a lot of hooks here, which might seem impractical because the sample code is quite simple and small, but it illustrates my point: By adding just four hooks, other developers can now customize the plugin's behavior in all sorts of ways.

Namespacing And Context For Hooks

Before proceeding, note two important things about the hooks we've implemented:

• We're namespacing the hooks with myplugin_.
  This ensures that the hook's name doesn't conflict with some other plugin's hook. This is just good practice, because if another hook with the same name is called, it could lead to unwanted effects.
• We're also passing a reference to $args in all of the hooks for context.
  I do this so that if others use this filter to change something in the flow of the code, they can use that $args parameter as a reference to get an idea of why the hook was called, so that they can perform their adjustments accordingly.

The Effects Of Our Hooks

Remember the unique scenarios I talked about earlier? Let's revisit those and see how our hooks have made them possible:

• If the user wants to display WooCommerce products or posts from a particular category, then either they can use the filter myplugin_get_posts_args to add their own arguments for when the plugin queries posts, or they can use myplugin_get_posts to completely override the posts with their own list.
• If the user wants to display the items in a carousel provided by another plugin, instead of as a simple list, then they can override the entire output of the function with myplugin_get_some_post_titles, and instead output a carousel from there.
• If the user wants to perform a custom database query and then use that query's posts in the list, then, similar to the first scenario, they can use myplugin_get_posts to use their own database query and change the post array.

Much better!