Question

Don't need to do this right now but thinking about the future...

What would be your method to take a website "offline" for a little bit through a custom coded cms? Meaning give the capability for an admin to login into an admin panel, type a message into a box, and submit the form. That message would then display rather than any other page to any user, unless the user is an admin.

I have done this before and used a if xml file exists then load the content from the xml file and puts a construction background behind the message with a login box that only allows admins to log in. When the admin would type the message into the box it stored the text into the xml. When they brought the site "back to life" it would simply delete the xml file.

The only problem was that once the site grew, it took more hits and checking for a file exists every page load was becoming slow. Anyone have a better solution for me?

Thanks.

Was it helpful?

Solution

Assuming this is on Apache.

If at all possible, I'd recommend doing this using a .htaccess file that re-routes all requests to a "site is down" message.

Something like:

RewriteRule (.*) /downmessage.php [L]

(note that any image resources will be redirected, too)

Compared to a PHP-side flag check and offline message, this is faster, plus it has the huge advantage that resources like uploaded images and style sheets are no longer reachable either - which they otherwise might be, through cached files, URLs, Google Images hits...

In a PHP-based "offline" mechanism where those resources are not blocked, the fact that some resources are still reachable if somebody knows the URL is very difficult to explain to users ("but we took the site down, didn't we?") and if the site gets taken down because of legal problems regarding a published image (can happen to everyone!), the image could still be reachable without the site owner knowing.

The downside to this is that it requires the mod_rewrite module on the server, and PHP needs to have write access to the .htaccess file: Both not always the case.

However, while this method has its advantages, the basic premise of your question is worth looking at before implementing any changes. You say that the check for the takedown XML file is taking too much time. I don't think that is the case. file_exists() checks are cached internally, and should not cause any noticeable slowdown even for very many requests. The average Drupal or WordPress page loads dozens of include files on every request. A single file_exists pales in comparison.

OTHER TIPS

Just an idea:

You can set a flag in your database handler (e.g. maintenance = TRUE) then you can control which database queries are permitted or not. Most of the cases you'll only want to permit reading the database while your site under maintenance.

Note: This will work only if all of your database requests are under control.

The easiest way is to check for a (local) file's existence (optionally output its contents, like /etc/nologin) . If Ops want to take the site down, they can create it independently on each web server.

Do this in some common code which is executed on every page before you try to access the database.

The reason for doing this is that Ops may want to take the database(s) offline during the maintenance period, so you can't store this in the database.

Checking for the existence of a local file is a very low overhead operation which won't impact the performance of the normal case very much.

Maybe a possibility for you would be to set an APC value. As these are stored in memory it would be lightning fast. But don't forget that APC values will not persist over a server restart. So if you need a "maintainance mode" over a very long period of time, you should instead store the value in a database.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top