Make WordPress Core

Opened 9 years ago

Last modified 3 years ago

#30976 new enhancement

When selecting multiple plugins and performing deactivate, keep selected for next bulk action (if any)

Reported by: aubreypwd's profile aubreypwd Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version: 4.2
Component: Plugins Keywords: has-patch has-ux-feedback
Focuses: administration Cc:

Description


Attachments (2)

first_pass.30976.diff (2.5 KB) - added by ashfame 9 years ago.
First pass
30976.diff (3.1 KB) - added by swissspidy 8 years ago.

Download all attachments as: .zip

Change History (14)

#1 @aubreypwd
9 years ago

  • Component changed from General to Plugins
  • Keywords needs-patch dev-feedback added
  • Severity changed from normal to minor
  • Version set to trunk

When bulk-deactivating multiple plugins I am usually aiming to delete them as well. In a long list it's a pain to re-select them over again to delete them.

#2 @SergeyBiryukov
9 years ago

  • Focuses administration added

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


9 years ago

@ashfame
9 years ago

First pass

#4 @ashfame
9 years ago

  • Keywords has-patch added; needs-patch removed

#5 @SergeyBiryukov
9 years ago

first_pass.30976.diff seems good, but we have to be careful to avoid creating too long URIs, like in #10762 or #29049.

@swissspidy
8 years ago

#6 @swissspidy
8 years ago

  • Keywords ux-feedback added; dev-feedback removed

30976.diff is an updated patch against trunk that makes the current code more readable using functions like sprintf() and checked(). Just like the initial patch, the checkboxes are still checked after plugin activation and deactivation.

Still need to get used to that functionality. Perhaps it's not needed on plugin activation.

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


7 years ago

#8 @karmatosed
7 years ago

  • Keywords has-ux-feedback added; ux-feedback removed

This feels like a really nice predictive enhancement. From a UX perspective it's a fair assumption to make.

This ticket was mentioned in PR #1134 on WordPress/wordpress-develop by aubreypwd.


3 years ago
#9

This uses transients to remember selected plugins so the next screen
still retains the selection.

The reason I went with transients here was to avoid the issue where via
current GET method the URL could end up being too long.

This is another method to keep track of selected plugins on the plugin screen like other patches on https://core.trac.wordpress.org/ticket/30976 but subverts the issue of passing the selections in the URL.

Trac ticket: https://core.trac.wordpress.org/ticket/30976

#10 @aubreypwd
3 years ago

I have another way of maybe doing this (https://github.com/WordPress/wordpress-develop/pull/1134) that does not have the URL issue mentioned above, but uses transients which may or may not be frowned upon.

Also the only UX issue I see is that when I act on plugins the selection is remembered ONLY for the next pageload, e.g. if you refresh the page your selection will be lost.

aubreypwd commented on PR #1134:


3 years ago
#11

  • [ ] I think I still need to do some work to get the selection to persist when updating plugins

#12 @ashfame
3 years ago

I like the use of transients so long urls issue can be completely avoided. How about we use local storage to save the selection as opposed to transients?

Previously we had to consider when to actually do this? Since the addition of automatic updates action, we now have the probability of a second action after every bulk action except deletion. Here are some examples:

Select > Deactivate > Delete
Select > Activate/Deactivate > Turn on/off automatic updates
Select > Turn on/off automatic updates > Activate/Deactivate
Select > Update > Activate/Deactivate
Select > Update > Turn on/off automatic updates

Note: See TracTickets for help on using tickets.