[wp-trac] [WordPress Trac] #14915: Fix activation hook inconsistency

[WordPress Trac]

#14915: Fix activation hook inconsistency
--------------------------+-------------------------------------------------
 Reporter:  nacin         |       Owner:             
     Type:  defect (bug)  |      Status:  new        
 Priority:  normal        |   Milestone:  3.1        
Component:  Plugins       |     Version:  2.9        
 Severity:  normal        |    Keywords:  needs-patch
--------------------------+-------------------------------------------------

Comment(by joelhardi):

 > You'd only be testing the plugins which were just upgraded.

 Right, I'm worried about the case where a user comes along to upgrade
 their long-dormant blog and they have 10 plugins or more to upgrade, that
 the upgrade process might become more fragile or take a long time and be
 prone to user interruption. Playing devil's advocate -- i.e., do we need
 to think about the UI when adding (silent) reactivation and error checking
 to the bulk upgrade process? Just a simple code branch (i.e. do not try to
 auto-reactivate if n > 10) at minimum might be a good idea, even if it's
 at n > 100 which is extremely unlikely to be encountered.

 > The 100ms/plugin (which is a guess) delay for checking them would be
 insanely faster than say, the user upgrading n+1 plugins.

 I don't disagree with the enhancement (add reactivation to bulk upgrade)
 or think users should have to single-upgrade.

 Just thinking through the reactivation process and suggesting possible
 pitfalls in the case where there's a en error with one of the plugins
 reactivated and the code has to step back and isolate the plugin causing
 the error. A binary search algorithm in this case would be much better
 than a linear search.

 100 ms is pretty optimistic, I just took a look at an 8-core 2.5Ghz Xeon
 box and just the init ({{{require_once('wp-admin.php');}}}) on the admin
 side is mean 195ms. So, for instance, suppose you are upgrading 10 plugins
 and there is one that causes a fatal error. If you use a binary search you
 will have to do 7-9 page loads to isolate the bad plugin. If each page
 load is half a second, that's ~4 seconds total.

 Is that reasonable? Well ... I'm not the boss, but 4 seconds seems
 reasonable to me.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14915#comment:19>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software