Plugin Sandboxing

I just finished a feature for WordPress 2.2 that I’m pretty excited about. Not that it’s anything sexy or groundbreaking. It’s just one of those “it just works” features that sits in the background minding its own business and doesn’t reveal itself until you really need it.

Here is the first scenario:

You find (or write) a great new plugin and upload it to your /plugins/ directory. You activate it and — oh no. PHP Fatal Error. Someone missed a curly brace somewhere. No problem, you think, that’s what the back button is for. But guess what, the plugin is active, even on the Plugin management screen. Now your entire blog is down as well as the WordPress administration interface. At this point, your only recourse is to FTP in, find the plugin, and delete or rename it.

While that scenario is aggravating enough, it’s nothing compared to the second scenario:

You’re on the road, checking your mail at a computer that’s not your usual computer. You notice an e-mail from someone saying that one of the plugins on your site is misbehaving. You navigate to the Plugin Editing screen in WordPress and quickly correct the problem. Hurray for in-WP plugin editing! But when you click the save button, you get a fatal error. You must have forgotten a semicolon somewhere. And suddenly you realize that you don’t know your FTP password, so the only method you have of editing your plugin is now blocked. And you won’t have access to your main computer for 3 days, during which time your blog will be broken.

If you’ve ever experienced one of the above, you know how annoying it is. So the feature I’ve put into WordPress 2.2 is what I call plugin sandboxing. Before a plugin is activated or a plugin is edited, it is tested in a temporary fashion (that is, without being permanently activated). If it passes the test, it is activated for real. If it doesn’t pass the test (it’s throwing a fatal error that would normally take down your WordPress install), it is deactivated, and you get a nice error message telling you what went wrong. If the fatal error was caused because you edited an active plugin, the “Update File” button changes to “Update File and Attempt to Reactivate,” so that once you correct your typo, the plugin will go back to being activated, without requiring you to go back and manually activate it.

If you never activate a flawed plugin or never make a typo when editing your plugins, you’ll never know this functionality is there. But some day you just might slip up, and now WordPress will cover for you.

39 thoughts on “Plugin Sandboxing

  1. Fantastic functionality addition Mark. This may just be a life saver!

    But, can it be extended to more than plugins? Maybe themes as well?

  2. I’m excited about this new functionality! I’ve done your first scenario more than I care to admit, and while a sandbox is no replacement for actually thinking things through, it’s going to help me a ton.

  3. Sounds like an excellent feature! At the moment I tend to use a “sandbox” installation of WP on a sub-domain to test things out before I install them but this should make things even easier.
    Looking forward to seeing what else you guys can come up with.

  4. Now this should be fantastic! It saves us all the trouble of using FTP just to fix a broken plugin.

    Btw, why don’t we offer a direct upload for plugins from the wp-admin itself?

  5. Halil,

    In WordPress 2.3, it will show the error message to the user (but still refuse to activate the plugin). I think this is the best of both worlds, because you know why the plugin failed, but it doesn’t take your site down.

  6. Just to clarify what Mark said. In WP 2.3, it WILL show the fatal error message BUT ONLY IF you have PHP display_errors turned on. I guess it’s obvious, but I chased my tail for a while before I finally got it to work.

  7. helendreamseries says:

    Mark,
    I can’t find the WP Plugin Management Screen link. Can you direct me?
    Thanks,
    Ginger

Comments are closed.