Plugin Deactivation Issues Solved With Actions and Filters
If you like this post, please subscribe to our RSS feed to read our new posts every day.
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.
Visitors who read this post, also read:
Related posts from the past
- Reduce the Size of Your WordPress Plugin Footprint
- How to: Offsets and Paging
- Gravatars and WordPress 2.5
- Removing Width/Height from the Image Uploader
- Error Management for WordPress Plugins
- Tackle Plugin Compatibility Issues While Using Popular Libraries
- Dissecting a Plugin: Better Comments Manager
- How to Only Retrieve Posts With Custom Fields
- Safest Way to Include Plugin Code in Themes
- How To: Avoid Duplicate Posts













Comments RSS
in WP 2.5.x there is a function name is_plugin_active ( and is_widget_active() for sidebar widgets). I think this might be worth mentioning here.
if (is_plugin_active('pluginbasedir/pluginfilename.php'))
add_action('my_related_posts', 'related_posts', 1, 1);
else
// do something else
[Reply]
chaoskaizer (60 comments.) — 06/7/2008 @ 9:30 amAs usual Ronald, excellent content!
Your 1,2,3,4,5,6 presentation may confuse people a little about the difference between actions and filters though (semantics really, as they share the same code and execution). 6 should really be with the other action information and is likely the scenario that it is worth providing some real examples for.
Your filter example is completely forced. Filters are always in the context of manipulating existing data, whether provided by core or a plugin, and very unlikely to relate to plugin deactivation issues.
As I started awesome content to put other there for critique
[Reply]
Lloyd Budd (11 comments.) — 06/7/2008 @ 10:00 am@chaos,
Thanks for that. Unfortunately I’m getting errors when I edit the post.
@Lloyd,
I see what you mean, but I’m not trying to give a tutorial on actions/filters with this article. Perhaps I should write one here?
The various methods should hopefully show plugin authors the various possibilities so that plugin deactivation issues can be a thing of the past.
[Reply]
Ronald Huereca (66 comments.) — 06/7/2008 @ 2:02 pmI am not sure if WordPress has a facility to deal with this following use case for plug-in.
I want to disable and remove the plug-in completely so that none of its options are left in the database.
I think there should be a way for plug-in developers to do such things.
So far I have a plug-in that erases all the info that it puts into the database and all user options but only problem is it comes with payload that if the user want to re-activate the plug-in they must also do all the config all over again. I think that is a reasonable approach to take.
Ideally there should be intermediate step in Plug-in Deactivation process, where by plug-in developer like myself can intercept and alert the user to if they want to make a back up of their options. before de-activating the plug-in.
What do you think?
[Reply]
Azizur Rahman (3 comments.) — 06/7/2008 @ 2:21 pm@Azizur,
That issue has been discussed here before: Uninstall, is there such a thing?
Not sure if there is a core uninstall hook planned.
[Reply]
Ronald Huereca (66 comments.) — 06/7/2008 @ 2:45 pm@Ronald, I don’t know how I have missed that post.
[Reply]
Azizur Rahman (3 comments.) — 06/7/2008 @ 3:23 pmTerrific article. It’s not clear how I would make a choice between some of these, however, for example methods 2 and 3. Could you add links to the appropriate related material in the codex or on your own blog?
Thanks,
David
[Reply]
David Potter (9 comments.) — 06/9/2008 @ 12:11 am[...] Weblog Tools Collection » Blog Archive » Plugin Deactivation Issues Solved With Actions … — [...]
The Haunted Palace » Archive » ma.gnolia/carla [June 9th through June 12th] — 06/12/2008 @ 8:04 pm