Week 14

* Assignment *

Questions from last time?

 

Server Side Includes

Server Side Includes (SSI) are lines of code that you can place in your Web pages; before the Web server sends your page out to a browser, the server interprets and replaces the SSI directives with designated information. This information might be pieces of HTML code from separate files (such as a navigation menu or footer that you want to appear on many pages of your site), or it might be the value of certain local varibles such as the date or time. There are examples of both below.

Side note: Active Server Pages (which have extension .asp) on a Microsoft Web server are a similar technology to pages using Server Side Includes because they are also processed by the server before being sent out to the browser. Similarly, .php pages are processed by a Web server before the resultant HTML page is sent out to the browser.

 

Server Setup

In order to serve pages that incorporate Server Side Includes, the Web Server must first be configured to do so. This is up to the administrator of the server, but information on how to do it can be found here.

NOTE: The UNM-LA main campus Web server is setup to allow Server Side Includes.

Depending on how the server is configured, your Web page filename may need to end in .shtml in order to have any Server Side Includes processed. Or, the Web server may be configured to process all Web page files with names ending in .html for Server Side Includes. This is not how most servers are configured, since this slows down the serving of all Web pages slightly, since they must all be scanned to see if they contain any SSI. Alternately, the Web server could be configured to process only .html files that have their execute bit set.

NOTE: The UNM-LA main campus Web server is setup to process Server Side Includes in all Web page files with filenames that end in .html (whether the execution bit is set or not), and will process SSI directives inside files with names ending in .shtml as well.

 

Testing Your Pages

Because SSI directives must be processed by the Web server, you can't test your pages that include SSI simply by opening them locally in a Web browser. If you do that, nothing will appear in place of the SSI directives. In order to test your pages that include SSI, you must upload them to the server and then view them in your browser.

Also note that when you view a Web page that used SSI, you will NOT see the SSI directives when you view the source code of the page in your browser. You only see the final, processed page that the Web server sent, and all the SSI directives have been replaced by other content.

 

Including Files

Below is a division with a white background. The content of that division was NOT initially part of this page, but instead came from the file inserted-text.html. If you look at the source code of the page now with your Web browser, it will appear that the division is simply part of this page.

This is an Example.

The content of this division (which is formatted with a white background to make things clear) was in a separate file, and it was inserted into today's lecture page by a Server Side Include directive.

chimpThis is another paragraph of inserted material, and an image floated to the right. The image was not part of the included file, but the HTML that inserted the image was part of the included file. The formating for all of this division is in the internal style sheet of today's lecture page.

This is it for the inserted material!

The line that inserted the division above looked like this in the original HTML of this page:

<!--#include virtual="inserted-text.html" -->

Note that the SSI directive is enclosed in an HTML comment. This prevents the SSI directive from showing up at all if the page is served by a Web server that is not configured to process Server Side Includes.

Important Note: There must not be a space between the start of the comment line (the <-- ) and the pound sign ( # ). But there must be a space before the marker for the end of the comment line (the --> ).

What is the advantage of inserting text on a Web page this way when I could have placed all that text in the page to begin with? Well, this technique becomes VERY useful when you want to include the exact same material on may pages within your Web site. For example, you may need to put the same footer at the bottom of every page of your company Web site. If you have the content in a separate file, you can use SSI to insert it on all of the needed pages. Then (and this is the very useful part) if you ever need to change the footer, you can just make the change in one place instead of having to go to dozens or hundreds of pages to make the same change!

I made an example Favorite Fruit Site that has six pages, and all of the pages use the same header, navigation menu, and footer divisions, which are put in place using Server Side Includes. The note.html page of that site shows what the HTML of one of the pages looks like before it is processed by the Web server.

Notice that the files that I am including are plain text files that contain only the HTML code that I wish to insert into the page at that point. You do NOT want to have DOCTYPE and <html> tags and all that other stuff in those files (they are not complete HTML documents themselves--just pieces that will go into an HTML document).

The file you want to include must be located on the same server as the page with the SSI directives in it. There are two attributes that can be used to specify the location of the included file:

<!--#include virtual="filename.html" -->

or

<!--#include file="filename.html" -->

Where it says "filename.html" above, you put the path to file you want to include. The virtual attribute is more versatile because the path specified can be relative to the page with the SSI directives in it, or relative to the root of the site (if you start the path with a slash), and can be a relative path such as "../filename.html" to get files that are in higher directories. The file attribute can't be used with files located in higher directories.

You can include files that also have Server Side Includes in them, down to 16 levels deep. So, for example, your included footer could contain an SSI directive it in that bring in the text of a "quote of the day" from a separate file.

If you have an error in your SSI directive, or the file you are trying to include can't be found or does not have proper permissions set, the resulting page will contain the error message:

[an error occurred while processing this directive]

 

Displaying Today's Date and Time

The echo directive displays the value of a variable. There are a number of standard environment variables that are available for display. For example, the DATE_LOCAL variable can be used to display the date and time:

You loaded this page on: Friday, 03-May-2024 15:09:42 MDT

The original HTML (before processing by the server) for the paragraph above is:
<p class="example">
You loaded this page on: <!--#echo var="DATE_LOCAL" -->
</p>

 

You can change the formatting of how the date is displayed by preceding the echo directive with a config directive with the timefmt attribute. For example:

The date is: Friday May 03, 2024

The original HTML (before processing by the server) for the paragraph above is:
<p class="example">
<!--#config timefmt="%A %B %d, %Y" -->
The date is: <!--#echo var="DATE_LOCAL" -->
</p>

 

The meanings of the symbols in the timefmt attribute's value can be found here. Here are some more examples:

 

The date is: 05/03/24

The original HTML (before processing by the server) for the paragraph above is:
<p class="example">
<!--#config timefmt="%m/%d/%y" -->
The date is: <!--#echo var="DATE_LOCAL" -->
</p>

 

This page was loaded at: 03:09 PM

The original HTML (before processing by the server) for the paragraph above is:
<p class="example">
<!--#config timefmt="%I:%M %p" -->
This page was loaded at: <!--#echo var="DATE_LOCAL" -->
</p>

 

This page was loaded at: 03:09:42 PM

The original HTML (before processing by the server) for the paragraph above is:
<p class="example">
<!--#config timefmt="%r" -->
This page was loaded at: <!--#echo var="DATE_LOCAL" -->
</p>

 

Oddly, if I put this page on the UNM Web server with the file extension .shtml instead of .html, many of the timefmt options don't seem to work.

 

 

Displaying the Modification Date of a File

You can display the last-modified date of a file by using the flastmod directive like this:

This page was last modified on December 07, 2010, at 03:31:03 PM

The original HTML (before processing by the server) for the paragraph above is:
<p class="example">
<!--#config timefmt="%B %d, %Y, at %I:%M:%S %p" -->
This page was last modified on <!--#flastmod file="index.html" -->
</p>

Notice that the date and time displayed by flastmod can be formatted using config as shown in the example above. Also notice that I am inserting various characters among the date and time symbols to produce the formatting I want. In the example above, I used the name of the current file (which is index.html), but you could specify a path to a different file if desired.

 

The last-modified date of the Web page file can also be displayed using echo to display the value of the LAST_MODIFIED variable, as shown below. I used the same time formatting as the example above.

This page was last modified on December 07, 2010, at 03:31:03 PM

The original HTML (before processing by the server) for the paragraph above is:
<p class="example">
<!--#config timefmt="%B %d, %Y, at %I:%M:%S %p" -->
This page was last modified on <!--#echo var="LAST_MODIFIED" -->
</p>

The advantage of using the LAST_MODIFIED variable method shown above is that you can use it in snippets of HTML code that you are going to insert into a page using SSI (and you wouldn't know the page name ahead of time, since that snippet of HTML code could be inserted into several files).

 

 

Making a Generic "Back" Link

Another environment variable is HTTP_REFERER. This variable contains the href of the page you came from. You can use this to make a generic "back" link that works like the 'back' button in a Web browser. This could be useful if there are several ways a user could have gotten to one of your pages, and this link will return them to whichever page they came from.

Go Back

The original HTML (before processing by the server) for the link above is:
<p class="example">
<a href="<!--#echo var='HTTP_REFERER' -->">Go Back</a>

</p>

Notice that I used single-quotes around HTTP_REFERER to prevent any conflict with the double-quotes used for the href attribute's value.

 

And More...

There are other environment variables that you can use (such as for finding out what kind of browser the user is viewing your page with), and you can also use conditional expressions is SSI to cause your page to react in different ways depending on the values of the variables (running different scripts for different browsers, for example), but this is as far as I will go with Server Side Includes.


 

 

Some Web Page Design Principles

---

 

 

 

 




Assignment - None, but...

You can use any of today's material in your Final Project for extra points. Be sure you specify where you have implemented any of the features on your "required features page" (see the final project assignment link below).

 

ABOUT THE FINAL PROJECT

See final day page for notes about the final project.