[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):

 Thanks everybody, I understand the issues better now. FYI I came across a
 minor issue but put it in a new ticket #14963 as it's basically unrelated.

 With respect to the single-plugin upgrade process, since the existing code
 (including the silent deactivation) is what we want -- with the exception
 of the activation hooks being re-run when the plugin is reactivated -- it
 would be very simple to just modify the existing re-activation so that it
 also operates in a "silent" mode that doesn't call activation hooks.

 Currently, deactivate_plugins() accepts an optional $silent parameter, but
 activate_plugins() and activate_plugin() do not. I'd suggest adding one so
 that these activate and deactive functions are more consistent. Then,
 class-wp-uploader would just set $silent to true when reactivating. To me,
 having both activate and deactivate functions accept $silent parameters
 would be nicely consistent.

 So, the single upgrade method would be what you want: activate/deactivate
 hooks no, but error check yes.

 Then, even if you go the other way (eliminate the single upgrade code and
 run everything through bulk upgrade), the effort wouldn't be wasted since
 probably will want to add this "activate in silent mode" function to the
 bulk upgrade process to add error checking anyway.

 Anyway, let me know if you have any feedback on that idea, I could easily
 code this up.

 re: chaining http redirects, this starts to look icky to me. It seems like
 a perfect use case for AJAX, but I don't know what the rules are for JS
 dependency in the WP backend.

 > It's been "common" to utilise the activation handler to die-out to
 prevent the plugin being activated on blogs that do not meet the
 requirements, I cant think of a plugin off the top of my head which does
 this, But the old upgrade method had the ability that plugins could
 deactivate themselves upon upgrades if the new version wasn't compatible
 for some reason.

 That might be something to relate to #14912. Alternately, if there were an
 "install" hook, plugin authors would stop caring that the activation hook
 is run on both installs and upgrades.

 To turn this hack into more of a sanctioned API, could just define an
 exception class like PluginValidException or something that plugin authors
 could choose to throw to disable their plugins. Put the try/catch in
 do_action() and then plugin authors could say "disable me" whenever they
 discover a problem, not just activation.

 Another idea would be to have plugins be able to provide a list of
 requirements (i.e. things that would be easy for !WordPress to check, like
 PHP version and required PHP modules) that !WordPress would check, or else
 optionally register a callback that would be called on
 install/activation/upgrade to do whatever checks it wants and return a
 TRUE or raise an informative exception whether it should be enabled or
 not. With something like that you wouldn't even have to install the plugin
 first, just unzip in a temp location and do the check, which would make it
 easy to just leave the old version of a plugin installed if the new one
 isn't compatible.

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