The report at the end of the drupal database update process is very confusing.
It asks users to look to see if there are any errors reported on the page, and assume the update was successful if there are not. The could make a user nervous (for real site), even when the there are no failures listed below or nothing logged.
Originally reported by @tsvenson on #2341575-42: [meta] Provide a beta to beta/rc upgrade path
Detect whether any errors occurred during the update process and show one of two different messages.
The amount of text on this screen will be reduced and easier to understand.
None
None
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2558765-3.patch | 2.37 KB | stefan.r |
Comments
Comment #2
xjmAs a scoped usability improvement that is not adding new user-facing functionality, I think this UI change qualifies as a task.
Comment #3
stefan.r commentedComment #4
stefan.r commentedComment #6
tsvenson commentedI've closed #2557097: The update result UI report needs clarifications and reposted the important content below as this issue is already in progress with patches:
Note: The screenshot referred to is the same as in the issue summary.
---8<...
[Added: There where actually one update that didn't take the first round. Drupal's red system message (not visible on the page above screenshot was taken from) told me there where issues and I had to go through the Status report to discover this. It went through the second time without protesting. Is it possible to catch this and present the option to rerun the update in the modal above?]
Particularly those three highlighted is not helpful at all, instead would probably make me quite nervous (for real sites) even when the there are no failures listed below or nothing logged.
Is there no way for Drupal to verify that all known updates queued up have been performed and that the storage server (MySQL in my case) have not choked on any of them?
Right now the text tells me Drupal 8 can only guess and I can only hope that the lack of listed failures and no logged errors mean it actually worked as expected.
I would be happy to work with someone who knows the code involved here, to develop a better report than the one in the screenshot above. Feel free to ping me on IRC, I usually leave my computer logged in on #drupal-contrib and other channels.
---8<...
From issue comment (slightly improved for readability): https://www.drupal.org/node/2557097#comment-10255901
My proposal is to break this down into:
---8<...
Updates performed:
Information:
---8<...
Comment #7
stefan.r commented@tsvenson I agree this would be an improvement. We have a patch already so you can manually test it or work further on it if you like (#3). Let's just keep the scope small and limit this to showing two different messages?
Comment #8
tsvenson commentedComment #9
tsvenson commented@stefan.r: Would be great if you could post screenshot(s) of the differences. My workstation is not yet setup for smooth and rapid testing of patches. Also fine with doing for example a Hangout screenshare to have a look and discussion of the progress.
Comment #10
tsvenson commentedWhen looking at (from [https://www.drupal.org/node/2341575#comment-10275527] ):
Is it not then possible for the update page to suggest re-runs until there are no more updates, or at least until a rerun does not lower the count of remaining updates?
See "Added" in #6 as example where it wasn't discovered until after clicking from the update page that there still was one remaining that went through the second time without any further error messages.
Comment #11
stefan.r commentedWell just to summarize, the messages in the patch are:
"(1/@count) updates failed while applying database updates. See the failure message below for more information.You may need to update your database manually."
and
"Updates were successful! You may proceed happily back to your site"
Other than that it's the same.
Comment #12
tsvenson commented"updates failed", "See the failure message" and "update your database manually."
Although this is technically correctly a failure, I think we need to be careful and remember that this can cause an instant panic feeling for the person performing the update on a live site. In particular when the site in question is mission critical.
In my case the second update attempt did work and thus cleared up things and there have been no errors logged since.
Therefore we need to present a message that at least make the user run update again to see if that works before there is cause for panic.
Something in the line of:
Even better would be if Drupal can re-run automatically and only warn when the count does not change after a new attempt. Thus only present the bad news when there is a real failure that needs manual attention.
Comment #25
quietone commentedSeems more suitable to the 'database update system' component.