PlugInstaller

This just means that you cannot use this plugin on a server that is based on a windows operating system. You can, of course, use it on your linux server if you browse the internet from a windows-based client computer.

PlugInstaller completely replaces the plugin management page. You will find your plugins listed in a more space-saving way, as this space is used to display additional information.

The deactivated plugins will be listed at the bottom of the plugins management page, not along with the active plugins.

Press the "Check for updated plugins" button at the bottom of the list of deactivated plugins. Checking may take a little while, so be patient. If updates are found, a message will appear on the screen telling you that updates are available. Additionally, a yellow "Update"-flag will appear behind those plugins that have updates available.

Click on the yellow "Update" flag behind updateable plugins (be sure to check for new updates in regular intervals). This will automatically upgrade the selected plugin.

Updates are only working with a restricted set of plugins from the wordpress.org plugins repository. PlugInstaller takes measures against those problems when installing a plugin the first time. If you experience plugins that are hosted on wordpress.org but that do not support automatic updating, just uninstall them and install them again using PlugInstaller. After this step, automatic updates should be supported on those plugins.

I am continuously working to make PlugInstaller compatible to almost every plugin. But you as a plugin developer can follow a few guidelines to ensure your plugin's compatibility with PlugInstaller.

• Include a readme file: Be sure to name that file "readme.txt" and place it in the trunk path of your svn repository. Be sure to name that file exactly "readme.txt", no capital letters!
• Refrain from using subdirectories: Placing your main plugin file inside a subdirectory of the trunk or the stable tag confuses not only wordpress, but also PlugInstaller. You can, of course, use subdirectories for additional files such als libaries, images and so on.
• Make your plugin work from the standard directory: The wp.org plugin repository creates a zip file containing a directory that is named after your project's main path. The PlugInstaller ZIP file, for example, contains a directory named "pluginstaller". Don't make your plugin require to be in a directory named other than your project's svn name (e.g. providing PlugInstaller in a directory called "pluginst").
• Comply to the wordpress.org plugin conventions.

Well, did you ever try to exchange your old car with a new one while you were driving on the motorway? It's exactly the same problem: PlugInstaller is needed to update plugins, but if you update a package, this package will first be deactivated (you cannot delete active plugins without throwing lots of error messages). But how should PlugInstaller upgrade itself if it is deactivated?

Below the list of deactivated plugins you will find a list of "broken plugins". Broken plugins are subdirectories inside your plugin directory that do not contain any plugin files. If a plugin shows up on that list after it has been installed, this means that the plugin cannot be installed by PlugInstaller. You may safely delete the broken plugin by selecting the "delete" link behind the directory name.