Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
When doing restores again and again (for testing/dev purposes), it would help a lot to show when the restore / backup was successfull (current date & time) in the statusmessage.
So I can see when I last ran the backup, especially it takes a longer amount of time and I don't watch the process.
Steps to reproduce
Proposed resolution
Add date & time behind statusmessage on success.
Remaining tasks
* Remove the changes to the tests.
* Update the wording to say "Backup completed at []".
* Update the date output to use the system APIs so the date is in the correct format.
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | Message_Backup.png | 98.05 KB | andregp |
| #4 | Message_Restore.png | 124.17 KB | andregp |
| #3 | 3262070-3.patch | 1.25 KB | hmendes |
Issue fork backup_migrate-3262070
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:
- 3262070-show-date
changes, plain diff MR !19 - 3262070-show-date- changes, plain diff MR !18
1 hidden branch
Comments
Comment #2
AnybodyComment #3
hmendes CreditAttribution: hmendes at CI&T commentedSomething like this?
"Restore Complete at 02-03-2022 10:46"
The patch changes the message to be this way, but i can change it to another format as well...
Comment #4
andregp CreditAttribution: andregp at CI&T commentedHi @hmendes, your patch applies flawlessly and successfully update the "Restore Complete" message :)
But, the "Backup Complete" wasn't updated.
Also, I believe changing "Complete" to "Completed" since the addition of 'at' would be better.
Comment #5
DamienMcKennaThe test won't pass as the timestamp between when the backup starts and the test runs will be slightly different, so it'd be best to just check for the string without the timestamp.
Comment #6
DamienMcKennaI also think it should use the core APIs to use the correct timestamp format rather than hardcoding it to a specific format.
Comment #7
Anybody+1 for #6, thank you @Damien! And of course all who help here :)
Comment #8
Anybody@hmendes, would you like to do the final fixes mentioned in #6?
Comment #9
WagnerMelo CreditAttribution: WagnerMelo at CI&T commentedHi, i'll try solve the implementation mentioned at #6
Comment #12
WagnerMelo CreditAttribution: WagnerMelo at CI&T commentedHi, i made the changes that was requested by the maintainer, to implementing a Date API.
I tested the implementation change the timezone to aleatory timezones to see if the behavior was the expected, and it worked normaly.
And i create another branch cause i had some problems to make the merge request on the other branch, so i'll move this issue to needs review.
Comment #14
bruno.bicudoI'll review this one :)
Comment #15
bruno.bicudoI reviewed this one and it woks as described by @WagnerMelo on #12.
All tests passed and manual testing didn't return any errors too.
Moving to RTBC.
Comment #16
DamienMcKennaThis still needs to use the Drupal APIs to format the timestamp instead of hardcoding a format.
Comment #17
AnybodyI agree, here we go @Damien :)
I chose 'long' as I think all details are helpful.
Is 5.0.x still in active development or should this go into 5.1.x?
Comment #19
Grevil CreditAttribution: Grevil at DROWL.de commentedWorks as expected! I just added a small addition to change "complete" to "completed" as @andregp already suggested in #4.
I also found out, that the restoration message gets logged first, and then the restoration resets the recent log messages. I created a separate issue for this, since it is unrelated. #3305094: Log "backup restored" to watchdog after restore finished
Comment #21
DamienMcKennaGreat work! Thanks everyone.
Committed!