id summary reporter owner description type status priority milestone component version severity resolution keywords cc focuses 45940 WSOD protection should disable plugins in fewer situations markjaquith "[44524] implemented WSOD protection, for #44458. I have concerns about how aggressively it pauses plugins. It is possible to get a plugin paused in the admin by triggering a fatal error on the front of the site. Furthermore, that fatal error could be triggered by specific user input (maliciously, even). If this is a plugin that implements 2FA or SAML or admin event logging or permissions filtering or login attempt limiting or any other security- or authentication-related function, this could have dire effects on the site. Bad actors could have a way of targeting and disabling critical site functionality. I think the scenarios where this pausing occurs should be narrowed. To start, I propose that pausing not happen for: 1. POST requests (on the front end). 2. Requests with a query string other than `?p=X` (or a few other standard WordPress query strings we can whitelist). For example, if a contact form submission, in certain circumstances, can result in a fatal error, this should not pause that plugin. If some `?obscure-query-arg=BAD_INPUT` URL on a site can result in a fatal error, this should not pause the plugin. If a plugin is taking down the entire site, or preventing a user from logging in, **that** is the dead end scenario we'd like to prevent, and those are the situations in which it's an acceptable trade-off to pause that functionality so that the site owner can take steps to recover more gracefully than they could in the past. See also #45888 which proposes that critical plugins (where the plugin itself knows that it's better to take the site down than have its functionality disabled) have a way of opting out of WSOD protection." defect (bug) new high Awaiting Review General critical