Problem/Motivation

If you try to manually trigger an available update you have currently the following steps. On admin/reports/updates/automatic-update (see Update.png) you see the current version and the available patch version to update to. At the bottom you have the button Update triggering the update process. After clicking the assets get downloaded leading to the ready to update page (see ReadyToUpdate.png).
For me as a user that page is troubling andconfusing. I am stuck in the update procedure i am half way through and i get the recommendation "Back up your database and site before you continue". Problem is the only options i have is either check the "learn how"-page or just click continue. I am uncertain what would happen if i would leave the update process half way through to run the backup migrate module or go to another page? What would happen to the already downloaded files?
Being on the ready to update page i am uncertain how to accomplish to back up my database and site there before i click continue to apply the patch. i feel a bit helpless if i try to follow the recommendation to back up my database and site.

Proposed resolution

Would it be a reasonable step to move the reminder about backing up the database and site to admin/reports/updates/automatic-update? That way the user would be reminded to actually backup before manually triggering the update. That would be probably the easiest fix.
Another option might be to provide micro copy on the "ready to update" page about what happens if the user would be leaving the "ready to update page" now to backup the site. or are there other options that come to mind?

CommentFileSizeAuthor
#13 3239759-13-before.png62.44 KBphenaproxima
ReadyToUpdate.png43.26 KBrkoller
Update.png55.42 KBrkoller

Issue fork automatic_updates-3239759

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

rkoller created an issue. See original summary.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue tags: +8.x-2.0-alpha1 blocker

Not really sure if we should this. I think there are reasons that you would want to backup the database at the last possible chance incase something goes wrong you have the most up-to-date content.

but adding as a "8.x-2.0-alpha1 blocker" to at least decide.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue tags: -8.x-2.0-alpha1 blocker

I don't think this should actually be an Alpha1 blocker.

I agree we should probably have some more help text on the start page or link to documentation that explains the steps in the update process but I don't think the correct time to backup your database for most sites in the second screen right before you apply the update. The reasons that you would want to backup the database at the last possible chance is incase something goes wrong you have the most up-to-date content.

Some people may leave the 2nd form up for a while before they actually apply the update. For instance if they get the update ready and then inform other site admins or stakeholders that they are about to apply the update. In that time they leave the form up their likely could be new content added.

We don't put the site into maintenance mode, which will stop content from being created by most users, until the 2nd, UpdateReady form. So up until we put the site into maintenance mode new content could be created.

I think after we have the Alpha there will hopefully be many more testers of the module so we can get more feedback on how to properly inform the user when they starting update of what they should be ready to do, even if they should not do all steps before they start the process.

rkoller’s picture

rkoller
he/him
Primary language German
Location Nürnberg, Germany
commented

sorry for the late reply. this one slipped through. i agree it was definitely not an alpha blocker. my initial suggestion was just an idea for an easy less work intensive fix. but in general i consider it a relevant and important problem.
i've revisited the issue. i've installed a fresh drupal 9.2.4 site with the latest automatic updates dev version again . i got to the update form admin/reports/updates/automatic-update and see hey there is an update and i click the update button. now i see the progress indicator stating the updates are getting downloaded. i end up on the second form admin/automatic-update-ready

the scenario you've outlined is definitely a valid one that the person triggering the first step of the update process is pausing it for a while and during that time if the site isnt in the maintenance mode content updates could take place. that is a clear counter argument for my suggested easy fix. i agree.

but then the second screen has to be definitely improved. if i put myself into the shoes of a novice user i have the following naive questions coming into mind when reading the recommendation "backup your database and site before you continue".

  • how do i backup my database and site?
  • am i allowed to leave that second form? there is no actionable item except the continue button to proceed and the learn more link
  • what happens with data i've download. might there be any complication when leaving the page and coming back to it (by for example bookmarking it?)
  • why should i perform a db and site backup when i update the core version manually but what happens when those updates get applied automatically? why shouldnt i backup my db and site there as well? is that done by the automatic updates module then?

and a question from your described scenario:

  • am i allowed to pause and delay the next step for exactly how long? is there some sort of possible time out and session invalidation possible?

These possible questions came to mind when i tried to apply the update manually and arrived at the second form. But I ran into an error in my recent test when i tried to continue which i've reported in #3249446. there i've noticed one detail i wouldnt have noticed as a user uncertain about the behavior of automatic updates. When i returned to admin/reports/updates/automatic-update the button was showing "Delete existing update" instead of "Update" (as well as the notice when deleting that the staged update deleted). that is excellent. but that is something that should be explicitly noted to the user on admin/automatic-update-ready . that would already solve half of the naive questions from above.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue tags: +stable blocker

added "stable blocker" tag. We should at least decide if we need to do this

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Title: Move the reminder to backup the database from the ready to update page or provide instructions » Remind users to back up their database before starting an update

Discussed with @tedbow and the conclusion we came to is that we think we should ask people to back up their DB in both places.

On the initial form, it should be worded more gently, as a friendly reminder. "It's a good idea to back up your database before you begin. Learn how." Something like that. People who are very confident in the update system and their ability to use it may choose to blow past this reminder.

Which is why we should also have it on the ready-to-apply form (as we currently do), maybe with slightly stronger wording. "You can't undo this, so if you haven't backed up your database, it is strongly recommended you do it now. Learn how." Or similar. This will also help remind people who would either prefer to back up at the last minute (i.e., a higher-traffic site), or who started an update and forgot about it for a while, to help prevent data loss if something goes awry during the apply phase.

This is pretty easy to fix, once we have the wordsmithing done, and therefore I still think it should be a stable blocker.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

Here's some proposed wording.

In UpdaterForm, how about:

$this->t('It\'s a good idea to <a href=":url">back up your database</a> before you begin.', [
  ':url' => 'https://www.drupal.org/node/22281#s-backing-up-the-database',
]);

On UpdateReady, I suggest:

$this->t('This cannot be undone, so it is strongly recommended to <a href=":url">back up your database</a> before continuing, if you haven\'t already.', [
  ':url' => 'https://www.drupal.org/node/22281#s-backing-up-the-database',
]);

I'd like sign-off on this wording (or counter-suggestions) from @tedbow and/or @rkoller before implementing.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented

#7 looks good to me

Theresa.Grannum’s picture

Theresa.Grannum
She/Her
commented
Assigned: Unassigned » Theresa.Grannum

Theresa.Grannum opened merge request !333

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

Some implementation guidance for @Theresa.Grannum:

As an example of what we want, see this part of UpdateReady.php:

    $form['backup'] = [
      '#prefix' => '<strong>',
      '#markup' => $this->t('Back up your database and site before you continue. <a href=":backup_url">Learn how</a>.', [':backup_url' => 'https://www.drupal.org/node/22281']),
      '#suffix' => '</strong>',
    ];

What this is doing is adding a little bit of arbitrary text and HTML to the form. That's all we want to do here.

In the case of UpdateReady.php, there is already text in place; we just need to change it to what I wrote in #7 for UpdateReady.php. You'll only need to modify the #markup property. Pretty much a one-line change.

In UpdaterForm.php, you'll need to add a new element to the form, but it has the same structure as the snippet I pasted above. In fact, it's even simpler -- in UpdaterForm.php's version of this, you can remove the #prefix and #suffix properties. (And obviously use the text from #7 that I specified for UpdaterForm.php, since we don't want it to say the same thing as UpdateReady.php does.) As for where to put it, I'd say add the element just below the list of projects to updated. What that looks like, in \Drupal\automatic_updates\Form\UpdaterForm::buildForm() (the only method you need to change):

$form['projects'] = [
  // a long and complex nested array is here, ignore it
];
// Add the new element here
Theresa.Grannum’s picture

Theresa.Grannum
She/Her
commented
Status: Active » Needs review
phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Status: Needs review » Reviewed & tested by the community
StatusFileSize
new 3239759-13-before.png62.44 KB

I love it. Screenshot:

A reminder to back up the database, before starting an update

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Status: Reviewed & tested by the community » Fixed

Thanks @Theresa.Grannum 🥳

rkoller’s picture

rkoller
he/him
Primary language German
Location Nürnberg, Germany
commented

I have applied the latest patch and have taken a look at the micro copy in the context of admin/reports/updates/automatic-update and admin/automatic-update-ready/. I like and agree that you have added texts on both pages" I would have a few additional points and thoughts to add.

1. I am not sure if starting off by providing a gently and friendly reminder saying, it is a good idea to back up your database, and then in the next step state in bold letters, that it is strongly recommended to back up the database and site, isn't a bit of mixed messaging. I would rather go with an explicit and clear statement on the automatic-update page that it is highly recommended to back up the database and site and then phrase the ready to update text more as the friendly reminder by stating that the downloaded assets will be applied next and that this step cannot be undone, the reason why an update is a good idea. Just provide clear and actionable steps what is recommended in the first place. Currently it sounds more like an update might be a good idea but isn't necessary and then you read on the ready to update page it is recommended after all. So a more explicit variant for the automatic-update page could be:
It is strongly recommended to back up your database and site before you begin.
(*maybe that sentence in bold on the automatic-update page?)

2. On the automatic-update page you have "back up your database" on the ready to update page you have "back up your database and site". It is advisable to be consistent with the actionable recommendation imho. Currently if someone is following the recommendation on the first page and just backs up the database could be puzzled when retrying and then reading on the ready to update page that database AND site should be updated now. Might be even considered annoying for some people. I would suggest to go with the link text "backup your database and site" on both pages.

3. One question that is probably still valid from #4. If an update is triggered manually there is the recommendation to back up the database and site while when the update is triggered and run automatically via cron there is no recommendation. Manually you get the strong recommendation to back up in the micro copy while when run automatically there is no notification for that? That "might" cause also uncertainty once someone triggers a manual update?

4. On the ready to update page you have the first line "Drupal core will be updated to 9.3.15" in a regular weight while the next line is bold. The sole focus is on the bold typeface (at least for me the "Drupal core will be updated part..." was more or less "invisible" or at least unnoticed that way) . I would perhaps make the whole block in a regular typeface and phrase the back up your database part a little bit different. Not that strongly but explaining the reasoning a little bit. I've added the word step to "this cannot be undone. At the end i would provide a brief note about what happens when you hit the cancel update button, stating that the downloaded assets get removed (aka they have to be re-downloaded if the user triggers the update process again):

Drupal core will be updated to 9.3.15. This step cannot be undone. The reason why to back up your database and site before the update was recommended in the first place. If you cancel the update process the downloaded assets get removed.

5. I could offer to put the issue on fridays ux meeting agenda (there is no entry yet - https://www.drupal.org/project/drupal/issues/3284204). There would be a few more pair of eyes to take a look at the issue and the word smithing part in particular. But i don't know how time sensitive the issue is since it is a stable blocker. But i think it would be a good choice.
And if i remember correctly Aaron also suggested a few weeks back in one automatic update issue to bring the automatic updates module in general to one of the ux meetings so that we could take a look as a group.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.