post-page

Plugin Deactivation Issues Solved With Actions and Filters

12
responses

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.

heading
heading
12
Responses

 

Comments

  1. chaoskaizer (62 comments.) says:

    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

  2. Lloyd Budd (22 comments.) says:

    As 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 ;-)

  3. Ronald Huereca (66 comments.) says:

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

  4. Azizur Rahman (3 comments.) says:

    I 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?

  5. Ronald Huereca (66 comments.) says:

    @Azizur,

    That issue has been discussed here before: Uninstall, is there such a thing?

    Not sure if there is a core uninstall hook planned.

  6. Azizur Rahman (3 comments.) says:

    @Ronald, I don’t know how I have missed that post.

  7. David Potter (9 comments.) says:

    Terrific 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

  8. anoop says:

    hi, i have a doubt. i want to convert all textarea to editor by using a plugin. moreover whn i add a widget and that widget contains a textarea , it should also change to editor(view page, not wp-admin), is it possible by do_action or add_action?

  9. anoop says:

    hi sir,
    i am using this plugin, (http://geekytalks.com/2008/11/.....eased.html) .This can convert wordpress comment textarea to editor. But its not support for any widget. But we wet the editor as a function as a function. Do u have any idea to get editor in widget(if widget has a textarea, it should convert to editor)by using d_action and add-action function?.



Trackbacks/Pingbacks

  1. [...] Weblog Tools Collection » Blog Archive » Plugin Deactivation Issues Solved With Actions … — [...]

  2. [...] Plugin Deactivation Issues Solved With Actions and Filters [...]

  3. [...] Problemas de Desactivación de Plugins Resueltos con Acciones y Filtros. [...]

Obviously Powered by WordPress. © 2003-2013

page counter
css.php