The Ultimate Plugin Administration Interface

Let’s assume you have a decent web platform. It may be a CMS, a forum, a blog, a gallery, or a wiki – the point is, it works. And this platform has plugin functionality. Let’s go ahead and also assume that the process of writing a plugin and extending/modifying the functionality of existing code is made very easy by means of well thought-out hooks and filters. All what’s left is the process of installing, updating, and managing plugins on your platform. If there would be an “ultimate” plugin administration interface, what would it be?

Core Features

• Ability to remotely upload a plugin (as zip file??) through the interface without having to FTP or SSH into the server.
• An “update detection” mechanism that can be manually or automatically run to check for updates for a plugin or more than one plugins and report back.
• Automatic-detection of “corrupt” or broken plugins – so you don’t have to FTP into the server to delete a bad plugin.
• Remote plugin management: delete plugins from the web.
• “Debug” Mode: All plugins are disabled. The key here is, once Debug Mode is turned off, your plugins go back to the way they were – some enabled, some disabled, just like you left them.
• Automated hooks for installing, uninstalling, and upgrading from previous versions.

Key Ideas

• Security. Don’t allow automatic updating of plugins because you have no idea what changes have been made to their source.
• Ease-of-Use. Never have to remotely connect to your server to install or remove a plugin.
• Stability. Bad plugins won’t fry your server (a la WordPress); you don’t have to frantically SSH in, and cd recursively into the directory just to rm the file.
• Compatibility. Define a specification that can be used by plugin authors to define for what versions of PHP, MySQL, and Habari their plugin(s) work and for which versions they don’t. Even allow for custom pre-requisites via a “compatibility check” function in the plugin. If a plugin specifically states it doesn’t work, don’t let it install.
• Bleeding Edge. By means of the update detection service, there is no reason for someone to be running an out-dated plugin.
• Automation. The first time a plugin is detected, it will call a install function in the plugin. If a newer version of a plugin that was previously installed is found, it’ll call an upgrade function in the plugin, and if a plugin is queued for uninstall, the uninstall function will be launched. These functions may have user interfaces, use other private and public methods, etc. but should be complete and self-sustaining: i.e. no secondary install steps will be needed. Configuration is different from installation.
• GUIDs. Each author, upon registering his or her plugin with the central plugin repository, get’s a unique GUID for one or more plugins. This GUID is unique to each plugin, and remains constant throughout all versions of the plugin unless it’s being shipped as a different product. This feature is used in the install/remove/upgrade automation.

These ideas and features are just the beginning of what’s possible for a plugin administration interface written from the ground-up with power, control, and end-user simplicity in mind. They mean nothing without a proper UI, and some good code to back it all up. But it’s a start.

These are not just “pie-in-the-sky” suggestions and day-dreams, this is all brain-storming for a very real and very tangible project. What do you think would make the ultimate plugin administration interface? What ideas are we missing here? What would you like to see in such an interface?