post-page

Plugin Deactivation Issues Solved With Actions and Filters

12
responses
heading
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