Log "backup restored" to watchdog after restore finished

Added status message to Drupal log:

Restore completed using {backup_name} from {backup_location} into {destination} at {time}.

Thanks @tamerzg - I added two comments. LGTM at all. Could you explain your choices?

@Anybody thanks for the review. I replied inside PR.

Thanks, moving both into the t() is just what I expected. Perfect! :)

@Anybody I just updated PR, now $message string is built dynamically so we don't mix it with context variable. Please note that $message is not wrapped in t() as it shouldn't be, log messages are translated on display, but they are always stored in english/system language.

I personally don't really like this cluttered text approach, but other maintainers may see it different. Let's wait for further feedback.

OK, I think this needs further work.

I agree with @Anybody. Not really a fan of the concatenated string approach. Furthermore, the log message text doesn't display the correct parameters.
For the test, I made a backup of my site using the backup_migrate module and saved the backup in my private files directory. Afterwards I used the "Restore" option.

This is my file dir / name : files/private/backup_migrate/backup-2023-02-13T10-35-05.mysql.gz

And this is the log message result:

Restore completed using backup_migrate_restore_upload from Upload into Default Drupal Database at Monday, February 13, 2023 - 10:37

Not really the expected outcome, but fairly close! :)

Update: The incorrect message only appears when restoring a backup using the "BackupMigrateRestoreForm" ("/admin/config/development/backup_migrate/restore" => the one with the file upload field). But the message appears correct, when restoring through the "BackupRestoreForm" ("/admin/config/development/backup_migrate/backups").

The reason behind this is, that inside "BackupMigrateRestoreForm", "backup_migrate_perform_restore()" is called with hardcoded parameters for correct file usage of the file uploaded in the file upload field.

Since this is working flawless for the "BackupRestoreForm":

Restore completed using backup-2023-02-13T10-35-05.mysql.gz from Private Files Directory into Default Drupal Database at Monday, February 13, 2023 - 11:01.

And we can not easily get file and destination IDs through the "BackupMigrateRestoreForm" without heavy refactoring, I suggest, we either display a static log message, keep it as is or remove the logging if the restoration was performed through the "BackupMigrateRestoreForm".

Any other ideas or an easy fix for this problem are also welcome! :)

The above MR is applied successfully for Backup and Migrate v5.1.x-dev.
Attaching the screenshot for reference.

Review Step

• Setup Drupal 10.x with Backup and Migrate Module - 5.1.x-dev
• Apply MR
• Go to Administration > Configuration > Development > Backup and Migrate > Restore (Tab) > Restore now
• After Go to Administration > Reports > Recent log messages > Backup and Migrate > Check backup_migrate Type log.

The Backup is still not added in the log message as was suggested by @Anybody in #2.
Review it too and let know if that is required.

Using Backup and Migrate to restore a file (related to issue https://www.drupal.org/project/backup_migrate/issues/3264580 🐛 MySQL collation complexities leads to backup incompatibilities Active ), I expected to see a confirmation message.

I did not see any message on the screen.

In searching for another confirmation I looked at the watchdog and I did not see any entry related to restore or any Backup and Migrate entries.

The only way I was able to confirm that the Backup and Migrated did the restore successfully was to look at the content and check for recent changes.

Tested this MR for 5.1.x and I can see the confirmation message after I restored an old backup, can be moved to RTBC.