id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
14096	More protection against fatal errors from plugins	nacin		"Willing to split this into more tickets if these ideas gain traction.

'''More realistic sandboxing.''' It would be interesting to perhaps kill most of the WP environment while trying to sandbox a plugin on activation, to catch more fatal errors. For example, unset $wp_rewrite, which would prevent add_rewrite_tag() issues (on activation) for plugins incorrectly trying to register rewriting for taxonomies or post types. Of course, most of these plugins are already running on a blog when the auto-upgrade happens. Hence the second item:

'''Check plugins before an auto-upgrade.''' We can do plugin update checks to verify their compatibility (as reported by the author?) with the version they are about to upgrade to. If the plugin is in the repo and is not identified as compatible with that version, then very strongly advise they deactivate it (and consider doing it for them).

'''Check a site after an auto-upgrade.''' Since we only recommend deactivating plugins on auto-upgrade, and I'm not sure we should forcibly do that as part of an auto-upgrade, then let's check the site after an upgrade. Hit wp-load with an HTTP request and look for a header we spit out on the wp_loaded hook. If we don't get a header, then deactivate all plugins and tell the user ""told you so"". We could consider trying to reactivate plugins until one fails as well (also a valid option for the previous suggestion)."	feature request	new	normal	Future Release	Plugins		major		dev-feedback	scribu@…