Ticket #3254 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

Plugin sandboxing

Reported by: markjaquith Assigned to: markjaquith
Priority: normal Milestone: 2.2
Component: Administration Version: 2.1
Severity: normal Keywords: plugin has-patch
Cc:

Description

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.

Attachments

prevent_plugin_fatal_errors.001.diff (1.9 kB) - added by markjaquith on 01/25/07 07:35:24.
plugin-fatal-error-protection.mov (159.5 kB) - added by markjaquith on 01/25/07 07:36:34.
Video demonstrating how the patch works
prevent_plugin_fatal_errors.002.diff (3.4 kB) - added by markjaquith on 01/25/07 22:10:49.
Part II. Protects against fatal errors when editing an active plugin
plugin-editing-protection2.mov (133.8 kB) - added by markjaquith on 01/25/07 22:24:19.
Video demonstrating how the new patch prevents fatal errors when editing activated plugins

Change History

01/25/07 07:35:24 changed by markjaquith

  • attachment prevent_plugin_fatal_errors.001.diff added.

01/25/07 07:36:34 changed by markjaquith

  • attachment plugin-fatal-error-protection.mov added.

Video demonstrating how the patch works

01/25/07 07:39:20 changed by markjaquith

  • keywords changed from plugin to plugin has-patch.
  • status changed from new to assigned.

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.

01/25/07 20:46:43 changed by 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.

01/25/07 22:10:49 changed by markjaquith

  • attachment prevent_plugin_fatal_errors.002.diff added.

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

01/25/07 22:24:19 changed by markjaquith

  • attachment plugin-editing-protection2.mov added.

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

(follow-up: ↓ 4 ) 01/25/07 22:29:33 changed by 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.

(in reply to: ↑ 3 ) 01/25/07 22:40:42 changed by 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.

01/25/07 22:46:05 changed by markjaquith

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

01/26/07 01:16:55 changed by JeremyVisser

  • status changed from assigned to closed.
  • resolution set to fixed.

Looks like it's been committed.

01/26/07 01:17:23 changed by JeremyVisser

Sorry, forgot to mention [4811].

01/26/07 03:03:05 changed by markjaquith

  • status changed from closed to reopened.
  • resolution deleted.

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

02/14/07 06:15:08 changed by markjaquith

  • status changed from reopened to closed.
  • resolution set to fixed.

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

02/14/07 14:57:42 changed by technosailor

  • status changed from closed to reopened.
  • resolution deleted.

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

02/14/07 22:16:06 changed by 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.

03/07/07 05:53:22 changed by markjaquith

  • status changed from reopened to closed.
  • resolution set to fixed.

Reopen with more detailed reproduction steps.