Web Site
Developers

Dynamic Content - Page Failure Notification

Summary

My previous article discussed a set of dynamic menus based upon no more than one, simple web page template, a few appropriate text files and absolutely minimal php code. There is a caveat, I dodged my responsibilities, i.e. I showed no effort to catch failures and errors. This was due to my initial code being flawed, hence, the first article was able to stress the core simplicity of the endeavor. Now, however, I attend to more serious business of both noticing failures and notifying those responsible.

Notify the Maintainers

When a flaw or error is detected, I see the first task is informing those able to correct the underlying problem. That is, email will be sent to a number of addresses with as much information that can be gathered at the occurrence. The site uer(s) will be notified politely afterwards that a problem has been encountered and ask for their forgiveness. Nonetheless, the first order of business is informing the webmaster and whomever else might fix the flaw.

Simple Reminder

I would like to remind you how we reach a specific menu from my home page, it is using the global GET[] value that is appended onto the url link. The simplest method is to copy the line from my previous article:

  http://[site]/[path]/[menu-template].[ext]?item=[code]

To me the likeliest location of an error would be a mangled or missing GET[] value that could be caught right at the start of processing a page. Therefore, that is where I would place the initial testing and subsequent email posting if a failure were encountered.

Early Testing

I suggest placing the initial test at the top of the web page, e.g. here right in the head tag area (stealing O'Reilly's site naming):

  <head>
     <BASE HREF="http://www.example.com/">
     <?php
	   $get_it    = urldecode($_GET["item"]);
	   $menu_meta = $_SERVER['DOCUMENT_ROOT']."/[subdirectories]/menus/meta/";
	   $all_menus = array(tags,template,hardware,problems,tools,energy);
	   $if_error  = false;

	   /* test to see if $get_it matches possible menus selection.   */
	   if (in_array($get_it, $all_menus)) {
	      /* insert specific meta tags for this menu here. */
	      readfile($menu_meta.$get_it.".txt");
	   } else {
	      $if_error = true;

	      /* Warn responsible parties of failure via email */

	      [email code]

I am splitting the code here, because the full functionality need not be in this location. Nonetheless, for now that is where I am going to place tested, working code. However, I want to stress this need not be the location and for many reasons it is not optimal choice. If the passed value, $get_it, does not match any in the list it is mandatory that the proper persons be contacted. Here is an approximate version of the code I employed to notify the site's web master and other interested parties:

  $subject  = "Menu Failure ".$get_it." not matched";
  $message  = "No Menu match with ".$get_it."\n"; */

  /* Inform web master of problem */
  $to       = "webmaster@example.com, hcohen@othermail.com, hcohen2@backup-mail.net";

Let's stop here to examine each line, before moving into the body of the email. Using my criteria those addressed using the $to variable is the most important. Since, I am the only one watching the site for maintenance purposes, I am more likely to see messages sooner on my regular email accounts than as webmaster. Therefore, my failure message is sent to all.

The email's subject line, $subject, alone could make the main message in the body redundant. A simple observation of just space between the words Failure and not means the menu code name was absent. Another potential failure could be to a misshapened GET value and that too would be visible in the subject line. However, the possible solution may not be obvious. Nonetheless, the site maintainers are on notice there are problems that have to be addressed.

The last variable, $message, is the first line of the message body, however, it adds little to nothing to has not been transmitted by the subject line. Despite my doubts I am showing the extended version of the essentially innocuous message body:

  $message .= "Confirm error of failure to generate menu\n";
  $message .= "or check failure to match.  Correct, if possible.\n";
  $message .= "Thanks, Site auto checker\n";

as I implied not much here. For those unfamiliar with the php syntax, the .= concatenate the previous sting to this one, just as the periods with evaluated variables are pasted into strings.

I think it is more important to look at the header that can be associated with the visible description of the sender, source, etc, which should teach you to never trust that data [1.]. Always look at the true underlying header details [2.], which may look like this (as borrowed from another project [3.]):

     $header   = "Content-type: text/plain; charset=iso-8859-1\n";
     $header  .= "From: ".$mailer."\n";
     $header  .= "Reply-To: ".$mailer."\n";
     $header  .= "Return-Path: ".$mailer."\n";
     $header  .= "X-Mailer: php";

I want you to note, while I have used a single variable, $mailer, in each line I could have easily inserted three different variables and each as completely of either imaginary content or using a [your] real address attached to a message neither composed nor authorized in your name. I want you to recognize whatever the variable name and its value that are placed in the email header seen above, those are all defined in the php script. The veracity of the input is dependent upon the truthfulness of the sender. I advise you to check the real email header when in doubt and even other times.

Finally, here is how I send out the email messages:

  mail($to, $subject, $message, $header);

now those with the responsibility of maintaining the site have been notified of the failure. Thus, the first order of business has been accomplished when a problem arises.

Informing the Users

In the next two installments, I will show methods to pass the message to users that the site has experienced a failure. Moreover, I stress these are not user induced problems. Indeed, I ask the user to assist in tracking the problem. The first approach tries to break free of the rendering of the menu by going to a standard error information page. In the second, I use the same menu template form where I insert the message in the central column where the menu was supposed to be listed. My experience was the latter was smoother, despite my preferring the former. Thus, I will use the menu form to communicate error messages for my site visitors.

There will be more follow up articles, because the technique employed (cited above) do not suffice to trap other significant errors. It is my intention to exhibit how to test and to report selected instances of failures. The code will differ using the try catch syntax where an exception is thrown. I suspect that syntax would have allowed a redirection to a single error page form. If you find that appealing, you could try it on your site.

Corrections, suggested extension or comments write: How-To-Guy. If the mailto does not work, use this: hcohen[-At-]bst-softwaredevs.com.

Return B/ST Home or Dynamic Page

____________________________________________________________________

    1.  I am publishing a series on LXer.com that addresses security
        where this article started that discussion.  Return

    2.  It is my intention to cite this article in the afore
        mentioned LXer series, stressing the visible header is   
        untrustworthy. The series is now mired in security issues 
	where this introduction began the endeavor.  Return

    3.  These lines came from a form mockup I did for a perspective
        client, which in its first incarnation had completely false
	content to demonstrate the code.  Despite the bogus headers
	the emails worked reaching their intended targets.
	Return

Web Site Developers