WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#10168 closed enhancement (wontfix)

Easy to update the wrong plugin by accident, if...

Reported by: hakre Owned by: janeforshort
Milestone: Priority: normal
Severity: normal Version: 2.8
Component: Plugins Keywords: needs-patch
Focuses: Cc:

Description

The usability of the plugin interface in admin can be improved. If you have two plugins beneath each other that are updateable it can happen that you click the wrong link to update while in rush.

Being in rush only means that you do look and click faster. This is a sign that usability can be improved because it is not easy to use.

I can imagine an UNDO feature for the plugin update or the other thing would be posing question if it is really intended to upgrade _that_ plugin.

Attachments (1)

screen-capture.png (78.7 KB) - added by Denis-de-Bernardy 5 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 hakre5 years ago

  • Version set to 2.8

comment:2 Denis-de-Bernardy5 years ago

  • Keywords reporter-feedback 2nd-opinion added; developer-feedback removed
  • Milestone changed from Unassigned to 2.9

I honestly fail to see how we could improve the above screenshot any further...

The update link could go alongside "Activate | Delete" et al, but that seems a bit wrong.

The screen to enter the FTP Details could contain the package's name, though.

comment:3 hakre5 years ago

An improvement would be to pose an additional question after the click wether or not the plugin should be updated. For a straight visual improvement I do not have an idea.

comment:4 hakre5 years ago

Having the question would mimic the same behaviour as delete. And should not be that hard to integrate.

comment:5 follow-up: dd325 years ago

  • Keywords reporter-feedback removed

The screen to enter the FTP Details could contain the package's name, though.

Except not everyone has to deal with that screen.

If people insist on a warning, Then a JS confirm is the only type I'd remotely support.

comment:6 Denis-de-Bernardy5 years ago

  • Keywords 2nd-opinion removed

comment:7 in reply to: ↑ 5 hakre5 years ago

  • Keywords needs-patch added

Replying to dd32:

If people insist on a warning, Then a JS confirm is the only type I'd remotely support.

That is so not taking care then. As webdev you should ever take the JS=OFF route first and enhance it later. So for those who have JS=ON can save one request.

Infact, before making things complex, just go the same route as delete. For delete there actually is no JS warning. It works pretty straight forward. Because the principle of the implementation of the question is already done with the delete action and the user already knows how to deal with it, it is a strong argument _against_ doing things in a new way here. Like introducing a JS confirm.

comment:8 dd325 years ago

My definition of that was a JS comfirm for those with JS, a fallback should always be available for non-js users, but those with js should never see it.

IMO, the UI should make it clearer as to which plugin it is, theres a ticket on that which missed 2.8

comment:9 westi4 years ago

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

I think the current implementation of this is clear enough.

Assigning to Jane for a second opinion.

comment:10 ryan4 years ago

  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from reviewing to closed

wontfix until we revisit the plugins UI again.

Note: See TracTickets for help on using tickets.