When Jeff wrote about plugin deactivation breaking your blog, Aaron and I wrote in the comments of a few solutions to prevent plugin issues with themes.

Within this post I will present several techniques plugin and theme authors can take in order to prevent deactivation issues.

Method 1: function_exists

In this example, let’s assume we have a function named related_posts.

When in a theme, we could use this code to call the function if only it exists.

<?php if (function_exists("related_posts")) {  related_posts(); } ?>

The PHP function_exists checks for the existence of the function, and if it does exist, it calls the function.

Method 2: function_exists and Actions

Using the same function name, the theme author could add some code into their functions.php file and use an action and function_exists combination.

if (function_exists('related_posts')) {
	add_action('my_related_posts', 'related_posts');
}

In the above example, we create a new action called my_related_posts.

The end user would use the do_action function where he wants the function used:

<?php do_action('my_related_posts'); ?>

Method 3: Actions

To use pure actions, the plugin author would have to take the initiative and add associated actions to their plugin code.

The code would look very similar to method 2, but would be included in the plugin file.

add_action('my_related_posts', 'related_posts');

The end user would then do the simple do_action call.

<?php do_action('my_related_posts'); ?>

Method 4: function_exists and Filters

Say, for example, there’s a plugin with a template tag that returns some code that you can then echo out in a theme.

Let’s pretend for a minute that the related_posts function could return a string instead of automatically spitting out the code to the screen.

In this case, the template author could add some code into their functions.php file.

if (function_exists('related_posts')) {
	add_filter('my_related_posts', 'related_posts');
}

The end user would then add the following to their theme:

<?php $s =  apply_filters('my_related_posts'); echo $s; ?>

Method 5: Filters

Again, the plugin author would have to take the initiative to only use filters. The plugin author would add the following to their code.

add_filter('my_related_posts', 'related_posts', 1, 2);

The above filter has a priority of one and accepts two arguments.

The end user (aka, theme tweaker), would add very similar code as used in method 4.

<?php $s =  apply_filters('my_related_posts', 4,10); echo $s; ?>

Method 6: Actions and do_action_ref_array

Let’s assume the plugin author has added in the appropriate code to their plugin:

add_action('my_related_posts', 'related_posts', 1, 1);

The above related_posts action just adds an action at priority one, which accepts one argument.

The themer could then add a reference to this action using the do_action_ref_array function.

<?php do_action_ref_array('my_related_posts', array(3,20)); ?>

Assuming the my_related_posts action takes two arguments, we use an array to pass the necessary arguments.

Conclusion

As mentioned in the introduction, it’s the plugin or theme author’s responsibility of adding in the necessary actions and filters so that the end user can deactivate plugins without any major headaches.

The methods I mentioned are not exhaustive, and can be far more advanced if need be. If you have any questions, please leave a comment.

For any code, please use Pastebin and provide a link.

Source : Weblog Tools Collection

If you enjoyed this post, make sure you subscribe to my RSS feed!