[wp-hackers] adding delete/autoload to options.php

[Moritz 'Morty' Strübe]

DD32 schrieb:
> On Wed, 12 Sep 2007 23:31:30 +1000, Moritz 'morty' Struebe <morty at gmx.net> wrote:
>   
>> DD32 wrote:
>>     
>>> Now, Deleting, I realise that someone who doesn't know what they're doing could cause havoc with that, but they can do the same if they modify the value to an unexpected value, Many plugins don't clean up the options when removed, and some users i know end up with a couple of thousand options(Those who like to tinker with many plugins..)
>>> Perhaps a button, or check-box?
>>>
>>>
>>>       
>> Deleting is quite a problem as you don't want to lose settings just
>> because you deactivated the plugin. What I did is to use
>> plugin_name_setting and delete all plugin_name_ settings if uninstall is
>> set up. Therefore there should be some thing be done on how plugins are
>> managed. Other systems (e.g. Typo3) make a difference between installing
>> and activating. I think it should be done. There still should be the
>> activation/deactivation hooks in case your messing around and something
>> will break if you get deactivated. But especially having a uninstall
>> hook would save you us plugin-developer a lot of trouble. And being able
>> to output errors on those hooks.
>>     
>
> The unfortunate thing though in WP's plugins context, when plugins are 'uninstalled' the plugins are no longer available to run uninstall hooks, So that rules that out, Which is why i'm suggesting we put a delete button(Or checkbox) on the special /wp-admin/options.php page.
>   
Once you start implementing this it get's complicated, because you have
an option which starts working when to a totally different time: The
user activates uninstall (accidentally) and half a year later he
deactivates the plugin and wonders why all his settings are gone. And
then it's the plugin dev's fault.
IMO a nicer solutions might be to deactivate the registrations of all
hooks but uninstall. This should be quite easy backing the hook-table up
before you include the file, then include it, call all uninstall hooks,
restore the hooks and you're done. Nice and clean.

> I'd like to with my plugins when its de-activated set the plugins options to autoload=no, as the data the plugin needs is a fair ammount of serialised data, i just dont see why those options should continue to be loaded after a deactivation.. I could do a raw SQL, but IMHO we should never have to do a raw query since theres a option api.
>
>   
Sound's reasonalbe to me although I don't think you will be able to
measure a difference in performance whether you load 50 oder 300
settings. But again this get's more complicated once you look at it
closely. To make this simple - otherwise pluindevs won't use it - you
have to have somthing like decativate_options_prefix() do deactivate all
options with a prefix. Thinking of activate_options_prefix you will
notice that that the plugin might not want to have all options
autoloaded. So you would need to add an "default load" to the options table.
Thinking of it, I think it's worth it.


-- 

strübe.de <http://xn--strbe-mva.de>