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.
Here is a way to set the site offline with a customized message to everyone visiting it. The administrator, user 1, is always allowed to access the site so he can do whatever he wants, while everyone else is not.
There is currently one drawback to this patch: You can lock yourself out of your own site! If you are logged in as admin and turn this setting ON, you will be fine. However, if you log off, you will NOT be able to login back.
The workaround for this is easy: in settings.php, you can have the following to override whatever is in the admin menus.
$conf = array(
'site_offline' => 0
);
Comment | File | Size | Author |
---|---|---|---|
#32 | user-login-broken.patch | 637 bytes | kbahey |
#29 | site-offline-new-form-api.patch | 4.21 KB | kbahey |
#25 | site_offline_5.patch | 3.9 KB | kbahey |
#15 | site_offline_4.patch | 3.9 KB | kbahey |
#10 | site_offline_3.patch | 3.91 KB | kbahey |
Comments
Comment #1
kbahey CreditAttribution: kbahey commentedModified to make it a 503 service unavailable, so that it does not get indexed by search engines.
Thanks for Gabor Hojtsy for the hint.
Comment #2
factoryjoe CreditAttribution: factoryjoe commentedFor all those naysayers who think this feature doesn't deserve to be exposed in a popular community platform. Consider Flickr's approach. Oh yes, I want this too (see attached).
Comment #3
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedChris: I've absolutely no idea what this screen is trying to tell me...
Comment #4
kbahey CreditAttribution: kbahey commentedJust a little bit of background.
This feature has come up before the recent discussion in the drupal-devel, for example, displaying a friendly site down message and still use the site.
Up until now, I used a crude solution for this, but this warrants a "proper" Drupal solution.
Comment #5
Jeremy CreditAttribution: Jeremy commentedI applied the patch and verified it works as promised. I like the idea very much. But a few things:
Minor things: "Site Maintenance" should be "Site maintenance" and "Site Status" should be "Site status" to match everything else on the settings page.
Usibility issue: Here's a problem I ran into, granted it was a user error:
1) logged in as user #1
2) set "Site Status" to "Offline" and configured a custom message
3) I navigated around as user #1 and verified the site still worked for me
4) I logged out and verified as a non-administrator I saw the error I configured
5) Now I'm stuck: I can't log back in to put the site back online. Unless I happen to have direct database access (to delete the 'site_offline' row from the variables table, and to flush the cache), the site is going to stay offline.
Feature request: Why tie this to user #1? Couldn't it be tied to a permission instead? If a non-user#1 can enable this mode (they can), then a non-user#1 should also be able to maintain the site when in maintenance mode.
Comment #6
drummI think it would be a good idea to make this an optional replacement for the friendly database error screens as a way of optionally protecting database login information. This means that all the data would have to be stored in settings.php since the database might not be accessible.
Comment #7
kbahey CreditAttribution: kbahey commentedImplemented suggestions by Jeremy. Wording has been changed, and all user account with "administer site settings" will be allowed to see everything in the site.
As for logging out locking you out, the solution is to change settings.php as described at the top of this issue.
Comment #8
kbahey CreditAttribution: kbahey commentedMust use correct theme page.
Here is the correct patch.
Comment #9
Jeremy CreditAttribution: Jeremy commentedLooks good, a few final picky comments...
It might be good to expand the text on the settings page to reflect the fact that site administrators can still access the site. For example, maybe change "This allows you to take the site offline for maintenance." to something like:
"When set to 'Online', all visitors will be able to browse your site normally. When set to 'Offline', only users with 'administer site configuration' permission will be able to access your site to perform maintenance, all other visitors will see the site offline message configured below."
Also you have a typo in the default message:
"Out" should be "Our". Better yet, replace the sentence with something like:
t('%site is currently under maintenance. We should be back shortly. Thank you for your patience.', array('%site' => variable_get('site_name', 'This site')));
That seems like an accident waiting to happen. Why not allow access the the login page? I'd even go so far as to provide a link on the front page that says something like "Site administrators can log in here." Anyone else that tries to login will just get the offline message. Changing settings.php is not always an easy thing to do, depending on your hosting situation.
Comment #10
kbahey CreditAttribution: kbahey commentedJeremy
All of your suggestions are addressed now in this patch.
The admin is not locked out of his own site. If he visits user/login, he will be back in.
Comment #11
Tobias Maier CreditAttribution: Tobias Maier commented+1 for this patch (untested because tired)
maybe a just stupid question of i tired man:
when someone wants to access the update.php, xmlrpc.php or the cron.php (site is under maintance user has not "administer site settings")
is he also looked out and gets the same message there (or will be referred to index.php)?
is this necessary?
cu tobias
Comment #12
Jeremy CreditAttribution: Jeremy commentedAlmost, however you replaced the wrong comment on the settings page. ;) The "Site offline message" box has the new help text that was intended for the "Site status" setting.
Otherwise, it works like a charm. I hope to see it merged.
Comment #13
bhagman CreditAttribution: bhagman commentedJust out of curiosity, why not create an access privilege for administering the site (during downtime)?
e.g. "Offline Access"
Then you can have multiple site maintainers.
Comment #14
kbahey CreditAttribution: kbahey commentedFixed the help text to go to the relevant field.
Comment #15
kbahey CreditAttribution: kbahey commentedHere is the patch.
bhagman: You can have multiple maintainers now by defining a new role (e.g. admin) and assigning it the "administer blah" settings.
Comment #16
bhagman CreditAttribution: bhagman commentedwow, I see it now, back at #7
I must be really tired.
Well done kbahey!
Comment #17
kbahey CreditAttribution: kbahey commentedI guess all the concerns are addressed, so settings this to ready for commit.
Any other issues?
Comment #18
chx CreditAttribution: chx commentedA separate function? Three IFs? You are paying for ANDs or what :)?
Comment #19
kbahey CreditAttribution: kbahey commentedNo, I think ANDs are still free here in Canada.
However, the code is clearer and more readable this way, and hence more maintainable.
I don't think there is much of a performance penalty, since site_offline being set is a rare occasion compared to it being not set, and hence we bail out early from the function and proceed normally (hence only one if in most cases).
Also, I orderd the if by decreasing likeliness, the second one is for users with admin privileges, and normally there are only a few of those compared to others (anonymous and authenticated).
Comment #20
chx CreditAttribution: chx commentedHint: PHP if is greedy. Therefore, you do not execute most of that if in most cases, too.
Comment #21
kbahey CreditAttribution: kbahey commentedHere is a benchmark I did on my test machine, which is a Pentium III 550 MHz, 630MB RAM, Linux 2.6.x kernel, Apache 2, MySQL 4.1.11. Not much else running.
Before each test, I shutdown MySQL and Apache and restarted them, so that MySQL caching does not play a role in skewing the results.
As you can see the results are comparable (2 ms slowness worst case).
So, the patch is ready to go since it does not impact performance.
Command is: ab -n 100 http://test.example.com/
Comment #22
chx CreditAttribution: chx commentedI just found the code too long. Really not performance issue :( tried to talk with you on irc :(
Comment #23
Dries CreditAttribution: Dries commented- 'Site Offline' should be 'Site offline'.
- variable_get('site_name', 'This site') is not consistent.
Otherwise looks good.
Comment #24
Jeremy CreditAttribution: Jeremy commented> variable_get('site_name', 'This site') is not consistent.
Not consistent with what? There are 18 occurences of site_name in the modules directory. They default to the following values:
- "Drupal", 1 occurence, aggregator.module
- "drupal", 10 occurences, multiple modules
- "this web site", 1 occurence, drupal.module
- "this website", 1 occurence, user.module
- "''", 2 occurences, drupal.module and ping.module
- "0", 1 occurence, ping.module
- "local", 2 occurences, user.module
It seems the default for site_name is whatever makes sense in the current context. What do you recommend instead? Just over half of the time the default is 'drupal', but if that is used then the default error will be "drupal is currently under maintenance. We should be back shortly. Thank you for your patience." How is that better than "This site is currently under maintenance. We should be back shortly. Thank you for your patience."?
Comment #25
kbahey CreditAttribution: kbahey commented- Changed "Offline" to "offline"
- Rerolled for current offset
Otherwise, the "This site" is no more inconsistent than other cases that Jeremy has pointed out. Making it "drupal" is not a good idea. Perhaps all the instances should be standardized on some wording, but that is not related to this issue.
Hope it gets committed.
Comment #26
Dries CreditAttribution: Dries commentedI was under the impression that we always used 'drupal'.
The 'This site' can't be translated ... so it's still buggy.
Comment #27
Tobias Maier CreditAttribution: Tobias Maier commentedmaybe we should say that this should everytime be "Drupal website" because drupal alone is a little bit less
Comment #28
shouchen CreditAttribution: shouchen commentedPerhaps the web site admin could specify the text of the message in a setting somewhere. That would be my preference, anyway.
Comment #29
kbahey CreditAttribution: kbahey commentedHere is the patch with a t()'d string.
It was also updated for using the new form API.
Comment #30
kbahey CreditAttribution: kbahey commented@shouchen: it is already configurable the way you want it to.
Comment #31
Dries CreditAttribution: Dries commentedCommitted. Thanks.
Comment #32
kbahey CreditAttribution: kbahey commentedDries,
Regarding user/login not working. I think that form is broken because of the new Form API patch from yesterday.
Here is a patch that provides a workaround (just used "user" instead of "user/login").
Comment #33
Dries CreditAttribution: Dries commentedNot sure I want people to browse or edit user profiles while performing site maintenance.
Comment #34
kbahey CreditAttribution: kbahey commentedThis will not allow them to edit, nor browse other user's profile.
At worst, it wll allow them to see their own user profile.
I think the real solution is to restore user/login though, since that will be the only form that works while the site is offline. I am not sure what is wrong with it though. Did the Form API patch break it?
Comment #35
gtcaz CreditAttribution: gtcaz commentedWith the latest CVS, if you move to a new broweser, the user/login page shows up, but you can't do anything. So, in this case, you're still locked out even though you can access the login page.
Comment #36
kbahey CreditAttribution: kbahey commentedYes, this is a bug in CVS it seems.
After you apply the patch in #29, apply this patch.
Comment #37
Dries CreditAttribution: Dries commentedkbahey: #29 has been applied, not?
Comment #38
kbahey CreditAttribution: kbahey commentedYes, it was applied in #31.
THe reason this is open is that ?q=user/login is not working with HEAD. It gives a page that is missing the sidebars, and the login tab has nothing under it.
I think all this is because of the new Form API patch.
When it is fixed, we can close this one I guess.
Comment #39
kbahey CreditAttribution: kbahey commentedDries commited the change of "user/login" to "user" and that takes care of the problem.
See details here http://drupal.org/node/35410
Comment #40
(not verified) CreditAttribution: commentedComment #41
abelleba CreditAttribution: abelleba commentedThanks for the post, got my butt out of Maintence Mode finally!
Regards,
Andy Belleba
http://tools.mywikiinfo.com
Comment #42
trimex CreditAttribution: trimex commented