WordPress.org

Make WordPress Core

Opened 7 years ago

Last modified 8 months ago

#20578 reviewing enhancement

Allow users to delete a plugin without uninstalling

Reported by: scribu Owned by: swissspidy
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Plugins Keywords: ux-feedback ui-feedback has-screenshots needs-patch shiny-updates
Focuses: ui Cc:

Description

Sometimes, a user may need to delete plugin files without deleting all the plugin data.

Attachments (5)

20578-delete-files-or-both.patch (4.5 KB) - added by kurtpayne 7 years ago.
Separate buttons for delete files and delete files + data
Screen Shot 2014-01-26 at 10.18.28 PM.png (51.1 KB) - added by helen 6 years ago.
After 20578-delete-files-or-both.patch - Jetpack apparently includes another plugin, hence the multiple plugins.
20578.diff (7.1 KB) - added by swissspidy 4 years ago.
20578.2.diff (8.3 KB) - added by swissspidy 4 years ago.
20578.3.diff (8.6 KB) - added by swissspidy 3 years ago.

Download all attachments as: .zip

Change History (55)

#1 follow-up: @scribu
7 years ago

Nacin say:

I think it would be good for the uninstall confirmation page to be a choice between "Delete Files and Data" vs "Delete Files". The plugin's uninstall routine would only be fired if the "and Data" was chosen.

#2 @scribu
7 years ago

One scenario: Alice wants to install the development version of a plugin, to test a certain bug fix.

She downloads the zip file. To install it, she first has to remove the existing version.

But, since she has valuable data stored by that plugin, she will have to use FTP to delete the current plugin version, instead of just using wp-admin.

#3 in reply to: ↑ 1 ; follow-up: @helenyhou
7 years ago

Replying to scribu:

Nacin say:

I think it would be good for the uninstall confirmation page to be a choice between "Delete Files and Data" vs "Delete Files". The plugin's uninstall routine would only be fired if the "and Data" was chosen.

Yes, please!

#4 @wpsmith
7 years ago

  • Cc travis@… added

Also in light of the previous ticket, it would be good to have a confirmation screen confirming deletion of plugin v. deletion + data deletion.

#5 @lightningspirit
7 years ago

+1 I suggest to use the current UI and add a new button labeled "Yes, delete both files and data" but perhaps a new design for this confirmation page may improve what we have now.

#6 @knutsp
7 years ago

  • Cc knut@… added

+1 Sometimes a plugin gets partly (un)installed during automatic update due to failing to delete the plugin folder (in use error) or a request timeout. To be able to reinstall a plugin you then must delete it, either trough FTP or the proposed delete without uninstalling action.

Plugins page should als list folders without a valid plugin inside (empty or not) and offer to delete that folder and contents. Separate ticket for this?

#7 @scribu
7 years ago

Plugins page should als list folders without a valid plugin inside (empty or not) and offer to delete that folder and contents. Separate ticket for this?

Yes, please.

#8 @ryanduff
7 years ago

  • Cc ryan@… added

#9 @kurtpayne
7 years ago

  • Cc kpayne@… added

#10 @mikeschroder
7 years ago

  • Cc mike.schroder@… added

@kurtpayne
7 years ago

Separate buttons for delete files and delete files + data

#11 in reply to: ↑ 3 @kurtpayne
7 years ago

  • Keywords has-patch dev-feedback added

Replying to helenyhou:

Replying to scribu:

Nacin say:

I think it would be good for the uninstall confirmation page to be a choice between "Delete Files and Data" vs "Delete Files". The plugin's uninstall routine would only be fired if the "and Data" was chosen.

Yes, please!

20578-delete-files-or-both.patch is a first attempt at this. It needs some language rework, and maybe a UX update (someone will be confused by 3 buttons). And having duplicate forms for the presentation logic feels clunky.

#12 @helen
6 years ago

  • Focuses ui added
  • Keywords needs-ui removed

Cool, patch still applies. Thoughts on the UI/UX front:

  • The return to plugin list button really should be a link, and should be now, too.
  • You are correct, some language needs reworking.

Will upload a screenshot momentarily for convenient discussion without having to apply the patch.

@helen
6 years ago

After 20578-delete-files-or-both.patch - Jetpack apparently includes another plugin, hence the multiple plugins.

#13 @celloexpressions
6 years ago

Could we make one of the buttons primary? Three flat options is tough, even if we tweak the wording.

#14 @grapplerulrich
6 years ago

Related: 8783

The second answer does not fully match the question.

Are you sure you wish to delete these files and data?
Yes, Delete only the files.

A better question would be "Are you sure you want to uninstall these plugins?"

#15 @Ipstenu
6 years ago

Or a better answer of "No, delete only the files."

Also why are we capitalizing 'Delete' here, following a comma?

#16 @helen
6 years ago

Ahem, you guys. kurtpayne said that he knows the language needs reworking/actual attention.

#18 @jorbin
4 years ago

  • Keywords ux-feedback ui-feedback added

This seems like a nice enhancement. I agree with the concerns about having three buttons. Would love to see a mockup or wireframe of a better confirmation page that incorporates the three options.

#19 @DrewAPicture
4 years ago

  • Keywords needs-patch added; has-patch dev-feedback removed

To move forward, this will need a new patch incorporating feedback in comment:12 from @helen.

@swissspidy
4 years ago

#20 @swissspidy
4 years ago

  • Keywords has-patch has-screenshots added; needs-patch removed
  • Milestone changed from Awaiting Review to Future Release

20578.diff is a new patch incorporating some feedback.

After (hopefully) removing the list of files which will be deleted (see #34439), I thought I should give it a shot. Why not even consider this for 4.5?

Some highlights:

Makes the 'Return to Plugins page' button a link

  • Moves the link below the buttons. Works great because of #34439.
  • I slightly changed the wording because that string is already used elsewhere

Adds primary and secondary buttons

Two buttons for an uninstallable plugin, only a single button for one without an uninstall handler.

Note: Since you can choose if data should be deleted or not, the (will also delete its data) text can be removed.

Docs

Adds the $uninstall_plugin flag to the delete_plugin and deleted_plugin hooks. Updates DocBlocks properly.

Screenshots

  1. Delete single plugin (no uninstall handler)

https://cldup.com/M0zjGHSeQd.png

  1. Delete single plugin (uninstall handler)

https://cldup.com/RPgo2aXM2x.png

  1. Delete multiple plugins (no uninstall handler)

https://cldup.com/-lZM8J3ggz.png

#21 @swissspidy
4 years ago

  • Milestone changed from Future Release to 4.5

Changing milestone for 4.5 consideration.

With the current patch the string changes are minimal, but the UI is greatly improved.

This ticket was mentioned in Slack in #design by swissspidy. View the logs.


4 years ago

#23 follow-up: @obenland
4 years ago

How many of our users will know the difference between only deleting files and deleting files and data? How many of them will be even more confused by that option?

I find the case where you would want to hang on to data but delete plugin files to be an extreme edge case from a user's POV. Even the example provided here as to why this would be a worthwhile change cites a dev scenario.

#24 @grapplerulrich
4 years ago

How many of our users will know the difference between only deleting files and deleting files and data? How many of them will be even more confused by that option?

Possible ways of finding out are: surveys or user testing. Do we have any possibility of doing this?

Even the example provided here as to why this would be a worthwhile change cites a dev scenario.

I don't think it is a dev scenario but a site management scenario. A developer can easily use FTP to replace the files. It is the site manager who does not understand FTP and prefers to use the admin area.

Another similar scenario is testing beta plugins on a staging site.

#25 in reply to: ↑ 23 @swissspidy
4 years ago

Replying to obenland:

I find the case where you would want to hang on to data but delete plugin files to be an extreme edge case from a user's POV. Even the example provided here as to why this would be a worthwhile change cites a dev scenario.

Thanks for chiming in! I thought the consensus was that this is welcome enhancement and just the details need to be set, but I'm happy to share my opinion on it.

I first stumbled upon this after a blog post (in German) by @grapplerulrich back in 2014. He noted that many people tried to delete a plugin before uploading a newer version via the browser uploader. However, while doing so they completely removed all plugin data by accident. Being able to remove a plugin without deleting its data would prevent this. Related: #9757

In the past few years I've seen many plugins (including WooCommerce and other big ones) creating custom uninstall routines just because users frequently uninstalled plugins unintentionally. There's a reason they did this, and it's clear to me that it's because WordPress doesn't prevent this, which this ticket aims to solve.

How many of our users will know the difference between only deleting files and deleting files and data? How many of them will be even more confused by that option?

With some clear wording this is a non-issue. IMHO the difference between "just delete files" and "completely uninstall the plugin" is clear and people are used to such scenarios from other software.

#26 @Ipstenu
4 years ago

I find the case where you would want to hang on to data but delete plugin files to be an extreme edge case from a user's POV.

It's less extreme than one might think. Users get plugins from non-org sources all the time. And when, in debugging, we tell them to disable a plugin, you might be surprised to see how many people delete.

Users will be less confused by 'Delete the plugin and all of it's settings and configurations' and 'Delete the plugin files' than you might think. Users actually do kinda know that the 'code-y stuff' lives in files and the 'content stuff' is in the DB :)

#27 @afercia
4 years ago

Any unintentional data loss should be avoided, maybe just better explain what "data" is? :)

#28 follow-ups: @grapplerulrich
4 years ago

@afercia - The data could be custom post types, settings, metadata or even custom tables. Anything that the plugin adds to the database during usage "should" be deleted on uninstall.

@swissspidy
4 years ago

#29 @swissspidy
4 years ago

Patch didn't apply cleanly anymore, so I created a new one (see 20578.2.diff) with some refined wording. It also now clearly distinguishes between 1 and many plugin, to get rid of the "these files and data" wording. The list of files is not displayed any longer, so this doesn't make sense anymore.

  1. Delete single plugin (no uninstall handler)

https://cldup.com/PV1AlTkY4c.png

  1. Delete single plugin (uninstall handler)

https://cldup.com/2aiG68AeXX.png

  1. Delete multiple plugins (no uninstall handler)

https://cldup.com/Qt1ODkFd2k.png

  1. Delete multiple plugins (uninstall handler)

https://cldup.com/rKKB2W_zbK.png

IMHO that's the best wording so far. It makes it clear that completely uninstalling a plugin means deleting it and all of its data.

#30 in reply to: ↑ 28 ; follow-up: @swissspidy
4 years ago

Replying to grapplerulrich:

Any unintentional data loss should be avoided, maybe just better explain what "data" is? :)

The data could be custom post types, settings, metadata or even custom tables. Anything that the plugin adds to the database during usage "should" be deleted on uninstall.

Perhaps we could add a hook where plugins can describe what exactly they would delete? Would look weird with many plugins displaying such info though.

#31 in reply to: ↑ 30 @jdgrimes
4 years ago

Replying to swissspidy:

Replying to grapplerulrich:

Any unintentional data loss should be avoided, maybe just better explain what "data" is? :)

The data could be custom post types, settings, metadata or even custom tables. Anything that the plugin adds to the database during usage "should" be deleted on uninstall.

Perhaps we could add a hook where plugins can describe what exactly they would delete? Would look weird with many plugins displaying such info though.

The plugins are deactivated at that point. :-) This couldn't be a hook, it would have to be a file header or something. See #31136.

#32 in reply to: ↑ 28 @afercia
4 years ago

Replying to grapplerulrich:

@afercia - The data could be custom post types, settings, metadata or even custom tables. Anything that the plugin adds to the database during usage "should" be deleted on uninstall.

@grapplerulrich sure, and unfortunately many, many, plugins don't remove their settings, tables, etc. But the point is: unintentional data loss.

#33 follow-up: @grapplerulrich
4 years ago

@grapplerulrich sure, and unfortunately many, many, plugins don't remove their settings, tables, etc. But the point is: unintentional data loss.

What do you mean by unintentional data loss? I agree many plugins don't remove their settings but why support a bad habit. This step should start to educate users and get them to question the theme and plugin authors.

#34 in reply to: ↑ 33 ; follow-up: @Ipstenu
4 years ago

Replying to grapplerulrich:

@grapplerulrich sure, and unfortunately many, many, plugins don't remove their settings, tables, etc. But the point is: unintentional data loss.

What do you mean by unintentional data loss? I agree many plugins don't remove their settings but why support a bad habit. This step should start to educate users and get them to question the theme and plugin authors.

The unintentional data loss is actually the devs who do have an uninstall.php and thus remove the data without users understanding what we meant by 'files and data' (which is what it says now). I don't necessarily want to run uninstall.php when I'm deleting to upgrade :)

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


4 years ago

#36 in reply to: ↑ 34 @chriscct7
4 years ago

  • Milestone changed from 4.5 to Future Release

There appears to continue to be a lack of clear consensus on the handling on specifically this topic, and the enhancement window for 4.5 closes in just over 1 week. Punting out of the milestone so a consensus and a patch which solves that problem can be developed.

Replying to Ipstenu:

The unintentional data loss is actually the devs who do have an uninstall.php and thus remove the data without users understanding what we meant by 'files and data' (which is what it says now). I don't necessarily want to run uninstall.php when I'm deleting to upgrade :)

#37 @swissspidy
4 years ago

  • Owner set to swissspidy
  • Status changed from new to reviewing

#38 follow-up: @Milmor
3 years ago

+1 for this feature.
I would leave "delete files only" as button-primary to prevent unintentional data loss.

Hope to see this feature soon. Having this supported by the core is clearer for the user and better for developers than use custom options to get uninstall intent.

@swissspidy
3 years ago

#39 in reply to: ↑ 38 @swissspidy
3 years ago

Replying to Milmor:

+1 for this feature.
I would leave "delete files only" as button-primary to prevent unintentional data loss.

Hope to see this feature soon. Having this supported by the core is clearer for the user and better for developers than use custom options to get uninstall intent.

There shouldn't be two primary buttons. A complete uninstall is the most likely action, the other is secondary.


20578.3.diff is a refresh of the previous patch against trunk.

#40 @swissspidy
3 years ago

  • Keywords needs-patch added; has-patch removed

Now with Shiny Updates V2 being part of core, we need to look into displaying this screen inside a modal (or something else) as well.

This ticket was mentioned in Slack in #feature-shinyupdates by paaljoachim. View the logs.


3 years ago

#42 follow-up: @paaljoachim
3 years ago

The most logical place is to inside the plugin delete modal have a message saying:

"Uninstall Plugin Data" - checkbox-

Last edited 3 years ago by paaljoachim (previous) (diff)

#43 in reply to: ↑ 42 @FolioVision
3 years ago

Replying to paaljoachim:

The most logical place is to inside the plugin delete modal have a message saying:

"Uninstall Plugin Data" - checkbox-

Absolutely. A modal message with a checkbox is quick and it's safe. That checkbox should NOT be checked by default (data deletion should be a deliberate choice).

#44 @swissspidy
3 years ago

  • Keywords shiny-updates added

#45 @mordauk
3 years ago

I'd love to see this too.

#46 @swissspidy
3 years ago

#37898 was marked as a duplicate.

This ticket was mentioned in Slack in #feature-shinyupdates by swissspidy. View the logs.


3 years ago

#48 @SergeyBiryukov
2 years ago

#41767 was marked as a duplicate.

#49 @alexsanford1
18 months ago

Given the upcoming enforceability of the GDPR, it is very important for plugins to give site owners the ability to delete all of the plugin's data in a safe way that is not prone to accidental deletion.

With that in mind, I think the proposed solution here (adding a checkbox to the dialog) provides a great balance between data deletion requirements and safety (so users don't delete data accidentally when trying to fix an issue with their installation, for example).

There are workarounds that plugin authors can use currently, but this should really be functionality provided by core (see some discussion for one specific plugin here: https://github.com/Automattic/sensei/issues/2116).

Any chance this could get some attention soon?

#50 @pputzer
8 months ago

Some traction on this would be nice. As is, the chance for unintentional data loss is very high. @swissspidy, are you still working on this?

Note: See TracTickets for help on using tickets.