WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#7091 closed enhancement (fixed)

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

Reported by: DD32 Owned by: DD32
Milestone: 2.6 Priority: normal
Severity: normal Version: 2.6
Component: Administration Keywords: has-patch needs-testing
Focuses: Cc:

Description

Patch attached:

  • Allows the deletion of plugins via the admin interface
  • Groups plugins by status:
    • Active plugins
    • Recently Active plugins (Deactivated within the last week)
    • Available plugins (Deactivated plugins)
    • Removed the Status column from the plugins table as its no longer needed with that design
  • Allows activation/deactivation/deletion of a selection of plugins via checkbox
  • Deactivate_all_plugins / reactivate_all_plugins removed and replaced with mass-selection and recently active plugins list

Notes:

  • Cleaning up a bit more, Theres also some debug cruft here and there, and some things do not look 100%
  • get_plugins() caching checkup, Currently uses a global $wp_plugins, any reason why that cant be moved to wp_cache_set() / wp_cache_get() ? So as to use wp_cache_flush('plugins')(Or whatever the method, Its late :))
  • Some fiddling with menu-header.php to work with globals when the header is included from within a function
  • I completely removed the functions reactivate_all_plugins and deactivate_al_plugins()
  • It uses the WP_Filesystem classes, And asks for FTP details if needed upon a deletion.
  • It does not request confirmation that you want to delete a plugin (Needs changing IMO)
  • TESTING
  • And more things i've forgotten at this hour :)

Onc again, itts late(1am), So please be warned: The attached patch *works for me* yet it may have some bugs, i've not found any though.

Please do not test on a installation with unsaved/unbacked up plugin data

Attachments (5)

7091.diff (25.2 KB) - added by DD32 7 years ago.
7091.2.diff (8.2 KB) - added by DD32 7 years ago.
7091.3.diff (3.6 KB) - added by DD32 7 years ago.
7091.4.diff (4.8 KB) - added by DD32 7 years ago.
7091.4.2.diff (4.8 KB) - added by DD32 7 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 @DD327 years ago

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.

@DD327 years ago

comment:2 @DD327 years ago

  • Owner changed from dd32 to DD32
  • Status changed from new to assigned

Fixed the HTML preview.

comment:3 @DD327 years ago

  • 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.

comment:4 @ryan7 years ago

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

comment:5 @ryan7 years ago

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.

comment:6 @DD327 years ago

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.

comment:7 @DD327 years ago

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

#7096

comment:9 @ryan7 years ago

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

comment:10 follow-up: @scribblerguy7 years ago

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).

comment:11 @DD327 years ago

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?"

@DD327 years ago

comment:12 @DD327 years ago

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.

comment:13 in reply to: ↑ 10 @stevish7 years ago

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).

comment:14 @DD327 years ago

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.

comment:15 @ryan7 years ago

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

@DD327 years ago

comment:16 @DD327 years ago

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.

@DD327 years ago

@DD327 years ago

comment:17 @DD327 years ago

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 :)

comment:18 @ryan7 years ago

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

comment:19 @matt7 years ago

  • Resolution set to worksforme
  • Status changed from assigned to closed

comment:20 @ryan7 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:21 @ryan7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.