Making Your Plugin Pluggable

The WordPress API provides a great solution for hooking in and extending or modifying its functionality. Sometimes, however, you may find that it would be useful to hook into another plugin, rather than WordPress itself, and extend or modify its functionality instead.

Here's an example of making your plugin pluggable: an issue about interaction (or lack of) between WP e-Commerce (http://getshopped.org) and the All in One SEO Pack plugin. All in One SEO Pack, among other things, adds a custom document title, description, keywords, and canonical URL to each page on a WordPress site. People often ask how to have their plugin modify this information before it displays onscreen. Forum plugins and shopping cart plugins particularly have this need, which All in One SEO Pack could easily satisfy if it would just provide a method of accessing its functionality, which it has — read on.

WP e-Commerce (and other plugins with similar functionality) creates its own virtual pages for product listings, and so on, all contained on a single WordPress page. For example, if you define http://mywebstore.com/shop as the WordPress page WP e-Commerce uses, http://mywebsite.com/shop/product-name and all other product pages are dynamically created by the WP e-Commerce plugin, and are outside the reach of other WordPress plugins. So, WordPress, and by extension, the All in One SEO Pack plugin, doesn't know about them. You can see the problem this would create for SEO purposes; WordPress and All in One SEO Pack would think that all these product pages are really the same page as the shop page, with the same titles, canonical URL, and so on. Code could have been written into the plugin to compensate for the needs of the WP e-Commerce, but that would be never ending, as there are infinite possibilities for other plugins that may need to hook into the All in One SEO Pack functions. So, the All in One SEO Pack API was born.

The WP e-Commerce plugin has an important need to hook into the document title, meta description, meta keywords, and canonical URL that the All in One SEO Pack plugin produces. Because WordPress and All in One SEO Pack weren't aware of the generated product pages, they all had the same canonical URL, which is detrimental for SEO purposes. The fix was simple. In the All in One SEO Pack plugin, after the canonical URL is generated, and immediately before printing it to the screen, the apply_filters function is used on the variable. This allows WP e-Commerce to use add_filter to hook in and filter the canonical URL, returning the appropriate URL for that page. That is, in the All in One SEO Pack plugin, they added the following:

function prepare_canonical_url(){
     $canonical_url = my_determine_canonical_url_function();
     $new_canonical_url = apply_filters( 'aioseop_canonical_url',$canonical_url);

     return $new_canonical_url;
}

This returns the value of the canonical URL and lets another plugin filter it, if desired, prior to returning the final value.

The part you can now add in the primary WP e-Commerce plugin file (at the end of the file before the closing ?>) is just as simple, and works the same way add_filter does for hooking into the WordPress API.

add_filter('aioseop_canonical_url','wpec_change_canonical_url'),

function wpec_change_canonical_url($old_url){
     $new_url = determine_current_product_page_url($old_url);
     return $new_url;
}

This provides a simple solution to allow other plugins (and themes) to hook into a plugin, without the need to add code specific to any one plugin.