[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