smd_at_work: click to put your site in maintenance mode

Bloke · 2014-10-21 15:26:30

For aeons, the go-to plugin for me during site development and upgrades has been rvm_maintenance. The only issue with it is that it’s not optimal in plugin cache directory installations of Textpattern, because plugins in the cache directory are “always on”, thus your site would always be in maintenance mode. Adding and removing the plugin file itself is a workaround, but I wanted something a bit simpler to control from the admin-side.

Enter smd_at_work.

With this plugin installed, either in the cache folder or as a regular plugin in the database, you can visit the Admin->Preferences->Advanced panel and toggle your site in and out of maintenance mode via a pref. You can configure the message to display to visitors, or simply write your own error_503 Page template which will be delivered instead.

All the time the site is in maintenance mode you will also see a reminder at the bottom of the screen informing you of the fact. Very handy to help you remember to switch it off after you’re done!

The behind-the-scenes magic is stolen directly from rvm_maintenance, so huge thanks to Ruud for writing the tiny original plugin. This just builds on his stellar work and exposes the process to the admin interface. Thanks also to mrdale for pushing me to write this in the first place.

Hope it proves useful. Any issues, please jot them in this thread. Happy maintenance.

Last edited by Bloke (2017-03-27 22:39:13)

candyman · 2014-10-21 20:15:53

Thanks Stef once again for your precious efforts.

Didn’t know about the cache directory effect. Do you know other plugins that are using it?

Last edited by candyman (2014-10-21 20:45:45)

Bloke · 2014-10-21 20:55:36

candyman wrote #285023:

Didn’t know about the cache directory effect. What plugins you know are using it?

Any plugin can be loaded either from the database, or from a full plugin template file in a nominated cache directory (preferably outside of your site’s docroot). Just set that directory in your advanced prefs and stick some template formatted plugins in there.

Template plugins are just plugins that have not been compiled into the usual .txt format that most people are used to. ied_plugin_composer can export such files via its Save as abc_plugin_name.php feature, ready for dropping into the cache directory.

While it’s a handy feature, there are some things to be aware of:

It’s not recommended for production use, although as long as you trust the plugins it’s not much more of a security risk than eval()ing the plugins anyway, which is what happens to the ones from the database.
There are no install/enable/disable/delete lifecycle events fired by cache directory plugins. A lot of plugins rely on regular installation into the DB to trigger new tables or prefs to be created, and likewise to tidy up after themselves when deleted. Without this, some plugins won’t run or will misbehave. I sometimes include fallbacks for cache directory plugins — this plugin does, for example — so it can be installed in either location (hmm, although I’m not sure about the Textpack, I’d best check). I know Adi does the same with some of his recent plugins. There are other people who do likewise.
The plugins cannot be disabled, unless you remove them from the cache directory. Or rename them to something other than .php.

For reference, ied_plugin_composer has a facility where you can automatically or manually trigger lifecycle events, either on installation or afterwards. So if you do install a plugin in the cache directory and it needs this step, you can use the plugin composer to kickstart it. The composer can also install Textpack strings from cache plugins if they’re not automatically installed. It’s very handy as a companion to plugin cache installations… and can be installed in the cache directory itself :-)

jakob · 2014-10-21 21:35:12

Hi Stef,

Sounds great! Just for info, the elusive Jukka also has rah_maintenance hidden away in his github treasure trove. Yours goes a step further with the public notice for the admin, and that is a great idea as it’s so easy to forget that maintenance mode is on if you are signed in.

I like to include a maintenance mode on/off button on the admin dashboard, along with a notice if maintenance mode is active – courtesy of your smd_tabber plugin. If it helps anyone, this is the code I used for rah_maintenance:

<txp:php>
    global $variable, $txp_user; 
    $variable['logged-in-user'] = htmlspecialchars($txp_user);

		$maintenance_mode = gps('maintenance_mode');

		if ($maintenance_mode != '') {
		  $change = ($maintenance_mode == "on") ? 1 : 0;

 		// rah_maintenance update (pref status on/off)
  		safe_update(
  			"txp_prefs",
  			"val = '".$change."'",
  			"name = 'rah_maintenance_active'"
  		);

  		$variable['maintenance_mode'] = ($change == 1) ? 'on' : 'off';
    } else {

      // rah_maintenance – get pref status
      $variable['maintenance_mode'] = get_pref('rah_maintenance_active') ? 'on' : 'off';

    }
</txp:php>

For those using rvm_maintenance replace the rah_maintenance lines with these:

  		// rvm_maintenance update (plugin status on/off)
  		safe_update('txp_plugin', "status = $change", "name = 'rvm_maintenance'");
...
      // rvm_maintenance – is plugin installed (i.e. does the function exist) or not
      $variable['maintenance_mode'] = function_exists('rvm_maintenance') ? 'on' : 'off';

Then further down in the smd_tabber page template I have something like this:

<div id="welcome">

  <txp:if_variable name="maintenance_mode" value="on">
    <div id="notice">
      The site is in maintenance mode. <a href="?maintenance_mode=off">De-activate</a> to make the site publicly viewable.
    </div>
  </txp:if_variable>

  <div class="salutation">
    <h1>Hello <txp:rah_repeat limit="1" delimiter=" " value='<txp:rah_function call="get_author_name"><txp:variable name="logged-in-user" /></txp:rah_function>'><txp:rah_repeat_value /></txp:rah_repeat> and welcome!</h1>
    <txp:if_variable name="maintenance_mode" value="off">
      <a class="maintenance_mode_switch" href="?maintenance_mode=on">Switch on maintenance mode</a>
    </txp:if_variable>
  </div>

</div>

the rah_repeat stuff is not strictly necessary, it just says hello with the first name only.

I expect this can easily be adapted for use with your new plugin.

Bloke · 2014-10-21 21:56:55

jakob wrote #285026:

it’s so easy to forget that maintenance mode is on if you are signed in.

Hehe, tell me about it! That’s primarily what spawned the plugin. The rest, as you say, has been done before, better.

And thanks for the dashboard code tip. Handy. I could add a conditional tag to the plugin to test if maintenance mode is active or not. Maybe even a tag to set the state, given sufficient privileges, which would mean less faffing with database calls.

If that was available you may be able do away with at least one hunk of PHP and use just a few lines to wire up the gps stuff. Would that be useful to you?

Bloke · 2014-10-22 00:10:03

Just toying with a couple of public tags. So far, the following code pretty much does what jakob posted above, just without any PHP:

<txp:adi_gps name="maintenance" quiet="1" />

<txp:if_variable name="maintenance" value="">
<txp:else />
   <txp:smd_at_work_status />
</txp:if_variable>

<txp:smd_if_at_work>
   Maintenance Mode is on! <a href="?event=dashboard&maintenance=1">Make site live</a>.
<txp:else />
   Website is live! <a href="?event=dashboard&maintenance=1">Put it in Maintenance Mode</a>.
</txp:smd_if_at_work>

Alternatively:

<txp:adi_gps name="maintenance" quiet="1" />

<txp:hide>Can't use txp:else, since that would trigger for any
value or non-value</txp:hide>
<txp:if_variable name="maintenance" value="on">
   <txp:smd_at_work_status status="1" />
</txp:if_variable>
<txp:if_variable name="maintenance" value="off">
   <txp:smd_at_work_status status="0" />
</txp:if_variable>

<txp:smd_if_at_work>
   Maintenance Mode is on! <a href="?event=dashboard&maintenance=off">Make site live</a>.
<txp:else />
   Website is live! <a href="?event=dashboard&maintenance=on">Put it in Maintenance Mode</a>.
</txp:smd_if_at_work>

The <txp:smd_at_work_status /> tag toggles the maintenance status if not given any attributes. Alternatively, its status attribute can be given a boolean to explicitly set a particular state. I shied away from using the value of zero in the second example above due to the outside chance that if_variable or adi_gps treat it as empty. In the first example, it didn’t matter what the value was, since we were toggling if the variable existed.

As I mentioned above, the <txp:smd_at_work_status> tag only does a rudimentary check that the person calling the tag is logged in. So I’d be tempted to wrap the code in rvm_privileged with an explicit level to avoid any user being able to tinker. But that’s application logic, not plugin logic.

I’ll commit this to the next development version on Github. If anyone fancies trying it out and could report on its success or otherwise, or perhaps suggest better tag names/attributes or something then please throw your thoughts here.

jakob · 2014-10-22 09:20:01

Brilliant! That looks like a much better solution. I’ll give it a go as soon I can…

Bloke · 2016-09-11 23:33:26

v0.20 is out, which is solely for Txp 4.6.0 and higher. It will not work on earlier versions. I didn’t ever get round to releasing v0.11, so this release combines those unreleased changes and the 4.6.0 stuff.

The plugin now has two public tags that you can use to test and/or toggle the maintenance mode (providing you have enough privileges) which means you can offer this functionality to all logged-in-users, or a subset if you employ rvm_privileged or smd_user_manager. This also gives you the ability to offer a quick toggle feature for users of dashboards.

Hopefully it’ll prove useful, especially to people who run plugins from cache.

bici · 2016-09-12 00:28:01

thanks. in play

Bloke · 2016-09-13 23:29:10

Ooops, v0.21 fixes missing tag registration for 4.6.0.

mrdale · 2016-10-14 05:08:10

So, this is not a bug but rather a feature not yet added.

I was using attempting to use adi_gps to extract urlvars into txp_variables on a 301 page that gets redirected to by this fine plugin.

Dumbfounded by my neanderthal inability to extract and manipulate variables on that page, I eventually realized that the urlvas did not survive their redirect journey.

Is the idea of passing urlvars through the smd_at_work wormhole even possible? what would happen? would they turn into some form of outrageously elongated pasta?

Bloke · 2016-10-14 08:02:36

mrdale wrote #302167:

on a 301 page that gets redirected to by this fine plugin.

How did you get the plugin to throw a 301? It’s supposed to only throw 503s. The only way to throw custom responses is to intercept the txp_die callback at the moment.

That said, if I exposed a pref that allows you to specify which status code to throw — default 503 — I could repurpose the message field to be a destination URL (or add a new pref or something). The destination URL pref would only work with statuses (status? stati?) 301, 302, 303, 307 though. That any use to ya?

Textpattern CMS

Textpattern CMS support forum

#1 2014-10-21 15:26:30