Allow plugins to be deleted via the WordPress admin interface / Group plugins by status

attachment 7091.diff added

Not sure why thats not showing a HTML preview, I had to manually edit some Diff chunks out of the file(Which i usually do) so if it doesnt apple cleanly, say so.

Theres a HTML dump of the plugins page available here: http://dd32.id.au/files/wordpress/plugin-delete-stuff/manage-plugins.html
(Note that i've got my remove-max-width plugin activated there, which is why everything is stretched)

As you can see, The page becomes much more manageable with them divided into groups, However, it shouldnt be too hard to reverse the grouping if need be, But with a plugin installer, I can see many more people ending up with plugins they've tested, but just left unactivated.

Fixed the HTML preview.

• Needs some descriptive paragraph under each heading for what that set of plugins are.
• Needs better text for no plugins (Currently: "No plugins to show")
• If all plugins are active, Should the Available plugins table be hidden, or show no plugins?
• If there are no recently deactivated plugins, That table does not show.

(In [8049]) Bulk delete/activate/deactivate for plugins. Split plugins into active and available lists. Props DD32. see #7091

I removed "Selected" from the bulk op buttons for consistency with other admin screens. Arguably the buttons are clearer with the text, but let's opt for consistency for now.

I removed "Selected" from the bulk op buttons for consistency with other admin screens.

I wasnt too sure of that either myself.

Also, I might change 'mass-manage-plugins' to 'bulk-manage-plugins' to fit in with whats used on other pages.

The delete branch can currently be done by anyone with the manage_plugins capability, I'm thinking of opening a new ticket to add delete_plugins and upgrade_plugins cap. It'll reduce the edit_plugins cap back to pure editing of the plugin file, and allow finer grained control over who can do what to the plugins in general.

I'm thinking of opening a new ticket to add delete_plugins and upgrade_plugins cap.

#7096

Hackers list discussion on UI:

http://comox.textdrive.com/pipermail/wp-hackers/2008-June/020490.html

I kinda like the new three-way split, but another option is to do a filter similar to the filters in the Posts, Pages, and Comments manage screens.

All Plugins | Active Plugins | Recently Active Plugins

Exception Handling Issue: Multiple plugins in the same subfolder (sub-directory)

If a plugin file is in a subfolder of the plugins directory, then the entire folder gets deleted, correct?

(Subfolder = a directory under the wp-content/plugins directory)

For example, Lester Chan's WP-PostRatings? plugin (http://wordpress.org/extend/plugins/wp-postratings/) consists of two separate plugins, the main plugin plus a ratings widget which is a separate file. If I go to delete either one, the entire folder is deleted. I also tried this by randomly putting one plugin file into the subfolder of another plugin. If I delete that random plugin, then the subfolder is deleted.

If the main wp-postratings plugin is active, I can still delete the widget plugin, which deletes the entire folder.

Deleting a single file plugin (e.g., the hello.php file) that is in the main plugins directory works okay.

From this page (http://codex.wordpress.org/Writing_a_Plugin), it looks like the "preferred" locations for plugins are (1) the main plugin directory, if the plugin only has a single file; or (2) a subfolder, if the plugin has multiple files.

Even if plugin authors are not following that the preferred folder conventions,** I think the safe course* would be that before a plugin is deleted, it's folder location is checked against the other plugins. If two plugins share the same subfolder, then the plugin should not be deleted through the WP interface. Some sort of error message should appear: "This plugin is in the same directory as (plugin names listed). For your protection, automatic deletion cannot continue on this plugin. Please delete manually."

*Who is the end-user going to blame? The user selects a plugin to delete. In the mind of the typical user, that should only delete the plugin and nothing else. Other plugins should be left alone. The end-user did not authorize the other plugin(s) to be deleted, just the one that they checked. The user is going to blame WP for creating a confusing UI, not the plugin author for failing to follow some design convention that the user doesn't know about and should have no reason to know about.

**I could see web design professionals putting multiple single-file plugins into the same subfolder for organizational purposes, especially if those were a suite of custom plugins. And, I'm sure that there are some good reasons for organizing multiple plugins under the same subfolder rather than having them all in the main plugins folder (a developer with a test folder where they dump any little plugin they are working on, and so forth).

Exception Handling Issue: Multiple plugins in the same subfolder (sub-directory) If a plugin file is in a subfolder of the plugins directory, then the entire folder gets deleted, correct?

Correct. The plugin upgrader currently will delete the entire folder if a plugin is inside it too. So if a plugin is in great-plugins/plugin-name.php the folder great-plugins will be deleted upon a plugin upgrade, or clicking the delete button.

From this page (http://codex.wordpress.org/Writing_a_Plugin), it looks like the "preferred" locations for plugins are (1) the main plugin directory, if the plugin only has a single file; or (2) a subfolder, if the plugin has multiple files.

Correct, However, The plugin upgrader will *allways* place upgraded plugins into a folder, That's the "prefered" way as far as the plugin setups currently go, Folder per plugin, one plugin per folder

would be that before a plugin is deleted, it's folder location is checked against the other plugins.

That would indeed be possibly useful, If multiple plugins are detected in a folder, then do not delete the entire folder, Sounds like a plausable solution for the delete button however it will not affect the plugin upgrader, Due to the fact that WordPress cannot know what files (other than the main plugin php file) belong to that plugin, or other plugins, Given that the upgrader is in the wild now, It seems like a step in the wrong direction to disable it for certain folder setups.

**I could see web design professionals putting multiple single-file plugins into the same subfolder for organizational purposes, especially if those were a suite of custom plugins.

I can see the same happening, However, it is a very edge case. Developers should try and keep plugins in seperate folders though, if not only just to allow them to use Source Control applications such as SVN on them.

I'll be adding a confirmation dialoge on the delete function, I'll make it spell out the files its deleting, And the plugins which it'll affect.
That should give users an extra warning of "Are you sure you *really* wanted to do that, And if so, here are the files that *will* be removed, Continue?"

attachment 7091.2.diff added.

• Introduces Delete Plugin confirmation page
  • Deleting the selected plugins will remove the followign plugins and their files:...
  • Click here to see a Full list of affected files
• function list_files() was introduced to get a list of all files in a directory and recursive to however many directories (Should also be useful in other directory listing areas such as searching for themes or plugin files?)
• A change snuck into validate_active_plugins():
  • Rely on validate_plugin(), Which also checks that there are no characters such as .. in the filename
• Changed nonce from mass-manage-plugins to bulk-manage-plugins
• Delete page could do with some extra styling.

Replying to scribblerguy:

Exception Handling Issue: Multiple plugins in the same subfolder (sub-directory)

What if we added a new stipulation to how plugins were created, that includes a file list? Perhaps the following format, in the plugin header:

Associated files: dictionary.txt, langs/ (meaning the entire subdirectory named langs), user/user1.cfg

Then in the delete/update functions, the following would be added:

1. Check for file list 2. If no file list exists, and plugin is in a subdirectory, show warning, including a list of files that will be deleted, then delete the entire subfolder 3. If file list exists, delete only those files, and then perform a check that would delete any empty subfolders.

This new stipulation could be considered another step in making sure plugins are compatible with version 2.6 (even though, for backwards compatibility, it wouldn't actually be *required* until 2.7 or 2.8, if ever).

What if we added a new stipulation to how plugins were created, that includes a file list?

I heard someone mention that a Plugin manifest/package was being thought about recently..

I think just telling plugin authors to keep all their files in a folder, and having one plugin per folder makes the most sense to me..

In the latest patch, If you ask to delete a plugin, that that plugins folder has 3 plugins in it, the confirmation will ask "By deleteing the selected plugins, You will remove the following plugins, and any files related to them: Plugin1, Plugin2, Plugin3"; It also has a link to view *all* the files which will be deleted.

(In [8095]) Delete plugin confirmation from DD32. see #7091

attachment 7091.3.diff added.

• s/available/inactive
• Do not show Active plugins table if none active
• Do not show Inactive header w/ no table if all plugins active
• Added paragraph for when No plugins are loaded, As when no plugins are available, No plugin tables are shown.

attachment 7091.4.2.diff added.

• Same as the 7091.3.diff changes
• Adds a "Clear List" option to the Recently Active list for those who like to keep it cleaner
• Added the descriptive text "The following plugins were recently active, When a plugin has been inactive for more than 7 days it will be moved to the Inactive plugin list." for the Recently Active list, Open to re-wordings.
  • Slight change in wording from 7091.4.diff & forgot to check overwrite box :)

(In [8218]) Plugins page layout improvements from DD32. see #7091