An Introduction to Server Side Includes

This guest article was written by Matt Haney, the original can be found at: http://www.m.j.haney.btinternet.co.uk/ssi.shtml - The navigation bars mentioned in the article can be viewed at this site. Any comments that I, Jamie, have added are noted by (Jamie: comment)

Contents

• Why SSI?
• Testing the water
• Simple SSI Directives
• Conditionals and Flow Control

SSIs help to ease site maintenance by allowing developers to create a standard component and then include it wherever it is needed. This article describes why I chose SSIs over the other methods available, and then goes on to explain how I used them to create my navigation bar (found at: http://www.m.j.haney.btinternet.co.uk/ssi.shtml) .

Why SSI?

When I came up with the extremely vague idea of adding a navigation bar to my site, I looked at the various ways of doing it and eventually decided on SSIs. The choices I had, and their pros and cons are thus:

Hard code the navbar onto every page

Arggh! Now this just sounds stupid from the offset, doesn't it? (Doesn't it!?) If I ever want to change the navbar, I'd have to make the same changes to each page in the site. Not my idea of fun.

Put the navbar into a frame

This appears to be the standard way to do this kind of thing. The advantages are that it would be easy to maintain (just the one file would need to be changed), and the navbar would stay on the screen all the time.

Disadvantages are that some (not many) user agents can't display frames, so I'd be cutting out some of my prospective audience. Also, its very easy to create a bad frameset so that bookmarks don't work properly and the user can never be sure about where they really are.

Use a client-side scripting language (VBScript, JavaScript etc)

I was tempted by this, but they all involve learning new syntax, and although that's not normally something I shy away from, I didn't really feel like learning lots of new stuff to do something as simple as a navbar. I'm also quite wary of relying on such methods, as they usually involve allowing users and/or thieves to read your source code.

Use a server-side scripting language (SSI, ASP, JSP, etc)

I like the idea of server-side scripting. The results are just plain HTML which any user agent should be able to understand. It also allows the developer to keep his secrets safe, by hiding the source away on the server, away from prying eyes.

I chose SSI because its syntax is very much like that of HTML. All you need to do is put some special comment-like directives in and bob's your uncle. SSIs do put an extra strain on the webserver, but if you can notice you're a better man than me.

Testing the Water

Before you start planning your whole site around SSIs, it might be a good idea to make sure you have somewhere to host it. Not all web hosts support SSIs because of the aforementioned performance hit. So, here's a small file you can upload to test the water:

ssitest.txt (text file - rename to ssitest.shtml) - Code below:

Save the file as 'ssitest.shtml' and upload it to your webspace. When you view the page, one of two things could happen. If you get a page full of stuff (like this), then "woohoo!", your server supports SSI. Otherwise you'll get a blank page and I'm afraid it's time to find another web host (you might be able to badger the server admin to enable SSI support, but I wouldn't count on it).

Simple SSI Directives

Before we start doing anything too daring, here's the general form of an SSI directive:

When your webserver comes across one of these tags it replaces it with whatever is specified by the element and attribute values. This could be any number of things, such as the current date, the date the file was last modified or the contents of another file.

I created my navigation bar by setting it out in a file on its own and then including it on every page. The source for this is:

...and its placed within a table which is set up on each page. In hindsight, it would have made sense to put the table set-up tags in the include file, but it makes little odds for a site this size (Jamie: Matt has a small site).

Notice that the file I'm including is also server-parsed (its extension is shtml). This is because I wanted to use SSI directives in the navbar itself. The server parses each file as it loads it, all in one go, so I needed to tell it to parse the included file before it pastes it into the document.

The 'last update' is also done by an SSI, like this:

Line 1 sets the format I want the date displayed in. %e/%m/%Y means display the date in the form "DD/MM/YYYY".

Line 2 just prints the built-in variable 'LAST_MODIFIED' using the format I specified.

Conditionals and Flow Control

Once I'd got a standard navbar onto each page, I thought it'd be nice to give my visitors a visual cue as to which page they are on. The obvious way to do this was to disable the link for the current page. Thankfully, SSI provides an easy and effective way to do this thanks to its conditional expressions.

As any programmer will tell you (I hope), conditional expressions are used when you want one of two or more things to happen. In SSIs, this is done with 4 tags. These are:

These tags are often used in conjunction with variables to alter the page contents depending on certain conditions. In my case, I set a variable to the current page name and do various things depending on it. I think this calls for a snippet from my code.

On line 1, I get the current document name and store it in a variable ($page) so that I can refer to it in the 'if' statements. Note - that's not a typo. When defining variables you omit the '$', but you need it when you use them.

On line 2, I check $page to see if this page's name contains the string 'index'. The slashes (/.../) signify I'm using a regular expression; when used like this, the expression will return true whenever 'index' appears anywhere in the page name.

Line 3 is the normal HTML I want to display if this page is the index, i.e. a pushed in button and the word 'Home' with no hyperlink, like this:

Line 4 is the 'else' tag. This tells the parser that I've finished with the code I want to return if the expression was true, and am about to start on the code for when the expression is false.

Lines 5 and 6 are the HTML code for when the expression is false and this is not the index, i.e. a raised button and a hyperlink pointing to index.shtml, like this:

Finally, Line 7 tells the parser that I've finished with this particular 'if' segment. Any HTML after the <!--#endif --> will be printed regardless.

This technique is then repeated for each of the sections I want to display in the navbar.

This was just a quick run-through of the fundamentals of SSI and how I use them. If you have any comments or criticisms about this article, please mail me (Matt), or Jamie McHale, webmaster of this site.