Plugin sandboxing

[markjaquith]

Fatal errors in plugins make your entire blog unusable. If someone is editing or activating a plugin through WordPress and this happens, they might not know what to do (FTP in and delete or rename the plugin file).

We should, upon plugin load (and maybe in-WP plugin editing), load the plugin into a sandbox environment, with actual plugin activation as a shutdown hook. If the plugin throws fatal errors, it won't get activated.

[markjaquith]

Video demonstrating how the patch works

[markjaquith]

First swing. This prevents activation of malformed plugins and returns gracefully.

Video included for the lazy.

Next up is preventing you from FUBARing your wp-admin while editing an activated plugin.

[markjaquith]

(In [4811]) Prevent plugins that generate PHP fatal errors from being activated. ticket #3254

Might as well get this in, as the solution for preventing errors while editing plugins is going to be different.

[markjaquith]

Part II. Protects against fatal errors when editing an active plugin

[markjaquith]

Video demonstrating how the new patch prevents fatal errors when editing activated plugins

[markjaquith]

002 patch prevents you from FUBARing your wp-admin when editing active plugins.

It works by de-activating the plugin after the edit redirect. The edit redirect dynamically includes the plugin (nonce protected, natch), and redirects to the "success" message (which silently re-activates) if it works, and the "error" message if it doesn't work.

There is a message at near the "Update" button for active editable plugins that warns that fatal errors will result in the plugin being deactivated.

I think deactivation is better than discarding the changes. Someone would be very frustrated if a whole bunch of changes went down the tubes because they forgot a semi-colon.

Movie attached.

If you never make a mistake, this is all transparent to you.

[westi]

Replying to markjaquith:

002 patch prevents you from FUBARing your wp-admin when editing active plugins.

It works by de-activating the plugin after the edit redirect. The edit redirect dynamically includes the plugin (nonce protected, natch), and redirects to the "success" message (which silently re-activates) if it works, and the "error" message if it doesn't work.

There is a message at near the "Update" button for active editable plugins that warns that fatal errors will result in the plugin being deactivated.

I think deactivation is better than discarding the changes. Someone would be very frustrated if a whole bunch of changes went down the tubes because they forgot a semi-colon.

This all looks really good.

My only plea would be give the user a button on the page that allows them to reactivate the plugin when the fix the error - maybe a update and reactivate button or updating a plugin that was active should attempt to reactivate it as well.

[markjaquith]

Good idea. Will code it up when I get a chance.

[JeremyVisser]

Looks like it's been committed.

[JeremyVisser]

Sorry, forgot to mention [4811].

[markjaquith]

JeremyVisser, only got half of it in. Still polishing up fatal error protection for plugin editing (the 2nd patch).

[markjaquith]

(In [4881]) Prevent plugins from taking down the install when plugin edits results in a fatal error. fixes #3254

[technosailor]

Tested and found error. When plugin is active and then edited, fatal error still persists.

To duplicate:

1. Activate Hello Dolly
2. Edit file adding fatal error
3. Load Plugins Page

[markjaquith]

Server environment?

Did you edit the plugin from within WordPress or externally? Note that this code only works for in-WP editing.

If you introduce a fatal error in step 2, and somehow my code is not deactivating the plugin, you wouldn't be able to get to step 3... you'd have a fatal error right away.

[markjaquith]

Reopen with more detailed reproduction steps.