Viewing 6 replies - 1 through 6 (of 6 total)
  • But removing plugin data on delete would be very unreliable. It would only work if you used the built in functions to delete the plugin, rather than ftp. I never use those built in update functions, ever. A better option would be a ‘do you want to delete data’ dialog when you deactivate the plugin. On the WordPress core end, a ‘suspend’ hook would be nice.

    Thread Starter Ulfsby Webdesign

    (@sulfsby)

    I strongly disagree. All management of a WordPress site should be done by the WordPress dashboard. That is why it is there. Using ftp is using the backdoor. If you use the backdoor, WordPress has no controll of what you are doing. Updating plugins by the built in functions is also very much faster than first downloading it from wordpress.org and than upload to the blog. But your proposed dialog is better than just deleting.

    Thread Starter Ulfsby Webdesign

    (@sulfsby)

    Better than a dialog when deactivating the plugin, is to have a button where you explicitly delete the plugins tabels, or else it will not be possible to mass-update the plugins.

    All management of a WordPress site should be done by the WordPress dashboard.

    I wish some of that dashboard wasn’t there. I think its dangerous. If something goes wrong you can’t get in to fix it via the only way you know, then people show up here crying “Help OMG!!!!!! I broke my site and now I can’t get in to fix it.” Too much automation means too little understanding.

    Some of those back end management functions are only available on some server/server configurations anyway.

    Updating plugins by the built in functions is also very much faster than first downloading it from wordpress.org and than upload to the blog.

    Nothing goes to my production sites without first going to my development server first for testing and debugging, mostly to make sure it plays nice with everything else. It is not faster to update directly.

    Updating directly also means that you are essentially blindly (since you don’t get to see the code) testing new/modified code on a production site– not a good idea. That is another reason I don’t consider it safe. I’ve got too much on the line to take the chance.

    Anyway, that’s my take, for what its worth. 🙂

    There might be a way to add a checkbox on the plugin’s listing on the plugin page (plugins.php). I think I’ve seen those before but I’m not sure. Its a pretty vague memory.

    Plugin Author Steve

    (@steveatty)

    Stig – that is why I recommend manually updating the plugin- and I’d hope people would make sure the upgrade works OK on a dev site before blindly accepting code they’ve not even unpacked and run once on a live system

    Anyway when V2 comes along all of those problems vanish.

    Thread Starter Ulfsby Webdesign

    (@sulfsby)

    Thank you Steve, that is good. I realy like your plugin. I have tested it on a testsite, but when I deactivated it, all my settings were gone when I activated it again. Now I use it on a production site beeing aware of the issue.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘[Plugin: Wordbooker] Removing settings and tables when deactivating is no good idea’ is closed to new replies.