Unable to put site in maintenance mode when backing up

[argiepiano]

When BM was ported, the lines variable_get('maintenance_mode') and variable_set('maintenance_mode', 1) were ported as a config setting within backup_migrate.settings (!!!). This setting, of course, doesn't work. The result is that BM is unable to put the site in maintenance mode when backing up.

[argiepiano]

The PR is ready for testing if anyone could. Testing is a bit tricky, as you need to find one process that takes a long time so that you can see that the site is indeed put in maintenance mode. For example, testing this with a real site with lots of nodes and fields.

If you are thinking that "Backup my entire site" will provide an opportunity to test this (since it takes a long time), unfortunately it won't. There seems to be a different bug both in D7 and Backdrop, where the site is only put on maintenance during the first process (DB backup) and not the second (compressing the files), which takes a long time. This should be addressed on a different issue.

So, this is the behavior both when backing up and restoring:

• If the site is not on maintenance, it's only put in maintenance if you modify the default profile and choose "Take site offline" in the Advanced fieldset.
• When the above happens, the standard maintenance mode message in the site is replaced by the "Site off-line message" in that same Advanced tab.
• The site will be put back in normal mode after the backup. If you are restoring, and the backed-up DB was in maintenance mode, the site will be forced back to "normal" mode after restoring. And the standard maintenance message will be restored to its original one that was present before starting the process.

If the site was in maintenance mode before backing up or restoring, the site will be left in maintenance mode when completing those.

[indigoxela]

Wow, I couldn't think of a way to test that.

[argiepiano]

Thanks, @indigoxela. Did you have a chance to test? @cellear, would you have the time to test this too?

[indigoxela]

Did you have a chance to test?

Unfortunately no. The PR makes sense, but I'm not able to test.

[cellear]

Thanks, @indigoxela. Did you have a chance to test? @cellear, would you have the time to test this too?

I have the time, and I'm planning to catch up on backlog this weekend, but I too have not thought of a way to test this until the other bug mentioned (that it doesn't stay in maintenance mode during compression) is also addressed.

[izmeez]

Ok, I applied the patch to the current 1.x-1.x download. Because of hunk 1 issue I applied the patch manually and created a new patch. I applied the patch and changed the default profile to take site offline and this is what I get:

Is that proof enough?

[izmeez]

I am also unable to add any labels to the issue.

[izmeez]

Like others have said the code looks good. I'd say this is RTBC x 1.