Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Steps to reproduce:
- Place site in maintenance mode
- In admin/reports/updates/install, install a new module remotely, say http://ftp.drupal.org/files/projects/date-7.x-1.x-dev.tar.gz. (Install method was local file transfer).
- Site is taken out of maintenance mode. "Installation was completed successfully. Your site has been taken out of maintenance mode."
I would have expected the site to stay in maintenance mode.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 976328-5.update-manager-only-online-if-it-started-that-way.patch | 3.94 KB | dww |
| #2 | 976328-2.patch | 3.61 KB | bfroehle |
Comments
Comment #1
dwwUgh, this was already reported at both #538660-154: Move update manager upgrade process into new authorize.php file (and make it actually work) and #606190: Fix handling of database schema updates in update manager workflow but was lost in the shuffle of both of the other issues. :( So yeah, let's leave this as a separate issue specifically about maintenance mode so it doesn't get lost this time.
However, before we go changing the workflow too much, we need to get some usability reviews in here.
p.s. I know it's confusing, but "update system" is for update.php and the DB update system. You're talking about the Update manager that checks for available updates to your modules and themes (and can install them for you in D7), which is provided by the "update.module"...
Comment #2
bfroehle commentedI've implemented something similar to the update.php script which does the following:
Store maintenance mode status in
$_SESSION['maintenance_mode']. At the end of the update, if we're offline but the previous status stored in$_SESSION['maintenance_mode']was online, put the site back online.Comment #3
bfroehle commentedOops, setting to Needs Review to trigger the bot.
Comment #4
dwwUgh, sorry I didn't have a chance to review this sooner. :( Hate to do this, but this has a code style bug. I'll quickly re-roll and test now.
Comment #5
dwwOkay, this fixes the code style bug. Tested manually, and the patch does what it says. I still think it's stupid to take the site online and then send people to update.php which then suggests the admin go take the site offline again. :( But, I don't think we can make a change that big at this point. We *desperately* need better integration between authorize.php and update.php, but that's obviously for D8 at this point.
But, this is a pretty major bug. If you start the whole update process with your site offline, we currently automatically put it back online right when you don't want it online. That sucks. This fixes it. Let's get this in for D7.
Oh, and I was wrong about the string freeze. We're not changing any strings at all here, I just misread earlier.
Comment #6
bfroehle commentedAgreed.
Comment #7
dww@bfroehle: Meanwhile, can you review/test and ideally RTBC either/both of these? ;)
#997802-12: Update manager doesn't allow you to install a project if it finds a single "broken" module in it
#1010506-8: FileTransfer doesn't properly handle any advanced settings nor the ssh username
Thanks!
Comment #9
bfroehle commented#5: 976328-5.update-manager-only-online-if-it-started-that-way.patch queued for re-testing.
Hmm.. We're failing from
SQLSTATE[08004] [1040] Too many connectionsin
on test client #32.
Comment #10
dwwBot's happy again...
Comment #11
webchickYikes! That's a pretty nasty problem. :\ Thanks for coming up with a non-string-freeze-breaking-fix. Yay. :)
Committed to HEAD. Thanks!