Automatic Maintenance Mode

Often, I create a development site, such as dev.example.com, test.example.com or staging.example.com, before making any change in the production site. I even have a dedicated server to host the dev site of all my clients. If you don’t have a development site on your own, please do create it. It’d save you a lot of time in the future. Your production site might become overnight success and you can’t afford to tryout important changes in the production site.

My ideal test site usually contains the following features…

  1. WP Toolbox to disable certain plugins automatically (such as sitemap / SEO related plugins)
  2. Automatic update system to update plugins, themes and WordPress core (including major versions)
  3. An external cron to trigger WP cron
  4. Discourage search engines to crawl and index the site

Even though, the above setup is solid enough, there are times, I wish I could not have this dev site to be viewable by others. For example, consider the following situations…

  1. When your client wants to test the beta version of upcoming WP core. And you install Beta Tester plugin and start to use the development version of WordPress, leaving the site vulnerable.
  2. When you or your client installs a plugin that becomes less secure. :)
  3. Somehow search engines start to crawl and index the dev site

To avoid all these issue, wouldn’t be nice to have a plugin that enables maintenance mode automatically, when you are away from the dev site for a pre-determined time?

auto-maintenance-mode
Image © morbark.com

My initial search in the WordPress plugin repo didn’t reveal anything similar. I was looking for the following features in it…

  1. Automatically enables the maintenance mode when there is no logged-in user/s in the site.
  2. When a user is logged-in and is doing some work, it should *not* show up the maintenance mode for non-logged-in users too, because I might want to test the site using certain tools such as Google PageSpeed Insights.
  3. Automatically disables the maintenance mode when a user access the site using a browser where the user has already logged-in.
  4. Automatically disables the maintenance mode when a user logs in.
  5. Automatically enables the maintenance mode itself when a user logs out of the site.

The last two points are already incorporated in the existing plugins, even though, there is a limitation in it too. For example, the existing plugins would make the site visible only on a browser where the user logged-in. It’d still show the maintenance mode, if the site is accessed using incognito mode (or using another browser). Basically, we can’t test the sites using tools such as Google PageSpeed Insights when the maintenance mode is on for non-logged-in users.

While this may seem a daunting task, the implementation is much simpler. Firstly, I forked Simple Maintenance plugin that fits my use-case. Whenever a user logs in or whenever a user accesses the site using the existing login, the plugin creates a transient (if it doesn’t exist already). If the transient exists, then the maintenance mode is disabled (automatically). If no logged-in user access the site for a pre-determined time, the transient gets expired automatically. So, when the transient doesn’t exist, the maintenance mode is turned on. If you look at the actual code, you’ll understand how easy it is to implement. So, here we go… Automatic Maintenance Mode for WordPress Development Sites.

What’s missing in it:

No plugin is perfect. This plugin is no different. For example, even if the maintenance mode is turned on, the site may still show up in the following scenarios…

  1. You use Varnish in front as the caching layer
  2. You use a full-page cache plugin (such as WP Super Cache) and its cache is not emptied after certain time (ex: when preload is enabled)

Basically, when the request doesn’t hit PHP and is served using a full page cache, then this plugin doesn’t work. I’ll probably improve it in the future to send a warning to the user that a full-page caching exists.

This plugin also doesn’t work, if (and only if) the transient doesn’t work for some reason. For example, in a client’s dev site, I kept object-cache.php for WP Object Cache that uses Redis backend. Unfortunately, it wasn’t available in that server. So, the plugin failed to set up a transient and started behaving like a traditional maintenance mode plugin. :)

Leave a Reply

Your email address will not be published. We use cookies to prevent spam comments. Required fields are marked *

css.php