#37563 closed defect (bug) (fixed)
On page updates: Bulk actions FTP dismissal issues
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.6 | Priority: | normal |
Severity: | normal | Version: | 4.6 |
Component: | Plugins | Keywords: | has-screenshots has-patch needs-testing commit |
Focuses: | Cc: |
Description
If you are using the FTP transport, do bulk updates on plugins (and likely themes. untested at this point), and dismiss the modal to enter your FTP credentials, there are some UI/UX issues.
- The "There is a new version of…” notices become blank
- The updates boxes you had checked become unchecked.
(potentially more, additional testing is needed).
Attachments (14)
Change History (44)
This ticket was mentioned in Slack in #feature-shinyupdates by jorbin. View the logs.
9 years ago
#4
@
9 years ago
- Keywords has-screenshots has-patch needs-testing added
- Version set to trunk
37563.diff is a possible approach to cover the cases illustrated in the screenshots above:
- stores in the element's jQuery
.data()
also the originalaria-label
attribute for later re-use onplugin-install
andplugin-install-network
- adds a check for
originaltext
that can be undefined, for example when canceling the FTP credentials during a bulk update, and in this case directly gets the HTML instead of trying to get the HTML stored in.data( 'originaltext' )
Definitely needs testing and review, not sure all the edge cases are covered.
#5
@
9 years ago
37563.2.diff doesn't trigger the modal close action for all items in the queue anymore, but only for the one that is currently processed. It also lets individual jobs handle asking for the FTP modal. Additionally it keeps checkboxes checked until the action on the item has been completed.
#6
@
9 years ago
37563.3.diff uses the (notoriously unreliable) plugin slug rather than its basename because since [38168] that is not always available anymore.
#7
follow-up:
↓ 10
@
9 years ago
Seems a better approach, doesn't address the aria-label
issue though. On plugin-install
and plugin-install-network
it needs to be restored to its initial value when canceling the FTP modal, see comment 3
#8
@
9 years ago
37563.3.diff: Removing wp.updates.maybeRequestFilesystemCredentials( event );
seems to be a bad idea because the user gets the modal with an error now, see modal-with-error.gif.
#10
in reply to:
↑ 7
@
9 years ago
Replying to afercia:
doesn't address the
aria-label
issue though
Yeah, I think your approach makes sense there. There are four more instances though where originaltext
gets set. Maybe we should abstract that into a function and cll it from within those action handlers.
#11
@
9 years ago
37563.4.diff: When I now cancel the dialog the status remains at "Updating…" but only after a failed connection, see cancel-updating-remains.gif.
#12
@
9 years ago
37563.5.diff is an iteration on 37563.4.diff that fixes cancel-updating-remains.gif by adding back the foreach loop for 'credential-modal-cancel'
. That way the message gets reset correctly.
It also fixes the aria-label
on plugin-install.php
so they get reset correctly after canceling the modal.
I haven't looked at 37563.diff much, but if it's a serious problem it should be easy to turn this into a new function and use that where needed.
#13
@
9 years ago
Fixing 11 only required adding the rejected job back to the beginning of the jobs queue rather than appending it.
#14
@
9 years ago
@obenland Ah, I see. Leads to the same result. Wanna combine that with the aria-label
changes in 37563.5.diff?
#15
@
9 years ago
Hm, I'm not sure. I think I like your patch better than mine. Let me test it a bit more
#16
@
9 years ago
37563.7.diff is @swissspidy's patch but adding the rejected job back to the beginning of the jobs queue rather than appending it, which seems more appropriate to me. We probably don't need to loop over all jobs and trigger the modal-cancel action, but safe is safe.
#17
@
9 years ago
37563.8.diff is 37563.7.diff but with my copy paste error fixed in tests/qunit/fixtures/updates.js
.
#18
follow-up:
↓ 20
@
9 years ago
- Owner changed from obenland to afercia
37563.9.diff is 37563.8.diff but removes the "now" suffix. The patch works as expected for me.
@afercia, @jorbin: Does it fix the issue(s) for you too?
#20
in reply to:
↑ 18
@
9 years ago
Replying to ocean90:
but removes the "now" suffix
The most important thing is having the aria-label
correctly synced with the button text with the addition of the plugin name to give context. Not restoring "now" is really not an issue :)
This ticket was mentioned in Slack in #feature-shinyupdates by ocean90. View the logs.
9 years ago
#22
@
9 years ago
- Keywords commit removed
37563.10.diff corrects the labels for "now" actions. But there is an issue in the list table, see wrong-label.gif. An aria-label gets added to the notice.
#23
@
9 years ago
37563.11.diff fixes comment:12.
#24
@
9 years ago
- Keywords commit added
Forgot to mention that 37563.11.diff fixes also the wrong aria-label for plugin network activation buttons.
Looking a bit at this, I think 2) is intentional. About 1) noticed that when clicking on the "update now" link on the plugin row and the FTP credentials modal opens,
wp.updates.updatePlugin
runs and set theoriginaltext
data. Easy to check because the update available notice changes and the icon starts spinning:Instead, when bulk updating
wp.updates.updatePlugin
does not run, not sure if this is intentional. See below: no updating notice and no spinning icon:so,
originaltext
data is undefined when canceling the modal. At this point if$message.find( 'p' ).data( 'originaltext' )
is undefined maybe it should directly get the$message.find( 'p' ).html()
.