It’s really annoying to have someone say ‘your website is down’. And it’s also annoying to check the prices for monitoring services – especially when it only takes a few lines of code to monitor your site.

In fact, if you have PHP on your system, it’s exactly this amount of code:

<?php
  // monitor a site, write errors to a log....
  // copyright (c) 2005 D.Pankhurst (BigBizBlog.com)
  // free to use - just please keep copyright in
  $url="www.YOURSITE.com"; // site to monitor
  $res="result.txt"; // your results file
  $openURL=false;
  $fp = @fsockopen ($url,80,$errno,$errstr,8);
  if($fp)
  {
    $openURL=true;
    fclose($fp);
  }
  $outString =date('YMd-H:i:s')." - ".$url.($openURL?": OK":": ERR")."\n";
  if ( !$openURL )
  {
    $fileName=dirname($_SERVER['SCRIPT_FILENAME']) .'/'.$res;
    if ( $fp = @fopen($fileName,'a+') ) // success?
    {
      fputs($fp,$outString);
      fclose($fp);
    }
  }
  echo $outString;
?>

What it does is reside on another site (obviously – it won’t do much good checking its own site), and do a test as often as needed. If the website call fails, then the program writes a record of the failure to disk, allowing you to easily check it day in, day out.

To use, just:

• Copy the code to a file, making sure you rename the website ($url) to yours, and the text file ($res) to whatever suits you.
• Upload the code as anything you want – check.php, for instance.
• Upload an empty text file, called result.txt (or whatever you set $res to) to the same directory.
• Change the text file’s permission to 777.
• Add a CRONTAB entry for this program that will allow it to be called regularly – here’s an example:

  
  * * * * * wget -q -O /dev/null http://www.YOURSITE.com/check.php
  

You can set to run this at any interval that’s suitable, but I find once a minute works well.

Now, whenever your (other) site is down, the call fails, and an entry is written to disk. From your browser, you can look at the text file (bookmark it if you want), and know how your site is doing.

And now for something off-topic: if you found this easy to set up, then you’ll have no trouble with ActiveLinker, my product to give you your own ‘tinyurl’ service, and protect affiliate links. Buy it today.

A problem cropped up on one of my sites. I wanted a massive redesign, but at 100+ pages, I wasn’t looking forward to the retrofit.

Worse yet, I didn’t know exactly what I wanted, so I had a choice – tinker and tinker until I was happy, or incrementally upgrade, see what works, and end up updating pages like crazy.

In the end, I broke down and looked into Server Side Includes (SSI). Although SSI can be used for a variety of uses, I just wanted text included: create common elements of my site (title, navigation bar, bottom copyright), put them in a separate file, and thereby make updating much easier.

For instance, I could put my page banner along the top into a seperate file, and then for every web page simply include the file with this command:

<!--#include file="ssi_hdr.txt"-->

The end result is the server ‘pours’ this page into the other, and the end user sees the merged pages – including the new banner code.

And I get the benefit of having one page on my site with the banner code – so I only have a single page to change when I want a redesign.

But one big problem – you normally have to rename your files to the ‘.shtml’ extension, and we all know what renaming web pages does for search engines.

My solution? A great write up on SSI explained common options. For retrofitting, you have two ways of doing it, by adding section to your .htaccess file:


AddType text/html .html
AddHandler server-parsed .html
AddType text/html .htm
AddHandler server-parsed .htmXBitHack on

…or…

XBitHack on


With the first option, all your web pages will be checked, with the second, only pages that have their execute bit set will be checked for code.

Why the two options? Well, the power of SSI comes with a price – increased processing time. If you need it on only one or two pages, having all web pages checked for SSI commands is a timewaster.

On the other handle, always remembering to set the execute bit can be annoying, especially if all the pages on your site use SSI.

But, restricting SSI is a good thing – as a security issue, if you allow SSI across your site, you have to be very careful that user input is never displayed raw (such as in a comment or a guestbook). Otherwise, a user could enter the SSI commands, and the web page would execute them when displayed – with predictably bad results.

Using either option, you can combine the ease of maintenance with SSI, and keep that old site in the search engines. And reduce your workload to boot.