[wp-trac] [WordPress Trac] #22704: Automatic Core Updates
WordPress Trac
noreply at wordpress.org
Tue Oct 15 18:26:24 UTC 2013
#22704: Automatic Core Updates
-----------------------------+-----------------------
Reporter: pento | Owner: pento
Type: task (blessed) | Status: assigned
Priority: normal | Milestone: 3.7
Component: Upgrade/Install | Version: 3.5
Severity: normal | Resolution:
Keywords: has-patch |
-----------------------------+-----------------------
Comment (by dd32):
Replying to [comment:115 kurtpayne]:
> When using the 'auto_upgrade_plugin' filter, plugins are not being re-
activated after upgrade. It looks like they are being explicitly
deactivated:
>
> {{{
> add_filter('upgrader_pre_install', array($this,
'deactivate_plugin_before_upgrade'), 10, 2);
> $this->run(....);
> remove_filter('upgrader_pre_install', array($this,
'deactivate_plugin_before_upgrade'));
> }}}
So the cause here is that we're using singular updates in the automatic
updater, which differ from their bulk upgrader counterparts in one
specific case - Singular plugin updates uses a plugin sandboxing iframe to
only re-activate the plugin if it doesn't fatal, bulk upgrades don't do
this.
The problem is that that sandboxing mode requires the user's browser to
hit an iframe which re-enables the plugin:
http://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-
wp-upgrader-skins.php#L122
Honestly, Since we don't support plugin sandboxing correctly anymore,
deactivating the plugin doesn't make 100% sense at all, and we should use
Maintenance mode instead. If we can patch *just* the automatic updater to
reactivate the plugin that would suffice for now and we can iterate on it
later.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/22704#comment:123>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list