More protection against fatal errors from plugins

[nacin]

Willing to split this into more tickets if these ideas gain traction.

More realistic sandboxing. It would be interesting to perhaps kill most of the WP environment while trying to sandbox a plugin on activation, to catch more fatal errors. For example, unset $wp_rewrite, which would prevent add_rewrite_tag() issues (on activation) for plugins incorrectly trying to register rewriting for taxonomies or post types. Of course, most of these plugins are already running on a blog when the auto-upgrade happens. Hence the second item:

Check plugins before an auto-upgrade. We can do plugin update checks to verify their compatibility (as reported by the author?) with the version they are about to upgrade to. If the plugin is in the repo and is not identified as compatible with that version, then very strongly advise they deactivate it (and consider doing it for them).

Check a site after an auto-upgrade. Since we only recommend deactivating plugins on auto-upgrade, and I'm not sure we should forcibly do that as part of an auto-upgrade, then let's check the site after an upgrade. Hit wp-load with an HTTP request and look for a header we spit out on the wp_loaded hook. If we don't get a header, then deactivate all plugins and tell the user "told you so". We could consider trying to reactivate plugins until one fails as well (also a valid option for the previous suggestion).

[jorbin]

Those all seem like decent enhancements for a future release. I think it comes down to providing a UX for upgrading that helps users. I would like to see the UX work like this:

User vists the guu panel. They are told:

A new version of WordPress is available. Based on the information reported by other users, the following plugins may have conflicts with the upgrade:
XXX
YYY
ZZZ

It is recomended that those plugins be disabled before you upgrade. Would you like those plugins to be automatticly disabled upon upgrade or should the upgrade proceed with those plugins active:

Yes|No

After Upgrade:

Please check your site and all of it's functionality. If you notice an error, [please file bug report]

clicking on that lightboxes a form that submits data on the server and all plugins active (before and after the install) (plus any other info we want, but that is clearly expressed to users).

---

I think rather then the told you so option, we should offer an automatic tryer that activates and does an ajax check for each option

[dd32]

Another note is, that many plugins will hook to init obviously.

Theres a problem in the sense that, plugins which run EVERYTHING on init, can fatal, but since init is not run during the sandoxing (The plugin is included after WP is setup) they can be missed by the sandboxing.

[WebTechGlobal]

"Check plugins before an auto-upgrade."

We created something like this by sending clients blog specs to us using SOAP. We compare the specs to a profile we have for the plugins they have purchased. We can use it to warn them of conflicts before they even download the plugin.

I would much prefer the core to simply use specifics in the plugin. An array of changes to both code and specifics which Wordpress loops through prior to updating.

We pretty much have this in our plugins already, even in our free plugins. But what we cannot do is prevent the existing plugin files being written over. So already changes are made and THEN users find out that a new version could cause problems. This is where a second plugin directory would come in. There is a ticket for the ability to have nested plugin directories. Possibly two birds one stone on that.

That second directory and reading the readme.txt plus main file would be a good start. The files would be temporary obviously.

[nacin]

Duplicate of far more complete ideas.

[SergeyBiryukov]

Related: #25137

[SergeyBiryukov]

Related: ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-10-26&sort=asc#m714213

[dd32]

Related: ​​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-10-26&sort=asc#m714213

Attached my patch here: 14096.diff​

It's a hacky little hack that detects fatal errors during the Plugin inclusion loops by using a shutdown function - based off the global variables it can then determine which plugin we were including at the time of the fatal - once it knows what plugin caused it, it disables that plugin.

I wrote it as a proof of concept, and it isn't really ideal for core inclusion at present but does open up a option to prevent plugins taking a site down.
This also showed to me that it's possible for a plugin to fatal on inclusion, but NOT fatal during our plugin sandboxing, if a plugin uses a function from pluggable.php directly (or anything else that's not ready for purpose pre-init) then it's possible for it to fatal then, but the sandboxing said it's fine (as it's operating post-init there).