[wp-trac] Re: [WordPress Trac] #8568: Plugin activation hook should
not be run when scraping errors.
WordPress Trac
wp-trac at lists.automattic.com
Tue Apr 28 11:51:33 GMT 2009
#8568: Plugin activation hook should not be run when scraping errors.
------------------------+---------------------------------------------------
Reporter: sambauers | Type: defect (bug)
Status: closed | Priority: normal
Milestone: | Component: Plugins
Version: 2.7 | Severity: normal
Resolution: wontfix | Keywords: has-patch tested dev-feedback
------------------------+---------------------------------------------------
Changes (by Denis-de-Bernardy):
* status: new => closed
* resolution: => wontfix
* milestone: 2.8 =>
Comment:
Replying to [comment:12 hakre]:
> I - as a plugin developer - am quite confident with the current
implementation. It ensures that errors created by plugin activation are
covered. This is usefull.
Not really. It won't cover a variety of other potential errors that could
be caused by a plugin's internal functionality. The current implementation
will merely check for valid php syntax. It's not as if it ran every last
hook in $wp_filter with the correct set of arguments to check if all goes
well indeed.
> Calling the Deactivation Hook must not be necessary here because the
code in question is only executed if the Activation Hook fails. So I
assume it will never be executed? Or will it?
To me, whichever works, since I never clean up the options I introduce --
in case the user reactivates the plugin later on. I think the issue Sam
was concerned about is more along the lines of: on activate, create a db
table (without checking if it exists). you can then get an actual error.
Anyway, let's just close this as wontfix, as there obviously isn't much
traction. :-)
--
Ticket URL: <http://core.trac.wordpress.org/ticket/8568#comment:13>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list