Enabling SSI Via htaccess
Many people want to use SSI, but don’t seem to have the ability to do so with their current web host. You can change that with htaccess. A note of caution first…definitely ask permission from your host before you do this, it can be considered ‘hacking’ or violation of your host’s TOS, so be safe rather than sorry:
AddType text/html .shtml AddHandler server-parsed .shtml Options Indexes FollowSymLinks Includes
The first line tells the server that pages with a .shtml extension (for Server parsed HTML) are valid. The second line adds a handler, the actual SSI bit, in all files named .shtml. This tells the server that any file named .shtml should be parsed for server side commands. The last line is just techno-junk that you should throw in there.
And that’s it, you should have SSI enabled. But wait…don’t feel like renaming all of your pages to .shtml in order to take advantage of this neat little toy? Me either! Just add this line to the fragment above, between the first and second lines:
AddHandler server-parsed .html
A note of caution on that one too, however. This will force the server to parse every page named .html for SSI commands, even if they have no SSI commands within them. If you are using SSI sparingly on your site, this is going to give you more server drain than you can justify. SSI does slow down a server because it does extra stuff before serving up a page, although in human terms of speed, it is virtually transparent. Some people also prefer to allow SSI in html pages so as to avoid letting anyone who looks at the page extension to know that they are using SSI in order to prevent the server being compromised through SSI hacks, which is possible. Either way, you now have the knowledge to use it either way.
If, however, you are going to keep SSI pages with the extension of .shtml, and you want to use SSI on your Index pages, you need to add the following line to your htaccess:
DirectoryIndex index.shtml index.html
This allows a page named index.shtml to be your default page, and if that is not found, index.html is loaded. More on DirectoryIndex later.
If your host supports the use of htaccess but not the use of SSI, there is probably very good reason for it. Please check with your host before doing this procedure.
|AddType text/html .shtml
AddHandler server-parsed .shtml
Options Indexes FollowSymLinks Includes
The first line states that pages with an extension of shtml are valid files.
The second line adds a “handler” which is the actual SSI stuff. Any file with the shtml extension must be parsed by the server.
The third line makes it all mesh together on the server.
That’s it. Now any pages you create on your site with the shtml extension will be able to use SSI coding (see below).
What about using SSI on .html extensions?
Don’t feel like renaming a bunch of files over to shtml extensions? Then try this instead :
|AddType text/html .shtml .html .htm
AddHandler server-parsed .shtml .html .htm
Options Indexes FollowSymLinks Includes
A bit of caution on that last addition though. This will force ALL pages on your site with an html extension to be sent into the server for parsing even if it contains SSI commands or not. The extra time to do the parsing action is transparent to the human eye, but it may bog the server down doing all these extra commands when it isn’t required.
The I of SSI stands for Include. What does this mean? Just as it sounds. It includes a specific part/code/script/feature into the current web page.
A very common use of SSI :
You have many pages that will have the same navigation area on them. Sometimes you want to change the navigation a bit but do not want to edit ALL of those pages. With SSI you can create one page for the navigation area and have all the pages link to that page. Only the one page will need to be edited for revisions.
This same feature may be applied for showing an advertisement that changes monthly. Or how about a daily greeting or update area?
Now before you go around and try to include a bunch of stuff, there is one minor drawback to SSI… You can only use files that are located on your own server directory or root. You cannot have one page on (for example) Geocities and have it include a file located on Tripod. It just won’t work. It’s not that powerful. Generally, this won’t be a problem for most of you since you are all good people who do not transload items anyways, right??
The “include” command has two property types available. FILE and VIRTUAL. Both of these do the exact same function. FILE is used when the included file is located in the same directory (or subdirectory) as the web page calling it. VIRTUAL is used when the included file is located in a directory address starting at the server root (not in the same directory as the web page calling it).
|<!–#include file=”navigation.shtml” –>|
|<!–#include virtual=”/subdirectory/navigation.shtml” –>|
The first forward slash in the VIRTUAL example above tells the server to start at the root directory. It then goes up the named subdirectory and finds the specified file to include.
I’ve used the VIRTUAL property for files located in the same directory (instead of using FILE) and it seems to work fine, but this may come to a “try it and test it” situation to be sure. It may depend on the server setup. By default, try using FILE first.