Why SSI and a Secret to Working Toplists

by Old Tom

OTScripts.com

What is SSI, and why might you want to use it? SSI stands for Server Side Include, but what does that mean?

An include file is a file that gets included. It's that simple! A server side include file, is a file that the server inserts into your web page before feeding it to your browser. For example, you might put a web page on your server that looks like this:

<html><head>
<title>My Title With Keywords</title>
</head>
<body>
<!--#include virtual="navbar.html" -->
<h1 align=center>My Title With Keywords</h1>
<p>Yada yada...</p>
</body></html>

Assuming you have your server set up correctly, your server replaces the line:

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

...with the contents of the file navbar.html. Incidentally, you can name the file anything you want. navbar.html, navbar.txt, or navbar are just fine. You could even name it navbar.gif, but that would surely lead to plenty of confusion later on. It is a plaintext file containing HTML instructions, not a graphic as the .gif filename extension would imply!

Your include file can be anywhere on your server, so long as it is on the same domain. Here's an example. Right now, as you look at this page, you're looking at a page in The DFN Weekly. I can put a file called navbar.html in the same folder. Go ahead and click the link, so you can see it's there! The file looks like this:

<table border=1 cellspacing=3 cellpadding=1>
<tr>
<td><a href="http://www.vnwr.com/dfn
/032404/index.html">First Page</a></td>
<td><a href="/dfn/032404/page2.html">Newbie Project of the Week</a></td>
</tr>
</table>

The NPOW (Newbie Project of the Week) link can be written any of three ways. Slow down, read the following carefully, make sure you understand the distinction. It's a simple distinction, but only if you follow what I'm saying:

  1. http://www.vnwr.com/dfn/032404/page2.html - I call this a "full" or "absolute" URL. You can use this full URL on any web page anywhere on any domain on the planet, and it will be correct. This is the "universal" locator for that web page. "URL", you will recall, stands for "Universal Resource Locator."

  2. /dfn/121703/page2.html - I call this a "domain-relative" URL. You can use this URL on any web page anywhere on the same domain. This might seem a poor compromise... why not begin with the http://www.vnwr.com and be done with it? Especially if your domain name itself does well in the Search Engines? You are absolutely correct - except when it comes to SSI. To make SSI work for you, you need to understand domain-relative URLs. So long as you understand the idea of saying where a web page is, relative to the domain root, you'll be able to set up your SSI correctly.

  3. page2.html - I call this a "plain" or "non-absolute" URL. For this to work, the file must be in the same folder as the web page mentioning it. You probably have used this type of URL many times, when using graphics on your web page that are in the same folder as the page. You might write, for example, <img src="logo.jpg" border=0> or <a href="pic01.jpg"><img src="thumbs/pic01.jpg" border=0></a>. Both of those are "non-absolute" URLs, because they only work on web pages in that particular folder. Move the web page without moving the graphics, and you have broken links.

Voltar generally recommends the first form, that is, the "full" URL beginning with http://. There are a number of reasons he suggests doing that - including the possibility of playing better in the Search Engines, and the fact that you can move the page to any folder on any domain without ever having to edit the page. When you build mirrors and doorways, that is an extremely valuable technique.

Unfortunately, when using SSI, you can't point to the SSI file with a full URL. You must use the second or third form. Can you see why? SSI only has one rule, but you must follow that one rule. The SSI file must be on the same domain. Therefore SSI actually has a second rule - that rule being that you can only point to the SSI file using the second or third form of URL.

(Incidentally, if you use the ErrorDocument directives in your .htaccess files, it pays to understand the distinction between full URLs, and domain-relative URLs. Check the documentation for details.)

To summarize, then, you can have navbar.html be part of your web page using either of the following two lines:

<!--#include virtual="navbar.html" -->
<!--#include virtual="/dfn/032404/navbar.html" -->

Be sure you get that #include virtual= stuff exactly as shown above. I usually go straight to the official document and make sure I have it correctly, copying and pasting their example.

Why bother to use SSI? It's confusing; you need your server configured correctly; what you see with your browser is different from what you see with ftp. Keeping track of that SSI stuff can get to be a total mess. So... why bother?

This very example shows a good time you might use it: When your site uses the same "navigation bar" on several different pages. Rather than copy and paste the same material over and over, just put the #include directive in each page. Suddenly all pages have the same navigation bar! As your site grows and mutates, you only need to change one file, to change the navigation bar on all pages.

Did you notice that the NPOW link points to the wrong page? No problem... just correct the line in navbar.html, and every page has the corrected link. Have you ever copied and pasted the same typo to page after page after page, only to have to go back and fix every one of those pages? If you had used an SSI file for that "copy and paste" information, you'd only need to correct it in the one place. (On the other hand, keeping millions of little SSI files around can cause more trouble than they're worth. Limit the technique to places with a big benefit.)

You can do something similar with your traffic flow. Jojasa and I, for example, have an HTML table item which promotes our AVS premium sites. Many different pages #include that same table. When we add another AVS premium site, we add it to the table, and suddenly all pages have the updated table. Very nice!

Click here for more information on becoming a WFA member.
Have you checked out
the sponsors of the DFN Weekly yet?
Well what are you waiting for?
Check them out NOW!

This, however, shows up a difficulty with SSI. The problem is that the SSI file must be on the same domain. Since we advertise our AVS premium sites on several different domains, we need a copy of that table on each domain. To make this scheme work, then, we have three options:

  1. Put a copy of the file on each domain. That means when you update the file, you need to update all copies of the file. Still, this may be the simplest. If your domains are on physically different servers, this may be your only option.

  2. Keep one master copy of the file, and use "symbolic links" to put "pretend" copies on each of your other domains. When you update the master copy, all other copies are instantly updated, and therefore all web pages on all domains on your server are also instantly updated. The effect is very cool!

    This technique is similar to putting a shortcut icon on your Windows desktop. The shortcut icon is just a placeholder pointing to the actual file. I personally use the "symbolic links" option. The difficulties are (1) remembering where you stashed the master copy; and (2) keeping track of all those symbolic links, particularly when moving servers. It's easy to wind yourself into a real mess; I recommend using symbolic links only if you (and your server admin) really know what you're doing. But if you do know what you're doing, you have a tremendously powerful tool in your hands!

  3. Use the server Alias configuration directive, to create a folder than can be seen by all domains. Drop the file to #include into that Alias folder, and you can point to it from any web page on any of your domains. That's because so far as the server is concerned, that folder is part of that domain.

    I don't personally use Alias, but in hindsight I wish I did. That is, I wish I had done it this way for SSI files that we use on all of our domains. That would be much easier than messing with all of those symbolic links! (There are other situations where I prefer to use the symbolic links, but this isn't one of them.)

Why else might you use #include files? Well... ever had to swap out a sponsor? If that sponsor ad were an SSI item, you'd only need to update the SSI item, and you'd be done. Unfortunately it's not quite as easy to organize and set up SSI ads as it sounds... but I have an example where it is easy: Toplists.

If you've ever worked with toplists (and I hope you have), you'll know there are a couple of difficulties. The first problem is the quality of the toplist itself. You may later find that you need to drop that toplist; or you may find that the toplist has dropped you. Either way, it's time to move on. What if you had set up links to this particular toplist like this (your BDSM toplist #1):

<!--#include virtual="/toplists/bdsm01.html" -->

...and your file bdsm01.html in your /toplists folder contains the toplist linking code.

Can you see the advantage you've created for yourself? You can drive hits to that toplist from any number of web pages; just place <!--#include virtual="/toplists/bdsm01.html" --> on each of those pages. If you need to switch toplists, just edit bdsm01.html, and all those web pages are suddenly sending traffic to the new location.

Have you ever considered temporarily sending traffic to a sponsor during a promotion? Would it be nice to send a whole bunch of correctly targeted traffic to that promotion? With your SSI toplist setup, you can!

Think about where you placed links to your "BDSM #1" toplist. Surely you placed the links to filter BDSM traffic? Suppose, then, your BDSM sponsor is running a one-day promotion. Might it not be handy to be able to change bdsm01.html for that one day, to feed your BDSM traffic to that sponsor rather than continuing to feed it to that toplist? At the end of the day, return that traffic to its normal toplist flow, and you haven't wasted a single click. Easy! If you plan ahead of time, and keep your toplists organized with SSI.

The other problem with toplists, is in "priming the pump" so to speak. You build a new web page and put it on your server. That web page, probably, has zero traffic at that point. How could it? You want that page to include a toplist. So, you go register for the toplist, get your linking code, put it on the web page. The trouble is, that page still has no traffic, and therefore no traffic to send to the toplist. The toplist won't return traffic to you, when you're sending it nothing in the first place. And, worse yet, the toplist will drop you entirely if you continue to not send it any traffic. By time you have traffic moving through that page, and are sending traffic to that toplist, the toplist may have already dropped you. By this time you're doing nothing more than throwing away that fresh traffic you just developed. Surely this is not what you had in mind!

So... do it the other way around. Set up your toplist link as an SSI file - but make it merely a placeholder. Instead of an actual toplist link, put some useless (but keyword heavy) text in there, but no link. Or, put a link to a sponsor or another of your sites in there. Develop the traffic to the page, and then go register with the toplist. Add the toplist link, and you instantly have traffic moving on through. SSI files make excellent placeholders!

To get SSI to work at all, you probably need to add the following lines to your .htaccess file. Check with your server admin for help:

AddType text/x-server-parsed-html .htm
AddType text/x-server-parsed-html .html

The most common problem with getting SSI working, is that "it doesn't work." The page comes up blank, where you expect the SSI item to be. You "view page source", and you see the SSI directive there right like it should be. That's the problem! If you can see the #include directive when viewing the page source, SSI is not repeat NOT working for that file. Even though you think SSI is enabled for that web page, I can guarantee you that it is not. Fix the problem, and you're done :)

Finally, I should mention that we've touched only the tip of the SSI iceberg. I mentioned only SSI files - but you can do a lot more with SSI than merely insert files. You can run an entire TGP site, with no CGI scripting at all, using SSI directives. You can personalize web pages with the date and time. You can generate dynamic content. But the place to start, is with those SSI files. Stuff happens - that's a guarantee - and when it does, you'll be awfully glad you did.

Previous PageNext Page

© 2001-2004 EA Ventures. All rights reserved.