[wp-trac] [WordPress Trac] #48850: Plugins Screen: introduce "Automatic updates" column / option

[WordPress Trac]

#48850: Plugins Screen: introduce "Automatic updates" column / option
-------------------------------------+-------------------------------------
 Reporter:  jeherve                  |       Owner:  audrasjb
     Type:  feature request          |      Status:  accepted
 Priority:  normal                   |   Milestone:  5.4
Component:  Plugins                  |     Version:  3.7
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  administration,
  has-screenshots dev-feedback       |  multisite
  needs-dev-note                     |
-------------------------------------+-------------------------------------

Comment (by audrasjb):

 Replying to [comment:56 johnjamesjacoby]:
 > > For the moment, the idea was to start with the existing UI, and to
 refine that after the feature is fully functional
 >
 > What do you mean by "existing UI"? I see a few suggestions in this
 ticket, none of which are in WordPress already.

 I meant: starting with something that doesn’t add new styles or extra
 columns or new control that doesn't exists yet in Core, but to clarify:
 it's totally ok to propose the same patch with alternative design :)


 > > we know that it's ok from design and accessibility perspective
 >
 > I really do not think that it is, though. The feedback in this issue I
 happen to agree with, that the words are too long, the icon is foreign
 (and not really the correct one to use), the links are awkwardly
 positioned next to other links that serve other different purposes, all of
 which together result in a design that does not look elegant or appealing
 or easy for users to identify and interact with without a high probably of
 trial & error. (Maybe it's accessible, but I don't see anything in this
 ticket that confirms that specifically.)

 I can confirm it's ok from an accessibility point of view, and the design
 team already discussed the current patch during meetings. But I know they
 are not totally comfortable with the current proposal so alternatives are
 very welcome. In any case, the ticket is open since weeks, so other design
 should be proposed as soon a possible to help this moving forward.


 > > also, deep code review and testing is more than welcome
 >
 > When everything is undecided and in-flux, code review seems premature.
 Personally, I'm always happy to help (and only trying to be helpful) but I
 have a hard time reviewing some parts (code) and not others (design)
 because it's all equally important, and they both rely on each other.

 I personally think we need to need a solid code basis first, but I admit
 it's very personal as well :)


 > What user wants to go through 50 plugins and click 50 links and enable
 them all manually? (Bulk Edit helps, but still feels weird to me for
 reasons that are hard to put into words right now.) Once they're on, what
 problem will come up that will make them visit the plugin screen and
 disable one or many of them later?

 To change autoupdate system for 50 plugins / 50 clicks at once, they will
 want to use the bulk edit select, just like they do when they want to
 update/activate/deactivate multiple plugins at once.


 ---
 Concerning the opt-in choice, this is in the scope of the plugins/themes
 autoupdate project since the beginning, and it was proposed as opt-in in
 2019 in the 9 projects for 2019 post. This is why that ticket is based on
 opt-in :-)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48850#comment:57>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform