[wp-hackers] Theme options in db: automatic deletion?

[Chip Bennett]

As a starting point, wouldn't it make sense for Plugins and Themes to
behave consistently?

That is: if/when Theme activation/deactivation hooks are implemented, they
should *start* by doing what Plugins do. If a Plugin deletes DB entries
on-delete (which is logical, IMHO; *deleting* an extension is not the same
thing, and shouldn't be used in the same context as or considered to be
interchangeable with, *deactivating* an extension), then so should a
Theme. Then, if the workflow and UI need to be improved, they can be
improved for both, simultaneously.

(Again IMHO) Introducing inconsistent UX for deleting Themes versus
deleting Plugins would be detrimental to users.

Chip

On Tue, Nov 1, 2011 at 11:54 AM, Mike Schinkel
<mikeschinkel at newclarity.net>wrote:

> On Nov 1, 2011, at 12:42 PM, Eric Mann wrote:
> > Deletion versus deactivation.
> >
> > Deactivation shouldn't remove any options, settings, files, DB
> > customizations, etc.  I would also argue that *deletion* shouldn't,
> either.
> > But if you absolutely have to place this kind of functionality in your
> > theme/plugin, hooking in to the "Delete" click in the WordPress UI would
> be
> > the safest.  Still inadvisable, but safest ...
>
> The BEST approach IMO would be upon plugin/theme deletion to serialize
> everything to a zipped archive file (or to a single option in the
> wp_options table) and then delete everything else persisted by the
> plugin/theme.
>
> Upon activation the plugin/theme could then look to see if there are any
> archived settings and, if so, import them if the admin approves.
>
> -Mike
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>