Every time I migrate a site (which seems to happen about once a month on average...) I find myself in a bit of a debate: I don't want to put the site into maintenance mode because I want people to be able to view the site, but I do want to prevent users from creating new content that would get lost in the migration. Ideally you can cut this period down to a half hour or so through the use of short DNS "time to live" values, but there is also some amount of time where you have this problem.
I'm thinking of creating a helper module for this situation that would provide the following features:
-
A new permission for "Log in to site" - since permissions require a valid user object that is only populated after the log in this would be evaluated just after a user logs in. If they don't have the permission, I would set a message (admin configurable) and redirect them to the "/logout" page.
-
A configurable message to show to users that would say something like "Hey, we're doing some maintenance now and have therefore restricted the ability to login to the site. Sorry!" This would warn users before they attempted to login so they know that they are probably wasting their time if they do it.
-
A button to clear out existing sessions that users have for roles which do not have the permission to login. The protection in item 1 is pretty useless if you don't also get rid of existing sessions.
So, does something like this exist?
If not, what to call it?
"maintenance_helper" seems a little long, though it is descriptive of the purpose. "login_permission" is more accurate but doesn't describe why you would want it (which is both good and bad, I guess).

Comments
+1
I always have this problem as well. Sounds like a good idea to me.
Caveats
I'd rather allow the user read access to the site during maintenance.
Obviously, having the database updated by regular traffic when you are running update.php will cause problems. At the very least locking can be delayed, or other unpredictable results.
To a lesser extent, reading from the database while it is being updated can cause issues as well.
Perhaps using something similar to boost or cache router with fscache would be better, to prevent database access while you are updating.
More to your proposal, we are still reading the database, and perhaps writing last access time or so as well. That may not be an issue most of the time, but if we update the users table or the sessions table (like what will happen from D6 to D7 because of the new password hash), we may be hitting the tables a lot on busy sites.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
different fits for different situations
There are two use cases here:
My main goal is to provide more control to the admin during scenario 1. It's possible that it could be useful for scenario 2 but that's not a goal.
A lot of the solutions you mentioned are reasonable and valuable to a site with large traffic and VPS or dedicated hardware. If a site is in that situation they can also use rsync for file transfer and set their DNS TTL so low that the total downtime in a data center migration would be maybe 15 minutes which is an acceptable downtime. That's not the intended audience for this module :)
The intended audience is folks on a shared server where FTP is the only method for accessing files and DNS TTL is not within their control and is limited to 24 hours. In those cases, a solution like boost/fscache/cacherouter is just too complex and unnecessary.
Regardless of whether or not there is a market or whether or not this module is suitable to a given situation, is there prior work somewhere that I should be focusing on instead of building form scratch?
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
Ah, got it.
That explained it.
In that case, this is what I do when moving hosts:
I put up a note that says the site is being moved, and if you see this message, the DNS has not propagated yet, AND disable new user logins, content creation, and commenting using access control. I don't put the site in maintenance mode when moving sites.
Then as people switch, they don't see the message on the new site.
But your solution is less work (less clicking), so go for it ...
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.